The Strange Case of Code Writing.

Recently, I got to read and work on the code of a project I was assigned to take over. And when I looked at the code, I was thoroughly confused. This confusion is in part due to the complicated structure and the fact that I wasn’t quite familiar with React and Redux just yet. But besides that, the code itself was highly abstracted and had a painful (it felt painful) lack of comments.

I’m never one to be biased against any kind of working approach, so while I wasn’t used to this coding style, I wanted to learn why it was written that way—there must a reason to this approach. So when I did a quick googling for the case for and against comments, I found this probably already popular page that contains plenty of comments for and against the insertion of comments in code.

And you know what? Nobody is right, just as nobody is wrong.

If code is well written, then we don’t need comments as a crutch? Maybe—or rather, sometimes. Coz if a new developer comes in and doesn’t understand the project or that quirky piece of code written just for that rare case, then he or she is going to have to spend lots of time scratching heads without proper accompanying comments. Worse still if another developer has to come in and explain what’s going on. If some form of comments have been provided, it might help save everyone’s time.

Again, there is no right or wrong. This is what I strongly believe. Any one approach has its advantages and disadvantages, so when we pick one approach, we learn to live with its imperfection. Plus, everyone is different. And code writing is, no matter how many compilers and linters you put in place, really quite a free form of exercise. The coder has the ability to exercise his or her discretion with every line of code, and it doesn’t make sense to demand everyone write the same way—you might as well get a robot write the code. Hell, even robots thrive on human programmers’ inconsistent code.

The interesting thing about code writing, though, is the fact that this free form of expression is tied directly to functionality. So there now seem to exist a basis for right or wrong. If the code written one way runs faster, then it must be better right? Nope. If code written in a highly abstracted way makes the program run fast, but cost other developers an absurd amount of time trying to make sense of the abstraction, then that means an overall loss in productivity. Even the idea that faster is better is questionable: sometimes a bit of waiting can provide some users (again, everyone is different) with a sense of security that yes, things are happening.

A bit of waiting can provide some users with a sense of security.

And so yes, humans beings are different. And more importantly, humans are imperfect. The idea and expectation of perfectly written code is, sadly, just the wishful thinking of overly idealistic programmers. We’ve all had the occasion when we look at the code of some program written by someone who has left the company and complained: that code sucks. But of course the programmers had done their best back then, when that way of writing was the norm, or the best practice. Best practices change, and programming as a profession changes (we can only hope, for the better). Even users change with time. At the end of the day, as coders, all we can do is to trust that our predecessors have tried their best, and work from there. You may believe your way is better and make what you think are necessary changes, but some day down the road someone else is going to look at your work and goes, this piece of code sucks. It’s evidence of the industry having evolved, I suppose.

Finally, my opinion on this is that how code should be written should fit the team more than anything else. Since no one approach is perfect, the only way to go about this is to pick the one imperfect approach that best fits the team, right now.

In that sense, perhaps, there is no such thing as good or bad code, only code (work) in progress. Or maybe I’m too idealistic?