Good code Vs Bad code

When writing code in any language, there are good coding practices and there are really bad ones. Both may be correct as far as compiling and when run, but bad code can present some problems in development, debugging, and modifying. In the workforce, no matter how well your program runs, someone will have to read and/or alter your code at some point. They may have to add new features, correct a rare bug, or just want to read it to understand how it works. Similarly, you will have to read someone else’s code to do the same thing. Everyone will get along a whole lot better if the code is readable and understandable.

Importance of good quality code : To know the importance of good quality code let’s try to understand what bad quality of code can lead to : A badly written code could lead to financial losses or waste of time needed for further maintenance, enhancements or adjustments to a software.

You write your code once but then follow it numerous times after, hence documenting your code becomes really important, naming conventions become really important. 

Many a times I come across my colleagues joking about how they do not remember what code or logic did they write a few days ago now couple it with writing bad code style and you will take more tome time to understand what you did compared to the when you did it. Things start to go haywire when an artist fails to understand their own piece of art ??????

Some key points to keep in mind while writing code

Code comments to the rescue : Most modern languages have declarative documented comments and their use in conjunction with single and multi line comments makes code more understandable and hence maintainable.  Good code comments explain why things are done not what is done. The code itself explains what is done. The need for comments should be minimal.

Indentation : Good code is properly structured as shown in the figure. It should be obvious for the person trying to understand code where a block of code starts and where does it end so that following the logic of the code base becomes evident and straight forward.

Readme’s : It is annoying when you have a project’s code base in front of you but set up and first execution takes hours to get you rolling. This is where readme’s come handy. It is always better to have a brief intro to a project before you access the code and a properly structured Readme does exactly that.

Naming Conventions : Many a times we come across a class by the name Apimanager, looking at that name the purpose of class is not clear. According to best coding practice norms our classes should follow single responsibility principle and proper naming conventions coupled with SRP make our lives much easier while trying to follow a project. Naming conventions should also vary for different scopes if a class is performing some intensive unit of work in order to differentiate when and where does a variable become out of scope just by looking at the block of code.

Use meaningful naming conventions for all but the most transient of objects. the name of something is informative about when and how to use the object.

Avoid magic numbers : A constant, completely undocumented, that must be a particular value for the program to work correctly. No one knows why that number was chosen, and at its most magical, no one REALLY knows how the number affects the program, other than changing it breaks things.

Magic numbers are evil and should be abolished on sight.

Adjusting to timeframe : The picture above speaks for itself.

Some common practices which should be used in order to write quality code (clean code) and their relative importance :

Writing good quality code is a dynamic process. Some more points to consider while trying to write “good code”:

• Good code is well - organized. Data and operations in classes fit together. There aren’t extraneous dependencies between classes. It does not look like “spaghetti.”
• Good code is well-tested. Tests serve as an executable specification of the code and examples of its use.
• Good code is not “clever”. It does things in straightforward, obvious ways.
• Good code is developed in small, easy to read units of computation. These units are reused throughout the code.

Thanks for reading, please share it if you found it useful :)