Code Quality – Learn, Measure and Organize Awareness

How many times it has happened to you that when you join a new project and start looking at the code first time or when some new member joins the project then people usually say that what the crap is this code and we need to improve this and that. As time passes you seldom get the chance to correct it and the same thing passes over and over.

I would like to start the discussion with the simple list of questions which sooner or later comes in the mind of every developer like:

• What to learn to write good code?
• How can I figure out the code in front of me is of good or bad quality?
• What makes the piece of code fall under WTFs?
• What are the good or bad code quality factors or criteria?
• Is there any documents, books etc. which can help me here?
• Can any tool help me to check my code for quality problems?
• How to approach the code to solve the quality problem?
• How to transform the bad code into good code?
  
• How can I share the WTFs and solution with my team?

And many more similar questions which bother many developers a lot of times.

As very well put in words, the topics like:

Complaining about Other People’s Code

So, when we first encounter a new software system we are, in Dunning and Kruger’s terminology, incompetent compared to the programmers that wrote it.

How WTFs improve code quality awareness

Of course, a developer will never deliberately produce bad code. So in order to improve quality, the developers have to gain quality awareness.

Things You Should Never Do

The reason that they think the old code is a mess is because of a cardinal, fundamental law of programming:

It’s harder to read code than to write it.

On a general idea I would try to put some light on how you can approach to get better idea of the different quality standards and principles and to become more aware of the things so that at least you become aware of these WTFs and can find it out and can apply the right solution.There are many code quality measurement tools and how you can integrate those as part of the development process itself and how the team itself handles the quality awareness among the team members.

I am planning to cover this in details in separate blogs, each giving more insight of:

• how to learn more about the code quality aspects
• how you can measure the quality of code as part of regular development process
• how to share and organize code quality awareness among the team.

How to learn about Code Quality Aspects:

Many a times, developers write bad code because they are not aware of it. Having better understanding of the followings is a good start:

1. Focus on Fundamentals – OOPs and Design Patterns
2. How to write clean code – Clean Code
3. Figure out WTFs and improve code quality – Refactoring

Read Code Quality – Learn: OOPs, Desing Patterns, Clean Code and Refactoring fore more details.

What are different Code Quality Measurement Tools:

There are many open source tools available for static code analysis like PMD, Findbugs, CheckStyle, Simian, Cobertura etc. which you can integrate with in your project, may be part of your development process or application build process, to check the code quality.

Read Code Quality – Measurement (Static Code Analysis) Tools for more details.

How to organize quality awareness with in the team:

Different teams plan it different way to put a check on the quality standards and organize it in different way to share the knowledge and making people aware of quality standards and learning. We will be looking more into some of the ways like pair programming, share knowledge etc. that you can plan in Agile teams to make it more effective.

Read Code Quality – Organizing awareness with in the team for more details.

Like the technology thing in the software world is evolving and changing thing, so as these standards and principles. There is no single pill which can help you to get ready with it and can make you perfect or great programmer but definitely keeping these few things would definitely help you to be a good programmer.

Code Quality – Learn: OOPs, Desing Patterns, Clean Code and Refactoring

This article covers the second part of the series of articles Code Quality – Learn, Measure and Organize Awareness which is about the Code Quality – Learning code quality aspects, Using different code quality Measurement Tools and How to organize the awareness with in the team . Here we will discuss about the learning the fundamentals like OOPs concepts and Design Patterns, writing the clean code and how to approach to remove the bad smells from the code.

1. Focus on Fundamentals – OOPs and Design Patterns

2. How to write clean code – Clean Code

3. Figure out WTFs and improve code quality – Refactoring

1. Focus on Fundamentals – OOPs and Design Patterns

Looking at the history of Object Oriented Programming, it has come a long way and now a days, hopefully no one will neglect the importance and vast usage of these concepts in every system.

Importance:

Well in a way, Object-Oriented Design is a science and an art at the same time. Becoming a master of object-oriented technology would require experience and time. To give it a start have a look at the classic design patterns that have laid the foundation of object-oriented design, Design Patterns: Elements of Reusable Object-Oriented Software.

Material:

Lot of times many of the developer wonder that why to use these patterns, when to use and how to use them. Look for something which helps you to understand the patterns with the help of aids, models, examples, and discussions. Something like Head First Design Patterns.

Games:

Understanding the patterns in a way of conversation, discussion and solution for a problem would help you more to remember the idea behind it. There are people who plan it different way to help you with it in different ways, may be reading out the content like a lecture or to make it more interesting and learning friendly, you can also try it in the form of games. Like the Design Patterns Playing Cards using which you can try the learning part in the form of games, like Patterns Poker, Name That Pattern etc. which will help you to understand, learn and remember it in better way.

Use:

The responsibility now lies on you that how do you use these in the software development. Every software system has it own problem and solution they are trying to solve.

2. How to write clean code – Clean Code

In general terms we can say that the quality lies in the eyes of the beholder. It depends a lot on the individual perspective that how do you perceive the code quality. But think of it if someone else is reading or working on your code. There are some standards and principles which states whether the piece of code is of good or bad quality in context of the problem. That is what we will discuss here that how you can improve the awareness about these.

What is the main reason that developers write bad code? It varies from case to case like tight deadlines, motivation or may be lack of awareness. Many a times developers are not aware that what is the best way to put the solution in terms of lines of code.

The topic has been talked about many a times and by different people like Writing Clean Code or 7 tips on writing clean code

The one book which can give you more insight and explaining the real problems and context based solutions which I personally like is the Clean Code. For review please feel free to have a look at this Book Review and also very interesting comparison Clean Code vs. Implementation Pattern. And certainly few more enthusiastic who even say  Get it. Read it. Learn it. Then live it!.

The well illustrated examples, solutions in the context of the problems and the Heuristic Smells chapter can give you enough insight and can definitely help you to be a good if not great programmer.

3. Figure out WTFs and improve code quality – Refactoring

WTFs (Bad Smells)

Funny and irritating at the same time, what does it mean WTFs in the code.

The WTFs are the “Bad Smells” in the code which helps us recognize when we have a problem.

Few questions that may come into your mind:

• Why to put WTF?
• How to find out WTFs?
• What to do with WTFs?

As I stated it earlier also that no developer introducing these bad smells intentionally. Either you are not aware about the right approach or may be ignorance or time pressure.

To figure out these bad smells, either to take care when you are writing the code first time or when you revisit the code second time, may be during fixing bugs or adding new functionality.

Well remove the WTFs. Figure out what is the better  solution, if not the best. Refactoring is the solution for it.

Refactoring

A change made to the internal structure of software to make it easier to understand and cheaper to modify without changing its observable behavior.

Refactoring improves the design of your softwares, make it easy to read and modify and help you to find bugs.

There are plenty of books and documents available to help you to understand refactoring and to understand why, when and how to do it.

The one book I liked reading very much and would like to recommend is Refactoring: Improving the Design of Existing Code.

The starting chapter itself explains the common problems you must have seen in the code many a times and then refactoring the code step by step to reach a solution where in the end you can say it is good code. The common Bad Smells chapter will give you enough idea to figure out the WTFs in your existing code or the next time you are going to code. The different refactoring techniques will give you hold on the topics like the design patterns.

Refactoring Catalog

As in the case of patterns, refactorings  also have names  in order to crystallize  the idea and help us remember it.

For the latest and updated catalog look at the online Refactoring Catalog.

Refactoring Tools

The commonly used IDE like Eclipse and IntelliJ comes with inbuilt refactoring capabilities. These days most of the development tools come with some sort of refactoring support. For more, have a look at Refactoring Java Tools.

There is no single book which can make you master of it but certainly can help you to have better understanding of the concepts and ideas behind it so that next time you put few lines of code you know the pros and cons.

Code Quality – Measurement (Static Code Analysis) Tools

This article covers the third part of the series of articles Code Quality – Learn, Measure and Organize Awareness which is about the Code Quality – Learning code quality aspects, Using different code quality Measurement Tools and How to organize the awareness with in the team . Here we will discuss about the different static code analysis tools as code quality measurement tools which you can use to put a check on the quality of the code produced.

In my small experience of auditing, I have tried to mention these points a lot of times that many of the code quality issues are very common in every application and can be figured out at very early stage of the project. What lies behind of scenes in every project is more or less exposed in the code auditing process. A small story What is happening behind the scenes explains a bit about the common problems in terms of quality of code, which will give you some idea what we are talking about here.

Why Static Code Analysis:

Static code analysis can help you to figure out the possible coding errors in your software. You can gain real quality improvements in your software by integrating these SCA tools in your development process. What is better than finding these problems during development phase rather than once the software is live. These tools can do the first hand review of the piece of the code written by the developers.

SCA Tools:

The List static code analysis tools gives you plenty of tools available to use, some of which are open source and some of these are licensed. I am gonna mentioned few of these which I personally have used and definitely would like to recommend.

a) Clover & Cobertura (Test Coverage Measurement Tools)
b) Simian (Code Metrics Tool for code duplication)
c) PMD & FindBugs (Code Quality Tools)
d) Junit (Unit Testing Tool)
e) CheckStyle (Coding Style Violations Checking Tool)

Junit : Junit is a unit testing tool which gives the information regarding success rate of the test cases.

Clover : Clover is a powerful and highly configurable code coverage analysis tool. It discovers sections of code that are not being adequately exercised by your unit tests.

Simian : Simian (Similarity Analyser) identifies duplication in Java source code.

PMD : Scans Java source code and looks for potential problems like Possible bugs, Dead code, Suboptimal code, Overcomplicated expressions and Duplicate code.

Cobertura : Calculates the percentage of code accessed by tests.It can be used to identify which parts of your Java program are lacking test coverage. It is based on jcoverage.

Findbugs : FindBugs is a program which looks for bugs in Java code.

CheckStyle : Checkstyle is a development tool to help programmers write Java code that adheres to a coding standard.

Metrics : Provide metrics calculation and dependency analyzer plugin for the Eclipse platform. Measure various metrics with average and standard deviation and detect cycles in package and type dependencies and graph them.

XRadar : It gives measurements on standard software metrics such as package metrics and dependencies, code size and complexity, code duplications, coding violations and code-style violations.

Feel free to have a look at the few comparison metrics, Talking about SCA and Tools Review List .

How to use:

It depends on you that how you integrate these tools with in your development process. Either you can integrate these tools as part of your build process itself or can plan separate quality build to put the check on the code quality.

• Integrate with build process
• Separate quality build
• Dedicated time to find and fix quality problems

Enforce it:

You can also plan to force the quality check before some check-in the code in the code repository. Like SVN provides you pre-commit handlers etc. which you can run to check that the incoming piece of code is following these quality standards otherwise do not allow to check in the stuff.

WARNING!!!

In the end, still the SCA tools only will not solve the problem. As very well stated that these tools only give you the idea of under lying bigger problem, SCA just tip of the iceberg.

Code Quality – Organizing awareness with in the team

This article covers the fourth part of the series of articles Code Quality – Learn, Measure and Organize Awareness which is about the Code Quality – Learning code quality aspects, Using different code quality Measurement Tools and How to organize the awareness with in the team. Here we will discuss about how to organize the quality awareness with in the team.

Why to share code quality knowledge/learning?

Consider sharing code quality concepts knowledge something similar to sharing domain, functional or any other technical knowledge with in a project. In every project, you will always find people with different domain and technical knowledge and same goes for the code quality capabilities also. I hope we all agree upon how important knowledge sharing with in the team is and especially for the Agile teams. Even if you fix some code quality related issue in your project but until and unless you share it with others, the same people will be more prone to do the same mistake again. And if you don’t talk about the quality issues, people may loose the motivation and may be next time they will be more relaxed in doing same errors again.

How to share and organize code quality knowledge/learning?

It depends a lot on the team how they decide to go ahead with it and what suits the best to them. Depending on the team try to find out the best way to share this knowledge and organize awareness with in the team.

Some of the ways you can try and adopt are:

Pair Programming: The best way to do the instant code review and take design decision and quality discussion during the development time is by doing the pair programming. Two minds working on the same piece of code and giving feedback on the nature of the code at that moment itself help to solve the problem there only rather than post poning it for later code review.
Wiki: Some teams prefer to use wiki to store this information. Depending on the situations like distributed teams, new people joining the team very frequently etc. make more sense here to use some kind of wiki to keep this information so that it is available to everyone and all the times and can be referred later also. But sometimes it is hard to maintain these documents and these become irrelevant over a period of time, decision is on the team.
Coding Standards Document: I still remember that during initial programming days in waterfall project, we used to have such document so that everyone in the team follow the same coding practices which were used during code review for check list. Well, in Agile it is hard to follow such documents and it is irrelevant but still if it works for you then it is fine.
Mailing List:Some teams create separate mailing list to share the learning so that everyone receives it and the whole team is on the same page.Going through a mail is easier than going through a long document.
Fixing the issue and letting people know: When you find the quality issue, try to fix it and let the relevant person know about the changes so that they don’t make the same mistake again. In Agile teams, collective code ownership is the good example and try to make it work for you.

Depending on the teams, whether collocated or distributed, do whatever works for you. The collocated teams prefer to talk to the person directly because it reduces the communication time etc. which is difficult in case of distributed teams. In case of the distributed teams it is a bit harder to share this knowledge and many more questions rise like Is the cheap developers really cheap and as a team you try to solve these issues.

Few points that you should take care of and I would like to mention are:

On-going process: This is an on going process, prepare team to follow it continuously.
Share in positive way: Don’t shout on that who made the blunder with out fixing it. Fix it and share the learning in a positive way.
Motivate people to fix it and share: Motivate people to approach the bad code and make changes to it and encourage it.
Talk more about quality: Talk more about it with the team and the ways to improve it.
pair-up more: Put people with different technical expertise together more often.

All the teams work in different ways and it is hard to mention single thing which we can guarantee that will work best for all the team. In the end it is up to the team how it approaches the problem and what works for them. Talk to the team what should you do to over come the quality related issues and adopt over time.