Code quality has always been a concern when there are defects coming out of nowhere. There are code reviews and then there are code reviews. Testability of the code is also one of the code quality parameters. Unit Tests and their code coverage is indicator of the code quality and having a high quality set of unit tests gives confidence to make changes to the code. However we are not covering testing here.
What causes code quality issues
- Lack of awareness across teams about what is code quality and coding principles like SOLID
- Many projects tend to complete the reviews just because there is a process which they realize just before delivery and then they need to be compliant.
- In other cases, when project has gone live the core team is dismantled and the support engineers who take over are scared of touching the code written by someone else. So they make changes and give some explanation and the reviewer is also scared of taking risks and the changes get approved without really doing a code quality check. They also comment around the code block with defect number.
- Naming convention is a matter of choice. I wrote about Naming Conventions and Code Redability quite some time back In old times most of the developers chose to use Hungarian notation to prefix the variables to indicate the data type or UI control type etc. Microsoft chose to drop all of this since beginning of .Net. Many years have passed but we still see people using Hungarian notation. Junior developers tend to mimic the seniors of code styles from old projects. This is a habit that dies hard. So in a project you can see code developed by different developers and technical leads buy the argument that this is a trivial issue as long as the code works. However in a modern IDE like Visual Studio, which immediately can tell you about a wrong assignment, such use of abbreviated prefixes is really unnecessary. It has a huge impact on readability of the code.
- In some projects for whatever reason no one bothers about code quality. Developers are either not aware or pressed by timeline or they take liberties because tech leads are too busy to review the code. The only way to ensure product quality is the black box tests executed by the test team.
Fixing code quality issues
- Learn SOLID principles of coding and why they are important. Here are few resources to learn these principles
- SOLID (object-oriented design) – Wikipedia, the free encyclopedia
- SOLID | DevIQ
- SOLID Principles of Object Oriented Design | Pluralsight
- S.O.L.I.D. Programming Principles
- From STUPID to SOLID Code! · William Durand
Off there principles one that impacts the code quality in long term is the SRP – Single Responsibility principle. Many times developers confuse what can be called as Single. Easy test for the same can be things that change together stay together. Another is to look at it from testing perspective. Does the block of code needs to be tested separately? Can something go wrong when executing the lines of code. In such cases take the code block as separate method. SRP can be applied to methods and it can also be extended to class and component design.
For a given process preferred style of coding could be to have a top level method which defines the process flow and for each step write a separate method. This way the code gets split at least at each conditional statement. This also brings down the cyclomatic complexity mentioned in the code metrics section.
- Code Metrics is one of the most useful tools which is part of Visual Studio. It is not as enhanced as tools like NDepend, however it is extremely useful for day to day tracking of where the code is likely to have quality issues. Two key parameters to watch for are lines of code for any entity like class or method and Cyclomatic Complexity for any method. Typically any method with LoC about 30-40 and CC about 10 must be reviewed and should be simplified by way of refactoring. More about it can be found on following links:
- Code Analysis is again a built-in tool of Visual Studio. It is integrated version of FxCop that many folks have used for earlier version of VS & .Net. Code Analysis depends on set of rules. These rules are categorized into groups like Performance, Globalization, Design, Security, Maintainability etc. There are many Microsoft defined rule sets available out of box in Visual Studio. However, teams can customize the rules applicable for their project. E.g. if the application is developed for only single language and culture, team can decide to ignore globalization rules. Code analysis can be configured to run on every build and the rules can be modified to raise a warning or error on failure to meet them.
- Improve readability using StyleCop, a tool distributed free of cost by Microsoft. Style cop works similar to Code Analysis by using a predefined set of rules. StyleCop can also be integrated with Visual Studio using StyleCop VS Extension from the gallery.
How to include the code quality check in your daily routine
- Select Code Analysis rule set suitable for your project. Making running code analysis at end of every build as default for all developers. Running code analysis after a lot of code is written has a negative impact on developers as it normally shows a lot of errors which creates an impression that the code needs to be rewritten. However running the analysis on every build gives early warning to developers before checking the code in to source control. This helps the code to remain high quality. Time required on every build: about 2 minutes. Assuming there are 5 major check-in per day in your source control, total time taken 10 mins per day
- Run Code Metrics at least once a day across the whole code base. This helps the leads in identifying where the team is writing complex code or large code blocks. Code metrics is comparatively time consuming process and needs a successful build. Long methods and complex code are easy to smell for individual developer. Individual developer can keep refactoring & simplifying the code once the understanding of how it helps in long run. Typically teams will take about one iteration to realize the importance of Cyclomatic Complexity. The first aha moment comes when there is a change request for any reason. Time required every day for medium sized project: about 10 minutes to run and export the results to MS Excel.
- Advanced techniques:
Additional Resources
- Improve Code Quality (MSDN)