Coding practices your future self will love you for

Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live.

• Martin Golding

Here are 6 coding practices that I've adopted in the past 10 years to ensure that my future self has fewer sins to forgive.

1. Standardize code formatting

Any codebase is read a lot more than it is written. Code with consistent formatting is easily readable and comprehensible for everyone in the team. Standard formatting ensures that your eye, and your subconscious, can look for variables, braces, functions, etc seamlessly. Golang does a great job by providing the gofmt command in the standard library. This ended all formatting discussions that come up so often in code reviews in the Golang community.

2. Don't follow the DRY principle blindly 

DRY (Don't Repeat Yourself) is almost a mantra for developers. But if applied indiscriminately, it leads to abstract code that’s hard to read & understand. It also stops different parts of the code to evolve to their full potential. Do not follow the DRY principle blindly. 

It is a good idea to copy-paste the same function a minimum two times in the codebase. Only when you see the same requirement a third time, should you refactor the code and apply DRY. Doing this ensures that you are not prematurely assuming that two problems that looked the same initially, are still going to remain the same after a period of time. When you come across a similar requirement a third time, you have some data on what parts of the code are common. You also have three instances of repeated code to create a good abstraction. 

3. Debug code via logs 

Practice debugging code on your local machine via logs instead of a debugger. Debugging on your local machine ensures that logs are added at the right place. This, in turn, makes sure that you can debug production issues quickly because you would have gone through this cycle on your local machine before. Remember to not get too excited and add unnecessary logs everywhere. It will clutter your log file in production.

Too much logging == no logging.

4. Beware of premature optimizations

A primary goal of code optimisation is to improve performance. More often than not, performance issues are not where you think they are. Always benchmark your code before starting to optimize for performance. Without benchmarking, how will you ever know whether the code changes you make have any real impact on efficiency or not? Premature optimization, especially micro-optimization, is not a good idea because you don’t know whether you are working on removing a performance bottle-neck or not.

As a corollary, this doesn't give you the license to code like the wild west. Don't get the computer to do work that it doesn’t need to do just because you got lazy and didn't think of the most efficient way of solving a problem.

5. Don't complicate your codebase with unnecessary features

Don’t complicate the codebase with features that no user has asked for. This is a problem you need to avoid in early product lifecycles. Startup teams tend to assume that building more features will help them find product-market fit faster. This is an anti-pattern. Adding unnecessary features makes the code harder to read & debug. When new developers come on board, they will find it difficult to differentiate important code paths from the ones that were added on a whim. Eventually this technical debt slows the entire team down.

6. Setup a CI/CD pipeline early in the development lifecycle

Even if it’s a one-wo/man show, a CI/CD pipeline reduces the overhead of remembering (& doing) the build & deployment of a particular codebase. The common assumption is that CI/CD pipelines are important only in teams that are pushing a lot of code into production every day. In my experience, CI/CD pipelines are even more important for codebases that are rarely touched because you won’t remember how & where the code was deployed. This is especially true if you are updating the code only once a year. Plus, having a CI/CD pipeline ensures that you have a version-controlled script telling you exactly what you were thinking X months ago. 

---

What other practices have you followed to prevent your future self from hanging themselves? 😜

---

I share TL;DR versions of articles on software engineering that I read every weekday through my newsletter - in.snippets(). Sign up here if you want to learn something relevant every day.

Comments

[Akshay Madhan]

Super article

[veterant]

Take advantage of goormIDE.
goormIDE is a fantastic cloud based IDE and it's free!

[Humberto A Sanchez II]

Unit test, unit test, unit test.

[Gaurav]

Really love this post Mohan

[gthomas2]

I almost was guilty of number 5 today until my teammates wised me up in scrum.

[Szymon Przedwojski]

Good points, Arpit!
About loggind I'd add that it's a good practice to introduce different log levels, e.g. ERROR, INFO, DEBUG, TRACE. This way you can have different amount and detail of logs on different environments and possibly you can also just change an env variable to change the log levels on production if you have issues there.

[Tony Ross]

Absolutely SPOT-ON! Thank you for this.

[Edelberto Enrique Reyes]

Thanks for the article.

[Dirty-Co.de]

"Too much logging == no logging." - cannot agree more on this one! I use logs a lot especially when writing JavaScript code and when I find myself filtering in my own logs I know, I've logged too much and I start cleaning up my logging :)

[Damindo]

Good share, thank you.
So now "best practices" are adopted in fear of "the violent psychopath" joke :)

What happened to "We don't negotiate with terrorists" ?

[martinakuzniecowa]

thank very usefull

[Marcos Costa Pinto]

Thanks for the great tips!

I'll try to debug locally using logs, I'm sure that will help me ship code more observable to production.

[Jacob McCrumb]

I stopped in because title looked promising, read on with a chuckle because of that initial quote, and stayed til the end cause it was all good content. Thanks for the write up!

[Diego Ponciano]

Lovely totally agree. I'd say human-to-human comments explaining things does not hurt at all also. Well, after you know how to write a proper comment/doc block, create it so that other human can easily pick up, even provide an example if necessary. Comments are for humans not for computers. Also write your code as if you were having a human conversation as far as possible, writing function names and classes so that they make sense and are rather elegant during usage. Some storytelling never hurt no programmer ;) if you know what I mean. Have a conversation while you program, even vocalize it.

[Manuele J Sarfatti]

Love it! And it's a good reminder not just for beginners!

I would add a number 7:
Write test, just a few, for the most complex parts.

[Arpit Mohan]

Thank you!

Testing is definitely required! Not just for the complex parts, but for the simple ones as well. You never know when the simple part becomes complex :)

[Manuele J Sarfatti]

I agree, but if testing is not part of your routine starting with "test absolutely everything" will result overwhelming and you may just give up entirely.

A good approach is to start where it hurts. Then add tests for every bug you find. Then if you still have time and budget feel free to go all in!

It also depends if you are building a library (I'd test as close to 100% as possible in that case) or a Gatsby website (I'd maybe only test a few UI components)