Go BackGo Forward Index Home    

ProjectCodeMeter

Code Quality Notes

Quality notes warn on some basic coding issues (based on measured source code smells, metrics and qualities) that affect development time and cost, maintainability, reuse and peer review, or incompatibility with the used cost models, especially Wighted Micro Function Points, however ProjectCodeMeter will do its best to understand your source code even if it's invalid or non-compilable.
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).
Note that ProjectCodeMeter checks are aimed towards managers and cost estimators, so while it covers some relevant checks in known standards (such as MISRA, CERT C, CWE, JPL, IPA/SEC C, Netrino C, HIS, JSF++ AV, High Integrity C++, AUTOSAR, CAST-12) many aren't covered while it does check for novel issues not covered by these standards.
Individual quality notes only appear for languages, platforms or application infrastructure providers (AIP) on which they are relevant.

Checked Quality Notes:

* High LLOC duplicates - Means a lot of the code lines are the exact duplicates or very similar to eachother. May indicate a lot of trivial boilerplate code exists.

* High duplicates influence - Means a lot of the estimated time is attributed to code lines that are the exact duplicates of eachother. May indicate a lot of boilerplate code exists (often to interface some framework), or code was copy-pasted instead of placed into a common function. This might cause the file to be over-valued (You can treat the Duplicate Percent metric as uncertainty, which you may want to subtract from the estimated work time and cost).

* 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.

* Comments contain code - Means file/project contains commented out code. This might be unfinished code or debug tests, that usually shouldn't be delivered to clients, as it may contain sensitive information, or make the code needlessly harder to read.

* High scope cyclomatic - Means a scope (function) has high amount of conditionals and/or loops and my benefit splitting/extruding into several functions.

* Might be test code - Means the file/project seem to contain test code (i.e unit tests) that shouldn't usually be counted (unless it's extraordinarily complex like simulation)

* Task remarks - Means the code comments contains task remarks like "TODO", "FIXME", "BUG", "HACK", "BROKEN", "DEBUG", "UNDONE" that may indicate unfinished work, or there are VCS merge errors in the file.

* May lack const correctness - Shown for languages that support const correctness, Means that some functions and their arguments might benefit from being declared as "const" or other immutable attribute. This generates faster and smaller binaries, and helps minimizing software bugs by restricting accidental state/value modification and allowing code analysis tools to perform deeper checks. It's one of the distinguishing marks of high quality code. Note that adding object const correctness is nearly a project wide decision, and may take significant extra effort (as immutable methods can only call other immutable methods).

* Hardware specific code - Means there is code that accesses specific hardware or fits a specific CPU family. This prevents the resulting software from running on some hardware, and may require extra effort to port to other hardware types.

* Parallel execution code - Means there is code that runs several execution contexts in parallel, such as threads or hardware interrupts. This speeds up software execution, but this code is harder to create and more error prone (commonly: data corruption, resource deadlocks, security race vulnerabilities)

* Too few checks for this quality level - Means the code has less than the expected try/catch or return value checks for the declared Quality Guarantee. Either the code has other means of error handling, or it might be of a lower quality than declared. Checking return values, function inputs, and execution state is key in preventing software bugs and security vulnerabilities.

* Restrictive license - Means license terms were found inside the code that may restrict its use, like mandating you distribute the source code, or print a copyright notice. (i,e GPL / MPL / Creative Commons)

* Might be decompiled - May have been generated by a decompiler from a binary software file. while it may compile correctly, this has significantly lesser value as source code, as it's harder to understand, and my infringe upon the original software copyright.

* 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.

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

* Conditional compilation - Means there's code for several alternative binary software that can be compiled from this source. This can be selected by some compiler toolchain option, like macro definitions, compiler directives, or compiler type. Be aware that the binary the compiler generates by default might be different than the one you need or the one tested by QA, so you may need to set up the project to get the one intended. Upon releasing new binary software you may need to make sure to test that specific compilation or all of them, rather than relying on alternate compilation passing the tests.

* Massive code deletion - Means a lot of code was deleted, may be due to aggressive optimization, refactoring, or accidental deletion.

* 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. Make sure you didn't accidentally switch between the Current and Old version.

* 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 probably shouldn't be released to clients as it contains code in comments, which may be confusing and harder to read.

* 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 by mistake. 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. (see above)

* 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 inside.

* 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.seer.attributes.eye.color;
   YourDressColor = MyDataStructure.seer.attributes.dress.color;   //most of these 2 lines can be cached
   YouAttributes = MyDataStructure.seer.attributes;   //this caching can be used instead
   YourDressColor = YourAttributes.dress.color;   //now it's more readable

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

* Scope too deep - Means there are many nesting scopes, either cascading classes, loops or nesting "if"s, that may need flattening out to improve code readability.