How to be good at coding? 5 simple tips to improve your code

I recently came across this comic on xkcd on code quality.

This got me to thinking what it takes to be good at coding. I have been writing code for more than a decade now and the one thing that I am sure about is that writing good code is hard work. What counts as “good” code anyway? I love what Bjarne Stroustup, the inventor of C+ and author of The C++ Programming Language has to say on the subject:

I like my code to be elegant and efficient. The

logic should be straightforward to make it hard

for bugs to hide, the dependencies minimal to

ease maintenance, error handling complete

according to an articulated strategy, and performance

close to optimal so as not to tempt people

to make the code messy with unprincipled

optimizations. Clean code does one thing well.

Good code is elegant and efficient. This begs another question in my mind. How do you develop the feel to know when a piece of code is elegant and efficient? I believe the answer lies in the art of craftmanship. To be a good craftsman you need knowledge and experience. This ultimately will allow you to develop a feel for writing good code. I can’t create a miracle and suddenly make you good at coding, but I can show you the strategies that I use to get the knowledge and experience to write good code.

Read lots of code

Believe it or not to write good code you need to read lots of code. You will encounter lots of code in your journey to writing good code. There will be lots of good code and lots of bad code. The more you read examples of good code and bad code the easier it gets to distinguish when you might be writing good code. What happens when you catch yourself writing bad code? This brings me to my next strategy.

Refactor

Try to transform the bad code you write into good code. There is an art to distinguish when you might need to refactor your code. Here are a few rules of thumbs to consider:

• Not meaningful names. Is it easy to understand what a variable / function is meant to do just from reading their names? There is a saying in the programming world, there are only two hard things to do in Computer Science: cache invalidation and naming things. Give this a careful thought.
• Too many comments. Comments do not make up for bad code. If it is hard to determine the intent of your code in the absence of comments, chances are high that your code needs to be refactored to make it simpler to understand.
• Inconsistent formatting. Let’s be clear that good and consistent formatting is important. Writing good code is about making it easy for others to read you code. It is hard to read code with inconsistent formatting. Use a linter with a publicly maintained standard like the PEP 8 style guide for python code. https://www.python.org/dev/peps/pep-0008/
• Code that is hard to test or worst not possible to test. Consider the Three Laws of Test Driven Development:
  1. You may not write production code until you have written a failing unit test.
  2. You may not write more of a unit test than is sufficient to fail, and not compiling is failing.
  3. You may not write production code than is sufficient to pass the currently failing test.

Learn the basics of coding techniques

The fundamentals of good coding carry across languages no matter the tools. Learn how to use and apply common design patterns to your code. Don’t reinvent the world, a lot of problems in programming are solved problems. Use techniques that have withstood the test of time.

Incorporate play time into your coding routine

Write code just for fun and enjoy the process of discovery and continuous learning. Keep up with industry trends and see what other people are doing. This will allow you to explore the boundaries of your current knowledge.

Work in companies of different sizes

Learn how big, medium and small companies manage changes around software. Get experience on how to best write your code that will produce the most value for your company. Writing code is a means to an end. Don’t lose sight of that end goal.

I can keep writing on this subject forever, but I think this is a good start to kickstart your journey to writing good code.