Despite its name, computer “code” should ideally be as readable as possible, and not just by those with the secret key. Naturally, there is plenty of discussion on this subject to be found on the Internet, including plenty of examples of both good and bad practices.
According to the Codacy blog, there are many recommended practices to follow when creating clean, readable code. One of these is adhering to the “single responsibility principle” (SRP), meaning that functions should only do one thing each. This directly relates to The Power of 10 Rules from NASA, which includes a declaration that functions should fit within a single printed page or terminal window. A long function with many responsibilities is not only difficult to understand, but hard to update and debug without affecting other portions of the code.
I have found that it is often easy to get caught up while programming and accidentally create overly complex functions that really should be split into several smaller ones. This impacts my ability to understand and refactor my code, let alone others, so I would like to try and focus on following the SRP more often.
On the flip side of things, there are plenty of code “smells” to avoid. Attila Fejér (via Baeldung) writes about several common groups, including a type of smells called “bloaters”. These are constructs in a program that are too large to be effectively worked with, such as a function or class that goes on for far too many lines (like the issue described above). Fixing this smell often includes grouping together related elements, such as commonly-used pieces of data or functions. In other words, it’s best to refactor your code so that you don’t have to repeat yourself (which happens to be another clean coding practice!). I would like to try and consciously avoid this smell more often, as it affects many different areas within a program, making it a potentially very efficient way to ensure my code stays readable.*
*Except, of course, when I’m writing a secret message.
