Common Rules in Programming

Writing code has never been easy.

Well, let me re-phrase: Writing readable code has never been easy.

Many programmers work on their code alone. They define and write the specifications, design the system, write codes and library and write documentation, all by them self. They never have a problem with version control, never experience a single conflict, and never have to deal with different approach and algorithms. Everything is on their head and they just write it out. No problem.

On the other hand, few programmers (if not many of them) struggling hard to read someone else’s code trying to understand on what he/she was doing at the time he/she wrote their codes. The later will always have to understand the logic, flow and “magic” around their former friend’s code. This is not an easy task considering every programmers had already have their own style. But still, they need to introduce massive unstructured yet not logic code into their brain.

Introducing Best Practice

Almost every programming languages (if not all) has a thing called “best practice.” This kind of discipline will not only avoid you from unnecessary headache because of different variable naming conventions but also saves you time by knowing where particular variable was declared, and so on. Best practice will not guarantee you to a bug-free programming but it reduces illogical branch of “if-else” and getting lost in loop inside loop. Best practice will make everyone think as much the same as yours and focusing on the solution instead of understanding what you’re trying to solve. Best practice is… a life saver.

So, I decided to share little things (yes, just a little, no big deal) that have made programmers around the world happy and later thank you for not writing such a messy code.

Constants

Should you ever need a variable which is not changing over time (or in many cases just one time), you should use constants. Mathematical and physical constants like Phi, e, G, etc. will not change over time and stay the same for the rest of execution. Constants help you minimize memory usage and also quick-to-find variable defined as constants.

Another good candidates for constants (but also eligible to be defined as configurations, see below) including per page pagination, dev mode and log mode flags, database configuration, and such things like that. Later on, you will realize how much time you have been saved by defining constants as constants.

Configurations

Configurations are just a set of variables, not more and not less. The term ‘configuration’ picked because there are some variables that: use a lot, rarely change but can be changed in the middle of execution, point to a specific, you know, configuration in your application, and should be placed in one set whether it’s a separate file or class. Constants can be made as configurations if it can be changed in the middle of execution. Otherwise, leave it as constants.

Access Control

So many programmers don’t care about access level modifiers. I mean, they let their methods, any of them, to be public without knowing the consequences. As mentioned in this page, you should give your method or member private access first, which means that only method and properties at the same class can only access it. If you need more broaden access, use protected and, as the last resort, public. This way you can protect your specific method or member from the ‘outside world’.

Comments

No matter how you finished your work, you always need to go back once for a while (for fixing bugs or add features, in example). Comments let you remember code snippets, algorithm, sort method, even randomize number you’ve created before. You will not forgot, six months later, why you choose ‘switch’ over ‘if-else’, shift-left over multiplication, and using cookies instead of session. Comments make you focus on what needs to be done, not re-understanding your intention before. This is even a big advantage if you’re working on a team. Other people will understand your intention when you remove 10 lines of codes and write a new method, instead.

Conclusions

I know there’s a lot of best practice out there regardless programming languages you use. It’s there. Even though every programming languages has its own ‘best practice’, I’m sure they share the same thing: to make you and your team productive. If you have another best practice (in general or in your own favorite programming language), let me know by leaving your comments below.