Go BackGo Forward Index Home    

Project
Code
Meter

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 or error checking, as these are checked by your compiler and lint tools).

* 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 contain auto-generated parts - appears when there is some indication that some or all of the source file was created by 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. It's recommended to at least comment on WHY the code and design was made and what pitfalls or limits it has. Optionally a general description of WHAT a block of code is supposed to do.

* 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

* No Code - doesn't contain any code. either file is empty or contains only markup (i.e HTML file without script)

* Old version has newer timestamp - in differential analysis the file in the "old version" folder is newer than the file in the "project folder", this makes timestamp based span estimation unreliable

* Lines were commented out - in differential analysis some previously active code lines were converted into a comment.This is sometimes done to keep some debugging or unfinished code during development, or by mistake. This code shouldn't be released to clients as it contains code in comments.

* Commented out lines were reintroduced - in differential analysis some code that was in a comment was now made active by removing the comment markers. this may indicate some debug code is present. ProjectCodeMeter won't include this code in the effort score (hours and cost) as it was already scored when it was first written

* Lines were commented out and/or reintroduced - in differential analysis some previously active code lines were converted into a comment, and / or other code that was in a comment was now made active

* Big file, consider splitting - Indicates that a file size may be too large to maintain comfortably, as too much functionality / data / UI markup was placed into it .

* High LLOC Duplicates - Means a lot of the code lines are the exact duplicates of eachother. May indicate some boilerplate code exists, or code was copy-pasted instead of placed into a common function. This might cause the file to  be over-valued.

* Might be obfuscated - Means the code appears to be mangled / compressed by a tool that makes it hard to understand by a human developer, but compile and run correctly, sometimes faster. Obfuscated files have significantly lesser value as source code and not considered as such.

* May benefit from line breaks - Means that adding some new line spacing may help make the code easier to read and understand.