To be able to code is a skill, which needs good knowledge to be appreciated. And I can say that many developers aren’t able to perceive the art behind a piece of code when they see it.
Each one of us has our own way of writing those magical lines. Some use white-spaces while some press a tab; some use comments while others find them useless. As time passes, it’s not just the quality of code that gets upgraded, but the practices followed as well. Here, I have tried to sum up the best coding practices, which may seem trivial to a few readers, but are certainly not something to be overlooked. For new programmers, these can be the mantras that will stick with them till the end. So why not dive right into it!
Writing readable code
On the surface, readability may seem subjective, something which may vary with languages, codebases, and teams. But when you look underneath, there are core elements within all pieces of code that make them readable. Here are a few of the good practices that I’ve learned throughout my experience with coding:
Understanding Version Control
Whether it is for personal projects or organization-level projects, version control is one of the most important skills for a developer. It is a tool that helps developers/programmers to tackle some everyday problems, such as tracking changes in the code, maintaining code, and allowing them to work on the same source code files without affecting each other’s workflow.
Version control in itself has become one of the essential parts of a programmer’s life. Using a VCS has various benefits like:
VCS may sound very sketchy to a few, but honestly, it is not. It is just one of the toolkits designed to make a developer’s life easy-peasy, although…
The art of googling bugs — Debugging
Coders spend long hours debugging, staring at the codebase, and figuring out what exactly went wrong. That’s something ubiquitous among developers who don’t know the correct techniques to find the bugs and fix them. It becomes easy to learn the correct approach to follow to kill that bug hidden inside your code like those cockroaches in your kitchen.
Good documentation
Being able to write good code is good, but being able to write good docs, well… that’s a talent. But why write those lengthy docs after hours of code writing? The answer to this question is simple: to tell other people about your code’s key features.
Documenting your programs is considered one of the best practices in a coding culture. It helps not only others but also ourselves. A good way to start would be simply updating README.md for your projects. Remembering large chunks of codes can be hard sometimes (actually most of the time), but going through well-framed docs can help you to understand the code later at some point of time while you might be scratching your head trying to understand why you wrote that particular part of the code.
People often think that the value of docs is subjective or unquantifiable. This is rarely the case.
The value of writing is that it can be written once and shared many times, whereas in-person or real-time communication forms need to be repeated each time a new person needs the information.
The question here is not “How” to document but “What” to document?
Okay, so what shouldn’t be documented then? Even that has an answer.
So much for the value of a doc.
What about the quality of a doc? Isn’t this subjective?
No. Not at all. Doc has a job to do. It is good inasmuch as it accomplishes that task; that is an absolute and completely objective standard to the quality of technical documentation. Suppose I write a document for experienced Kotlin engineers and, out of 100 engineers, 23 understand it. No matter how smart I think I am, I have failed. That score will save very few people any time.
Good docs follow the 4C principle, which says that your documentation should be:
Well yeah, that’s all you need to know to become a good programmer. It is not easy, but it is a skill that one can develop by practice.