Don't just write code, Code right!
Updated: Dec 28, 2018
This article is more of a general coding guide for people who have just entered the software market or have a keen interest. Although while going through this article you may find it learning more towards Javascirpt(a programming language). But the principles described here are mostly followed in the industry in general. Enough talking its time to take some action.
Declaring constants in a single file.
Break the code.
Keep entry and exit points as low as possible.
Single responsibility principle
Declaring constants in a single file
Usually in the industry we would keep the stuff that won't change in the same file where we would be using it(in constants), except for some environment variables used globally. But according to my experience it would be better to declare all the constants in a single file with some great detailed comments, that way any person who would require to access the code base would find it easy to control various aspects of the whole app from a single file.
Now by constants i don't mean only entities containing static values(i.e const variables) but also some common functions having a small single simple responsibility e.g.
Using the above function system wide for printing logs will help you to control system wide logging from one place. Here any one can just switch the isDebug to false and the logs for the whole system would stop.
Usually do need to handle small, small things that could go wrong like making a database call to store something or getting an image from a url, and a million things more. We require to handle these types of error gracefully but here i want to talk about the errors that can occur while the code is in production, although we do have tools like firebase crashlytics, AWS crash analytics, but here i am talking about the code.
Our system should be designed so that when ever its crashes because of an unhandled bug a system level error handler should be there which will collect the environment data send it to some email or log it some where available for detailed research and then closes down.
Break the Code
Yes that's what i said, while writing the code we also need to focus on ways that can break our code and try to break it as much as possible, because the creator of the code is in the best of knowledge to find such loopholes and this would allow us to create a code which is mostly stable. After a while following this there would emerge a pattern of coding, a pattern created and recognised by yourself which would be a lot better.
Keep entry and exit points as low as possible
Mostly you require to acquire data, process it (or maybe not) and send it where ever its required, now we must follow a convention to keep the data entry and exit points as low as possible that way we can have a firm knowlege of what's coming from where and where its going, failing to follow this principle will result in a lot of confusion of how system behaves.
You may have a system which requires to create a transaction for activities performed inside the system, so what you did is, you made a database call where ever a transaction is to be recorded, but then you were said to disallow the transaction above a certain amount, so now you would need to go to every single place where you made a database entry and write this logic.
Instead what you could do is write a single function which can access the database and store the transaction and use and abuse that function when ever a transaction entry is required. Also by doing so writing any logic around transactions would be very easy.
Single responsibility principle
This is very simple, just structure you code in such small segments where every segment has a simple single responsibility and nothing else. It does just one thing but it does it well.
So that's it for today, Please let me know what do you think about this article, also please note i have just scratched the surface of what a good code may look like, but i will keep developing these articles as it comes to my experience.
Please leave a comment below if you have something wandering around your head, may it be something crazy. And let me know what kind of technical articles you would like us to create.
Ending with a quote
A game is to play not to win or loose