Entering into the world of programming is immense and a different journey for each individual. But it’s up to you how far in you go, how much you stumble and how long it takes for you to find your strengths and weaknesses. And let me tell you that there is no room for giving up, you have to keep preceding, steadily acknowledging and learning from your weaknesses and recognizing patterns that can help you as you advance.
For the past few years, I’ve been following some guidelines while programming that has helped me to a greater extent. I hope these tips make you save some time and frustration and more importantly to avoid you from facing the bad or harder experiences I’ve faced in the initial stages.
1.Make it Readable
From a simple program we build a complex application, but when the code becomes enormously large it can be tough to interpret it. While debugging your code or while updating the code after a long time, it might happen that you get lost in the lines if the program isn’t neat.
Readability also plays an important role when we work in teams. The average developer spends 75% of the time understanding code, 20% of the time modifying existing code and only 5% writing new code. A slight additional time spent on readability reduces the understanding time for teammates. Hence maintaining proper indentation and white space is significant.
If it was hard to write, make it easy to read.
Comments are crucial as they make computer programs human readable. The volume of comments written is meaningless, quality is all that counts. Comments should explain everything about a program because you might not remember a complex code you wrote months ago or the task of a function. It can be helpful if you’re working in collaboration too, as your peer might require a little more than unexplained vague lines of code.
Write meaningful, single-line comments for complex lines; write functionality descriptions for functions and methods; for tricky logic blocks, describe the logic in words if necessary. And don’t forget, always keep your comments up to date!
3.What’s in a Name? —a lot!
The name should clearly indicate what the variable is or what a function does. Following the naming conventions should be a must!
- Always use CamelCasing: getName(), studentName.
- Write the name of constants in uppercase with underscore separating each word: ARRAY_SIZE.
- Don’t make the name too descriptive, try to keep the length of the name short.
- Avoid making variables or functions with similar names: if you create a function named addInList() and another function named appendInList() you might have trouble understanding the code later.
- Make sure the description of a variable or function should match with their functionality as well.
4.One Function, One Job
Functions allow us to conceive of our program as a bunch of sub-steps, allows us to reuse the code, keeps our variable namespace clean and make testing simpler. Keeping the functions limited to a specific task plays a significant role in readability and testing as well.
As much as possible they should be considered “black boxes” because we don’t need to know how they work. Just what is supposed to go into them, and what is supposed to come out of them. A common rule of thumb is the “Ten-Line Rule”, usually function longer than ten lines are trying to do too much and should be simplified.
5.Avoid Global Code
Global variables and loops are a mess and can prove problematic when your program or an application increases to thousands of lines of code (which most do!). They may influence code elsewhere that is difficult to discern, or cause confusing naming clashes. So think twice before you use the global namespace with variables, functions, loops, etc.
In an ideal case, you should have no blocks defined globally. That is all switch statements, try-catch, for, while-loops, etc. should be written inside a method or a function.
Believe it or not, you should be refactoring your code on a daily bases or your code is not in good health! You should be refactoring everything, from your architecture to your methods and functions, variables names, the number of arguments a method receives, etc.
How to refactor is more of an art more than a science, but there are few rules that can shed some light on it:
- If your function or method is more than 15–20 lines, it’s more likely that you are including too much logic inside it, and you can probably split it into two or more smaller functions/methods.
- If you have a lot of nested loops then you may be doing some resource-intensive processing without realizing it. In general, you should rethink the logic if you are nesting more than 2 loops. Three nested loops can get a little messy!
- Keep the code up to date, including all the latest things you have learned, put the latest syntax, make sure you are not using deprecated methods.
- Consider if there are any applicable design patterns your code can follow. You shouldn’t use patterns just for the sake of using patterns, but patterns offer tried-and-true ready-thought solutions that could be applicable.
7.Output (as important as frosting)
A final, overlooked aspect of good programming style is how your program’s output is presented and how clear is the information given to the users. Part of writing professional looking programs is providing clear instructions and results to the users of our programs. You must always assume that you are writing programs which will be used by somebody with no understanding of computer programming whatsoever. Consider the cherry on top to be the use of proper white space and alignment in your output.
Concluding It All: You may find these tips and guidelines basic or you might’ve heard about them a lot of times already but losing the hang of it won’t give you the outcome that you’ll be expecting! So always try to inculcate them as thoroughly as possible.