Clean code and the practice of programming

"Should I be descriptive or can I be lazy?"

When you are teaching yourself, it's easy to pick up bad habits or style because you don’t have someone checking your work. You don’t have many reference points for clean code because not many books/courses directly address these.

So, I want this newsletter to be your reference point for building your intuitions about beautiful code and good programming practices.

Here are 4 guiding principles that I personally follow to keep my code clean:

  1. Don’t settle for “it runs”.

  2. Write for readability - code is read more often than it is written.

  3. Explicit is better than implicit.

  4. Duplication may be the root of all evil in software.

These should help guide you when you are making decisions about designing your code.

I also want to share some more specific, actionable pieces of advice.

5 simple, actionable, good programming practices:

  1. Put some thought into choosing your variables’ names -
    Don’t be lazy with long descriptive names. Remember, most IDEs can autocomplete your variable names.

  2. Create new functions whenever necessary
    It is easy to understand the syntax of writing functions in your favorite language. But it takes practice and some sense of design to learn when to break the code into functions. You need to write small functions with descriptive names that do only one thing.

  3. Document your code and write helpful comments
    Remember, “documentation is a love letter that you write to your future self.” :p

  4. Be consistent in your coding style
    Consistent coding style is good coding style. It makes it easy for someone (including you, yourself) to dive into your code and read it in the future.

  5. If it breaks, assume that it’s (probably) your fault
    You are likely to spend a majority of your coding time banging your head over broken code. In those moments, you will inevitably try to shift the blame to your IDE, compiler, environment or your machine. But you should remember - It's not the computer, it's you. Only when you do that, will you be able to diagnose and get to the heart of the problem (even if it is some problem with the machine).


Here are the 2 books that really helped form my own intuitions:

  1. Bob Martin's book Clean Code

  2. Brian W. Kerninghan’s book - The Practice of Programming

"The purpose of style is to make the code easy to read for yourself and others, and good style is crucial to good programming."

-Brian W. Kerninghan in his book - The Practice of Programming

I have written and published a detailed article about this called - Writing Clean Code and The Practice of Programming: Actionable advice for beginners. Check it out if you want to read a more detailed version of this newsletter!

Thanks a lot for reading! This was the Build To Learn newsletter and you can subscribe to it here.

If you think that coder friend of yours might find this newsletter useful as well, please forward it to him/her. :)

Also, if you have other such best principles that you follow, please let me know by replying to this email or reaching out to me on either Twitter or LinkedIn.

Finally, if you liked what you read, please hit the hardly-visible heart icon below. It will help in improving the visibility of this newsletter on Substack - the platform that hosts Build To Learn :-)