Code Quality Notices

ProjectCodeMeter

Code Quality Notes

Quality notes warn on some basic coding issues (based on measured source code qualities) that affect maintainability, reuse and peer review. These are good practice guidelines to make sure the estimation is effective, and the code will be easy to understand and maintain (not syntax checking, since this is checked by your compiler).

* Many numeric constants, may be auto-generated - appears when too many hard coded numbers are inside a source file. Often automated tools are used for generating these types of embedded data, so this file effort may be over estimated. Ask your developer if this file was auto-generated, if so don't include it in the analysis.

* May be auto-generated - appears when there is some indication that the source file was created by an automated tools so this file effort may be over estimated. Ask your developer if this file was auto-generated, if so don't include it in the analysis.

* Code structure can be simplified. - appears when code structure (functions, classes, variables) is very complex, this may be due to one or more reasons:
- unnecessarily long variable, class or function names
- over dividing the code to small files, classes or functions that contain little or no code inside
- using absolute references instead of relative, local or cached ones. For example: java.lang.String myname = java.lang.String("William")
- using long reference chains. For example: stDressColor = MyDataStructure.users.attributes.hair.color;
- adding redundant code syntax such as extra semicolons, braces or scopes. For example: while(((i > ))){{{ i++;;;;;;}}};;;
Note that this may be unavoidable on complex applications or when creating an application skeleton.
Complex code structure is harder to maintain and increases the chance of errors (bugs).

* Needs more comments - appears when there aren't enough comments in the source file. Uncommented code is very hard to maintain or review.

* May need breaking down into functions or classes - appears when source code has low modularity (bulky code) with a lot of code stuffed into a single class or function. Large code chunks are difficult to understand and review. It is recommended to split these large code blocks into smaller functions, classes or even files.

* Code structure may be too fragmented - appears when over dividing the code into small classes or functions that contain little or no code inside. Note that this may be unavoidable on complex applications or when creating an application skeleton.

* Function and attribute nesting may need simplification - appears due to several reasons:
- over using absolute references instead of relative, local or cached ones. For example:
java.lang.String myname = new java.lang.String("William"); //this is unnecessarily long
String myname = new String("William"); //this can be used instead
- using long reference chains instead of cached ones. For example:
   YourEyeColor = MyDataStructure.users.attributes.eye.color;
   YourDressColor = MyDataStructure.users.attributes.dress.color; //this is redundant, can be cached
   YouAttributes = MyDataStructure.users.attributes; //this caching can be used instead
YourEyeColor = YourAttributes.eye.color; //now it's more readable