Code Quality – Learn, Measure and Organize Awareness
Posted by Jai on April 12, 2009
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.
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:
- Focus on Fundamentals – OOPs and Design Patterns
- How to write clean code – Clean Code
- 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.
Jai's Weblog - Tech, Security & Fun... 
Erik Costlow said
This is a great series of posts, thanks for publishing them. I’ve been dealing with a lot of “bad code” lately and your sources will help me explain a good course of action for cleaning it up.
Code Quality « CostlowCorp said
[…] https://jaibeermalik.wordpress.com/2009/04/12/code-quality-learn-measure-and-organize-awareness/ […]
Chris Treber said
Hi,
“It’s harder to read code than to write it.”
Only because code looks like what it unfortunately most often looks like “these days” (I’m implying here that code often could look much better than it does).
As a programmer you have to understand the specification, clarify details, design a solution, code it, realize wrong assumptions you made, improve the design because of the insights you gained and because of code smells you can’t stand any more, refactor for clarity since sometimes you don’t quite understand anymore what that piece of code does, and correct bug fixes.
All in all there is a lot of work until the code is done. And if the code is done well (correct function being the minimum requirement that you won’t get any praise for), it is readable by humans – not only the compiler – with reasonable effort.
Good code exists; every now and then I stumble across some. The names of classes, fields, methods, and variables are well chosen and accurately and reliably reflect the function (no “verify()” that changes the DB contents, and “imageCount”, guess what, counts images – who knows what “j” and “counter” are counting). The code almost reads like pseudo-code and pretty much *is* the documentation. The size of classes and methods is reasonable. Packages group code into (largely independent) modules or components. The code is so easy and painless to understand one would think either the program or the programmer is primitive, but the application rocks.
I think “It’s much easier to read good code than to write it”; at least is very much should be that way.
Cheers!
Chris
P.S.: Very good article series, BTW.
Brownfield Application Development in .NET: Book Review at Mark Needham said
[…] code easier to understand. I recently read a blog post by Jaibeer Malik where he claims that it is harder to read code than to write code which I think is certainly true in some […]