Clean code and the practice of programming
"Should I be descriptive or can I be lazy?"
|Build To Learn||Nov 29, 2019|| 5|
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:
Don’t settle for “it runs”.
Write for readability - code is read more often than it is written.
Explicit is better than implicit.
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:
Put some thought into choosing your variables’ names -
Don’t be lazy with long descriptive names. Remember, most IDEs can autocomplete your variable names.
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.
Document your code and write helpful comments
Remember, “documentation is a love letter that you write to your future self.” :p
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.
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:
"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!
If you think that coder friend of yours might find this newsletter useful as well, please forward it to him/her. :)
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 :-)