Making Good Software

A blog by Alberto G (Alberto Gutierrez)

Written by Alberto Gutierrez

October 20th, 2009 at 3:06 am

5 practices to create good code.

with 6 comments

A few weeks ago I published “10 commandments for creating good code”, the article was focused on the physic code characteristics but it didn’t mention anything about best practices to follow to produce such code, to compliment it in this article I would like to present what in my opinion are the five more important practices to take into consideration to create good code.

Keep it simple

I strongly believe that the number one problem with unreadable code is over engineering, we learn so many techniques, frameworks, tools, patterns… that we actually believe that if we can use them, we should use them, and it actually should be the opposite, the best solution is always the simplest solution, remember: “There are no hard problems, only hard solutions”.

As I wrote in a previous post, there are four main traps that may keep you away from keeping things easy:

  1. If all you have is a hammer, everything looks like a nail.
  2. Because you can, It doesn’t mean you should.
  3. The more things that can fail, the more things that will fail.
  4. The more prepared is your code for change, the more difficult is to change your code.

Visit the article: For god’s sake! Keep it simple! to see a detailed explanation on these 4 traps

Make it work, then make it fast.

“The best is the enemy of the good.” Voltaire

“More computing sins are committed in the name of efficiency (without necessarily achieving it) than for any other single reason – including blind stupidity.” W.A. Wulf

“We should forget about small efficiencies, say about 97% of the time: Premature optimization is the root of all evil.” Donald Knuth

I took all the previous quotes from two excellent articles from Cunningham and Cunningham, “Make it work, make it right, make it fast“, “Rules of optimization”

Automated Test

They are great to:

  • Perform regression testing
  • Help you design new code
  • Validate your new code
  • Boost your productivity

Test early, test often, test automatically! If you are interested in further reading, you might want to check out: How to write a good test case and Top 5 considerations to build software without defects.

Code reviews.

My five tips on code reviews are:

  1. Make your code reviews often. At least once a day.
  2. Make your code review short and Informal. Something like: “Hi Mike! You mind coming over to my for a quick code review”
  3. Make your code review with different reviewers.
  4. Keep a positive attitude.
  5. Learn to enjoy the code reviews. A code review should be seen as a learning opportunity

For more details check the article 5 tips to make good code reviews.

A special mention deserves pair programming, pair programming is the ultimate way of code reviewing, not only makes code reviews unnecessary, but it also increases the code quality and the productivity.

Refactor.

One of the biggest recent mindset changes is from refactor = bad to refactor = good, saying that refactor is good is saying that you know that you are going to make mistakes, but that you are going to be ready to fix them, that’s quite different from the refatoring is bad mindset, where you put a lot of effort in not making mistakes, which is obviously wasted because, let’s face it, that’s impossible.

6 Responses to '5 practices to create good code.'

Subscribe to comments with RSS or TrackBack to '5 practices to create good code.'.

  1. Thanks for the pointers. For code review and automated tests, a lot of companies are now inserting a static analysis step to analyze source code for potential flaws. Code analysis tools have come a long way from the LINT days and can add significant value with less noise.

    Andy

    20 Oct 09 at 8:16 am

  2. [...] Usability Testing seit Langem: http://bit.ly/tsNs8 #usability #uxCoding: 5 Tipps für besseren Code http://bit.ly/UHbBb #skillsApple kündigt signifikante Produktupdates an: http://bit.ly/1rIYeV #appleSo: Powerpack ist [...]

  3. [...] This post was mentioned on Twitter by Camille Roux and rroldan, Eric. Eric said: 分享 http://tinyurl.com/ygxaksd (5 practices to create good code.) via Making Good Software http://plurk.com/p/2c3d5c [...]

  4. Alberto,

    I couldn’t agree with you any more regarding Keep it Simple. I just wrote a post about Complexity vs. Simplicity.

    Just because you CAN make an application complex doesn’t mean you SHOULD.

    Great post.

    JD

    Jonathan Danylko

    21 Oct 09 at 5:45 am

  5. Good points, I’ve tweeted about it as well…www.twitter.com/alenzukich

    Alen Zukich

    21 Oct 09 at 6:23 am

  6. All true. I would add *unit* to the Automated Test point.

    Giorgio Sironi

    22 Oct 09 at 8:32 am

Leave a Reply