Geeks With Blogs
Ram Kinkar Pandey
What is a good code and how can we write a more object oriented code?
Sometimes I heard my team members complaining about the quality of code which I wrote, so I started a search for some instructions about “What is a good code?”
I went through “Agile Priniciples, Patterns and Practices in C# by Robert C. Martin”, “Refactoring by Martin Fowler” and “Head first Design Patterns from O’Reilly press” and found some useful tips.
So before going through those tips, let’s start with what is bad code?
The most common criterion which is responsible for bad design(in real life) is “TNTWIWHDI” means “That’s not the way I would have done it” so this should not be a criteria for declaring a code piece be bad code. But the main criteria should be
a)     Rigidity: - It is hard to change because every change affects too many other parts of the system.
b)     Fragility: - When you make a change, unexpected parts of the system break.
c)     Immobility: - It is hard to reuse in another application because it cannot be disentangled from the current application.
d)     Viscosity: - It’s hard to do right things but easy to do wrong things.
For avoiding above causes and writing good code experts have accumulated 10 OOAD (Object orientation analysis and design) principles.
1)     Open Closed Principle (OCP): - Code should be open for extension and close for modification.
2)     Liskov Substitution Principle (LSP): - Every function which operates upon a reference or a pointer to a base class should be able to operate upon derivatives of that base class without knowing it.
3)     Dependency Inversion Principle (DIP): - High level modules should not depend upon low level modules. Both should depend upon abstraction. Abstraction should not depend upon details. Details should depend upon abstraction.
4)     Interface segregation Principle (ISP): - Client should not be forced to depend upon interfaces that they do not use. Many client specific interface are better then one general purpose interface.
5)     Release Reuse Equivalency Principle (REP): - The granule of reuse is the granule of release. Users will be unwilling to use the element if they need or forced to upgrade every time author changes it.
6)     Common Closure Principle (CCP): - Classes those changes together belong together. The more packages that change in any given release, the greater the work to rebuild, test and deploy the release. So they should be grouped together.
7)     Common Reuse Principle (CRP): - Classes that are not used together should not be grouped together. A dependency upon a package is a dependency upon everything in the package. When a package changes, and its release number is bumped , all clients of that package must verify that they work with the new package even if nothing they used within package actually changed.
8)     Acyclic Dependencies Principle (ADP): - The dependencies between packages must not form cycles.
9)     Stable Dependencies Principle (SDP): - Depend in the direction of stability. A package with lots of incoming dependencies is very stable because it requires a great deal of work to reconcile any changes with all the dependent packages.
10) Stable Abstraction Principle (SAP): - Stable packages should be abstract packages. The SAP I sjust a restatement of the DIP. It states that the packages that are most dependent upon (i.e. stable) should also be most abstract.
So I think that if we all try to follow these principles then our code quality will be mush better and easy to maintain.
And one more thing most of these experts were convinced that a code following all the principles described above is not possible but we should try to follow most of them until there is a suitable reason for not following any.
Details of all of these design principles are availabe on and book published by Robert C. Martin but i would still like to describe all of these on my blog and will try to relate the with different design patterns.
Posted on Saturday, October 3, 2009 12:50 PM Design Principles | Back to top

Comments on this post: How to write a good code?

# re: How to write a good code?
Requesting Gravatar...
I completely agree to the above principles and try to follow them as much as I can.

Nevertheless, I think your list is a bit too academic. At the end of the day, it is a fact that good code is only good if your company makes money with it. Sometimes, quality has to be reduced to speed up time to market, or there's a one-shot project where it wouldn't make much sense to invest a lot of effort in maintainability. So these criteria have to be balanced with the specific business needs on a project-by-project basis...

What I am also missing from the above list is readability: If your code will likely be read by someone else (and which code does not) and has to be maintained for a couple of years, then one of the most important (but often overlooked) questions is: How hard or easy is it to read and understand the source code. As a freelancer who regularly does code reviews and other maintenance-related stuff, I can say: On and the same source code is at least twice as hard to read and understand if there are no such things as meaningful identifier names or a consistent naming strategy etc. On the other hand it's easier to refactor bad code if it is easy to understand. This is the single most important point where companies gain or loose money...

- Thomas
Left by Thomas Weller on Oct 04, 2009 6:24 AM

# re: How to write a good code?
Requesting Gravatar...
I agree with most of yours points and yes readibility is one of the most important thing which is missing from above post. But as you said that above topics are bit more acedemic i donot completely agree with that, as it may seems acedemic but when you will relate this with design patterns whcih we like to implement always then these makes lots of sense. And for some time that code could be good if yours company makes money out of that but when you think maintainence wise then code should be well refactored, readable and easy to accomodate new things.
Thanks for your comments, since next i would try not to forget some of the important things.
Ram Pandey
Left by Ram Kinkar Pandey on Oct 07, 2009 4:02 PM

# re: How to write a good code?
Requesting Gravatar...
I agree with you on the above principles and most of the times we try to use these principles to write a loose coupled code for future extension but I have seen projects that are too complex and exists for 4-5 years, in such cases only few of the principles will be applicable, it becomes difficult to refactor such type of code. So, what to do in such cases??
Left by Rakesh Kumar on Nov 03, 2009 11:04 PM

# re: How to write a good code?
Requesting Gravatar...
Hey Rakesh,
You can do much with those legacy codes if you are allowed to modify those. So what can i suggest is that you never think anycode as legacy and if you get any chance to modify that code then first refactor that peice of code (make it sure that you first write a unit test around that code, it will make it sure that you are not breaking functionality), So this process is going to be slow but a constructive process. I would recommend that you should go through book by
"Refactoring: Improving the Design of Existing Code" by Martin Fowler. This book contains much stuff regarding how to refactor code even legacy code.
Left by Ram Kinkar Pandey on Nov 14, 2009 9:58 AM

# re: How to write a good code?
Requesting Gravatar...
Are there any guidelines? There are many programmers in our office and each of them has his own style. How do they agree on a style they can all use?
Left by reseller on Mar 29, 2010 7:59 PM

# re: How to write a good code?
Requesting Gravatar...

Brilliantly put.
Left by Cheap UGG Boots UK on Nov 10, 2010 4:27 AM

Your comment:
 (will show your gravatar)

Copyright © ramkinkarpandey | Powered by: