When writing code in any language, there are good codes and bad codes. Both are correct until compilation and when run bad code can cause problems during development, debugging and modifications. Regardless of how well your program runs, someone will have to read or change your code at some point. They may have to add new features, fix rare bugs, or just want to read it to understand how it works. Similarly, you will have to read other people’s code to do the same. People will understand what you want to code better if the code is easy to understand.
You write the code once but then you may have to use it many times, so your code documents are really important. Many times I come across my colleagues talking about them not being able to remember the code or logic they wrote a few days ago. For a bad piece of code, it will take you longer to understand what you were doing at that time. Everything will be chaotic when an artist cannot understand his own works.
A bad piece of code can result in financial loss or waste of time needed to maintain, improve or adjust the software.
Here are some important points to note when writing code:
1.Commet code
- Explain the code to make the code easy to understand and maintain for later maintenance.
- Explaining good code means explaining why this is done, not what this code does. It was the code that said what it did. The explanation must be the most concise.
2.Indentation
Good code is structured as shown in the figure. It must be obvious to the person trying to understand the code where the code started and where it ends so that after the logic becomes clear, then it will be a battle.
3.Readme’s
It is very complicated when you have a project that takes hours to set up and execute. It’s time to readme, it’s better to have a brief introduction to the project before you read the code. A readme has exactly the following structure: https://gist.github.com/PurpleBooth/109311bb0361f32d87a2#file-readme-template-md
4.Naming Conventions
- Many times we meet a class called Apimanager, looking at it and finding that the purpose of the class is unclear. According to current standards, SRP naming makes it easier and more specific. Naming conventions should also change for different scopes if a class is doing some intensive unit of work to distinguish when and where a variable becomes out of scope just by looking at code.
- Use meaningful naming conventions for all but transient objects. The name of a class is information about when and how to use objects.
5.Adjusting to timeframe
Steps to improve the code quality
- Good code is well organized code. Data and activities in classes must work together. There is no dependency between classes like “spaghetti.”
- Good code must be thoroughly tested. Tests perform the task of executing the code in the examples that execute it.
- Good code is not “smart” code. It needs to be made as simple and clear as possible.
- Good code needs to be done from small computational units and it will be used throughout the code.
Source: Collector