1)
I think the most important feature of code is class size. If a class becomes too large, then the class will become
too difficult to manage and is likely to result in more comments in comparison to if the class was broken down
to subclasses. If the class size is huge, then it is likely that it contains many methods and long methods
compared to if the class was broken down to subclasses, since when having multiple classes there are likely to
be more methods but more manageable chunks of code. Overall, large classes itself leads to other code smells
which have a highly negative impact, and therefore it would be best to avoid classes from being too large.
One metric would be weighted methods per class (Sommerville, 2011) if the complexity of the class becomes
too complex then it would be a good indicator to break the class into subclasses to keep the classes easy to
understand. Likewise, if a class isn’t complex enough it could be an indication to make the class a bit more
complex, otherwise it may become confusing managing too many classes.
Another metric would be depth of inheritance tree which takes the number of discrete levels in the
inheritance tree where subclasses inherit attributes and methods from super classes (Sommerville, 2011), if
the inheritance tree is too deep then it would mean the design is more complex, which would mean the design
of the classes would need to be looked into and perhaps if class sizes are too small and that’s the reason for
having a huge inheritance tree it could be better to have bigger class sizes.
Another metric would be number of children (Sommerville, 2011) as it measures the number of subclasses in a
class, it may be better to break a class into subclasses to make it easier to understand, although having too
many subclasses may make maintainability a bit more complicated, which is why it’s good to have a right
number of children.
Another metric would be coupling between object classes (Sommerville, 2011) if coupling is too highly
dependent between classes which means it is more likely changing one of the classes with the impact the
other classes within the program. If a class is too dependent it could then become difficult to break the class
into smaller subclasses which could lead to a large class.
2)
I chose project “Java” (GitHub, 2019). This project has 33 commits, 1 contributor, 0 releases, and 1 contributor.
From the contributor’s graph, the project’s first commit was on November 22 nd 2015 and last commit was on
November 30th 2015 which means the project is likely completed as it hasn’t been updated in so long.
Furthermore, the duration of the project was only 8 days. The contributor wrote 39958 lines and removed 386
lines, which means the contributor wrote a total of 39572 lines. There are over 2,700 forks which is probably
because the original owner of the repository hasn’t updated the repository in years, and users which have an
interest in this project have forked their own updated version so other users with an interest can use their
updated version instead. The project also has over 5,000-star rating which is considerably high for this
respiratory.
I think the most important feature of code is class size. If a class becomes too large, then the class will become
too difficult to manage and is likely to result in more comments in comparison to if the class was broken down
to subclasses. If the class size is huge, then it is likely that it contains many methods and long methods
compared to if the class was broken down to subclasses, since when having multiple classes there are likely to
be more methods but more manageable chunks of code. Overall, large classes itself leads to other code smells
which have a highly negative impact, and therefore it would be best to avoid classes from being too large.
One metric would be weighted methods per class (Sommerville, 2011) if the complexity of the class becomes
too complex then it would be a good indicator to break the class into subclasses to keep the classes easy to
understand. Likewise, if a class isn’t complex enough it could be an indication to make the class a bit more
complex, otherwise it may become confusing managing too many classes.
Another metric would be depth of inheritance tree which takes the number of discrete levels in the
inheritance tree where subclasses inherit attributes and methods from super classes (Sommerville, 2011), if
the inheritance tree is too deep then it would mean the design is more complex, which would mean the design
of the classes would need to be looked into and perhaps if class sizes are too small and that’s the reason for
having a huge inheritance tree it could be better to have bigger class sizes.
Another metric would be number of children (Sommerville, 2011) as it measures the number of subclasses in a
class, it may be better to break a class into subclasses to make it easier to understand, although having too
many subclasses may make maintainability a bit more complicated, which is why it’s good to have a right
number of children.
Another metric would be coupling between object classes (Sommerville, 2011) if coupling is too highly
dependent between classes which means it is more likely changing one of the classes with the impact the
other classes within the program. If a class is too dependent it could then become difficult to break the class
into smaller subclasses which could lead to a large class.
2)
I chose project “Java” (GitHub, 2019). This project has 33 commits, 1 contributor, 0 releases, and 1 contributor.
From the contributor’s graph, the project’s first commit was on November 22 nd 2015 and last commit was on
November 30th 2015 which means the project is likely completed as it hasn’t been updated in so long.
Furthermore, the duration of the project was only 8 days. The contributor wrote 39958 lines and removed 386
lines, which means the contributor wrote a total of 39572 lines. There are over 2,700 forks which is probably
because the original owner of the repository hasn’t updated the repository in years, and users which have an
interest in this project have forked their own updated version so other users with an interest can use their
updated version instead. The project also has over 5,000-star rating which is considerably high for this
respiratory.
