Core S2 Software Solutions

Writing quality code

Older article from Lost in Dev; originally written by Jeremy Bridon.

What does quality code look like? From my experience, the majority of people agree that “good” code is the type that looks complex and is barely readable. Who in the world decided that crazy code is considered quality code? Have people, who say complex code is good code, worked in teams and real-world projects? Quality code can be written by simply following three practices:

  • Comment your code! I don’t mean comments every line or just a single comment at the start of a function. Don’t even bother using some corporate format or have some sort of over-kill comment structure. ”Use comments intelligently”; mark the sections that might be hard to follow and comment blocks of code that do only one step of your workflow or algorithm.
  • Stay away from complexity! Don’t write code that is so optimized it is unreadable, but don’t write code that is so big that it takes more than a few pages to understand what it does. It is hard to find a balance, but you can usually assume the compiler is smart and will optimize for you. Then again, don’t write code that can clearly be optimized by something that can still be mostly understood. Simply put: create code that logically follows steps and variable names that make sense. Stay away from deep-layered loops, keep your code as segmented as possible, and stay away from passing memory around through global variables or abuse of pointers.
  • Think before you code! I’ve already written about this, but it is critically important! Sit down and think of the exact structures and methods you will need before you even touch a single key on your keyboard. Drawing it out also helps discover design problems or unexpected corner cases.

Follow these three general tips and you will be fine. If you have been writing code at least a few months now, look at your first program and compare it with your latest. I’m sure you will realize you are naturally following, or at least beginning to, most of the above rules. If you are already a programmer, and still want to improve, pass your code to peers and ask them how they would do it. Go online and ask message boards to review code you write (make sure it isn’t legally protected by an NDA). Remember, programming is a mashup of art and science, there are always several good ways of solving the same problem.

If you are interested in quantifying code complexity, check out one of Microsoft’s blogs. The author explains the quantifications and actual mathematical approach to measuring code complexity. There exist several tools to also analyze quality of code, but nothing beats peer reviews.

Realistically, you also have to match run-times and development-times with your project goals, which makes writing quality code hard over time. Try to do it the first time, and if you don’t feel comfortable with something you wrote, write a comment (tip 1) and make a note to review it later.

This entry was posted in News & Updates. Bookmark the permalink.

Leave a Reply

Your email address will not be published.


*

Sites map