When we are discussing about software development life cycle, we would like to take a chance to discuss about code quality also. Why it is? Because lot of people speaking about it but following…!!! Yes, its very less.
Code Quality is one of the key factors in software development, How? Sometimes when there is mistake/bug, it is key challenging to predict how people will interpret your code, whether they will find it easy to read or an absolute nightmare. Not only that, when your project gets very big even you might not be able to read it.
In Such a case, we shouldn’t sit with mess. How to make it simple? It’s very easy. Yes, just recall your school days, may your mam keep says to take a note. Yes, same we going to say same but not to take notes, just document it. Which will help you lot. Along with this we have few principles which will help to write a Quality code.
The following coding principals are widely using by expert developers which gave massive productivity boost and helped anyone be able to easily interpret and expand the code base. Hope these principles help you to write a code faster and better.
Principle 1 – Test it
Yes, you heard correct TEST it. We all know we should always do it, but sometimes we cut corners, so we can push the project out faster. But without thorough testing, how will you 100% fully know that the code works? Yes, there are very simple pieces of code, but one is always surprised when that crazy edge case comes up that you thought you didn’t need to test for!
Do yourself and everyone on your team a favor and regularly test the code you write. You’ll want to test in a course to fine style. Start small with unit tests to make sure every small part works on its own. Then slowly start testing the different subsystems together working your way up towards testing the whole new system end to end. Testing in this way allows you to easily track where the system breaks, since you can easily verify each individual component or the small subsystems as the source of any issues.
Principle 2 – Name it meaningfully
This is what makes code self-documenting. When you read over your old code, you shouldn’t have to look over every little comment and run every small piece of code to figure out what it all does!
The code should roughly read like plain English. This is especially true for variable names, classes, and functions. Those three items should always have names that are self-explanatory.
Principle 3 – Classes and functions should be Single Responsibility Principle (SRP)
Small classes and functions make code easier to read. First off, they allow for very isolated unit testing. If the piece of code you are testing is small, it’s easy to source and debug any issues that come up in the test or during deployment. Small classes and functions also allow for better readability. Instead of having a giant block of code with many loops and variables, you can reduce that block to a function that runs several smaller functions. You can then name each of those functions according to what they do and human readable code.
The SRP is a widely quoted justification for refactoring. This is often done without full understanding of the point of the SRP and its context, leading to fragmentation of code bases with a range of negative consequences. Instead of being a one-way street to minimally sized classes, the SRP is proposing a balance point between aggregation and division.
Principle 4 – Catch and handle exceptions
Exceptions in code are usually edges case or errors that we would like to handle in our own specific way. For example, normally when an error is raised the program will stop; this will not work for code we have deployed to production that is serving users! We’ll want to handle that error separately, perhaps try to see if it’s super critical or if we should just pass over it.
Having a deeper understand of your code like this makes it easier to debug and makes your code more fault tolerant.
Principle 5 – Logs
Believe me this helps lot to debug your code and monitor the application.
You should log all major “step” of program takes, any errors, exceptions, or out of the ordinary results. It may also be useful to log the date and time that these events occur for easy tracking. All of this will make it easy to trace exactly which step in the pipeline the program failed.
Many common programming languages such as Python come with their own logging libraries that have some very useful functions you can play with. If your application is to run as a SaaS app, then you may want to consider off-device, centralized logging.
