Trick lies in the thought process, not in the syntax!

by Kshish Ashish | Oct 3, 2017

If you didn’t get this, you are probably running on java too.Programming my friend is like a novel. Except that if you missed that stupid semi-colon on page five and fifty nine, the entire thing is useless.Humans have been with tackling the knick-knacks of computer programming for for about fifty long years but still in comparison to the grand world of technique and skills, coding is still just a toddler, colliding with walls, stumbling alongside, and occasionally throwing tantrums in a party. As a consequence of its relative age, there seems to be a lot of discrepancy over what is categorised as a “GOOD CODE”.

We could say that maybe a “good code” has 100% test coverage. We could say it should be quick and efficient, runs acceptably on a decade old hardware. While these are all commendable achievements for software developers, Let’s throw in a few more things into the mix .First and foremost thing that comes to mind is MAINTAINABILITY because if it can’t be comprehended, maintained and extended by others, the chances are that your code will not be in use soon for the sprint of time it was created in so you can definitely do better.A lot of other qualities that tend to correlate with maintainable, “good” software would be proper object-oriented design, elegance , language constructs, environment capabilities, modularity, efficiency, and simplicity.

Now I know how life of a programmer works and I’m sure all those who have never coded before do too. If you have ever been stuck amidst a problem you had no clue you had and in a way you don’t understand, then you have already experienced the life of a programmer. As a consequence of which, programmer settle for a code that just “WORKS”. But a code or we should say, a user, needs a lot more than that.

#1: How would you want someone else’s code to treat you?

Focus on Reviewability, Modifiability, Debugging, Comprehensibility and Error rate.

Communication is the key behind the quest for the Holy Grail of Programming.The computer wont care whether your code solves a real time problem. It cares about binary machine instructions and syntaxes. Readability ensures that your programme is understood by those who use it as well as those who can help you increase its efficiency.Remember that you have to write for the primary audience for your code ( not the compiler or the computer) , whosoever next has to maintain, and enhance it (which may not be you a few months down the lane).

Assuming we ourselves judge a programming language by its own ease of use and capability of writing good code. This had to be one of the top criteria.

#2: Avoid the “Did I really write that?” syndrome.

Good code is easily comprehended, in part and as a whole, by others as well as by the programmer in the future. “In part” refers to the fact that every function and module should be self explanatory. Otherwise a code that has no independent readability and continuously handovers minute attributes of the codebase for references from the rest of the code seems like a book with references, footnotes or an appendix at the end of every sentence. You’d never make the mistake of reading it. Make each part of the codebase subject to least possible number of such concerns.

#3: Names have magic powers.


Names seem to activate thinking and guide the system the way in which the brain forms thoughts. So you have to put a great deal of efforts, careful thought into method and variable names. This negligible time investment would pay significant dividends. Orchestrating the right variable identifier makes the code intuitive. Otherwise, its just a bunch of lines that give you headaches and confusion.

#4:Cleverness is the enemy.

When working with fancy programming techniques, operations or paradigms (such as ternary operators or list comprehensions), use them carefully and in a way such that it doesn’t affect the readability . Be consistent. Consistency in the way you code, in terms of how you place those braces as well as the operations, improves readability greatly. Also keep in mind your algorithm. Algorithm is that word which every programmer uses when he/she can’t explain what the hell is going on. But seriously, its the base of your code and its what makes it efficient. Develop the habit of working on the Algorithm first (Sooner, the better!).

The last thing that you must certainly see to is that “you don’t reinvent the wheel when you have the option of standing on the shoulder of giants”. Someone out there could have already designed a way that you can leverage. Take your time to ponder over any such options, if apt and available. Definitely, the more frequent and efficient the code you’re dependent upon is, lesser is the time investment for maintenance. But keep in mind that by using an open source library or an unfamiliar source adds some interesting functionality, you become dependent and liable to that particular library. It’s a huge commitment; if it’s a grand library and all you require is a fragment of it, do you really want to carry the burden of the entire library? Bottom line being that it’s constructive to complete your own research and evaluate whether or not is it logical to include external technological know-hows.

Thank you for reading!