Best Practices to Make Life Easier for the Programmer
Writing code has never been easy.
Well, let me re-phrase that: Writing readable code has never been easy.
Many programmers work on their code alone. They define and write the specification, design the system, write codes and libraries and write documentation, all by themselves. They never have a problem with version control, never experience a single conflict, and never have to deal with different approaches and algorithms. Everything is on their head and they just write it out. No problem.
On the other hand, many programmers have a hard time reading other programmers' code. One will always have to understand the logic, flow and “magic” around their friend’s code. This is not an easy task considering every programmer has a unique style. But still, they need to introduce massive, unstructured yet logical code into their brain.
Introducing Best Practices
Almost every programming language (if not all) has “best practices.” This kind of discipline will help you avoid unnecessary headache because of different variable naming conventions, and it also saves you time by knowing where a particular variable was declared, and so on. Best practices won't guarantee you bug-free programming, but they reduce illogical branches of “if-else” and getting lost loop inside loop. Best practices will help everyone think like you, and they will focus on the solution. Best practices are, in short, a life saver.
So, I decided to share a few things that have made programmers around the world happier because they aren't having to deal with nearly as much messy code.
Should you ever need a variable that 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 will stay the same for the rest of execution. Constants are quick-to-find variables and they help you minimize memory usage.
Another good candidate that can act as constants, but also ones that are 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've saved by defining constants as constants.
Configurations are just sets of variables, not more or less. The term ‘configuration’ means variables that are used a lot and rarely change but can be changed in the middle of execution, if needed. They point to a specific configuration in your application and they should be placed in one set, whether or not 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 a constant.
So many programmers don’t care about access-level modifiers. They let their methods, any of them, become public without knowing the consequences. As mentioned in this page, you should give your method or member private access first, then only methods and properties at the same class can access it. If you need broader access, use protected and, as a last resort, public access. This way you can protect your specific method or member from the ‘outside world’.
No matter how you finished your work, you always need to go back once in a while to fix bugs or add features. Comments let you remember code snippets, algorithms, sort methods, even randomized numbers you’ve created before. You will not forget six months later why you chose ‘switch’ instead of ‘if-else’, for instance, or 'Shift-left' over 'multiplication', or 'cookies' instead of 'session'. Comments help you see what needs to be done; they don't reiterate an intention before that. This is a big advantage if you’re working on a team. Because of comments, other people will understand your intentions if you've removed 10 lines of codes and written a new method instead.
I know many best practices are out there regardless of programming languages people use. They're there. Even though every programming language has its own ‘best practice’, I’m sure they share at least one similarity: to make you and your team more productive. If you have another best practice (a general one or one that's in your own favorite programming language), let me know by leaving your own comments below.
(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)