Over the years I have found that following several guiding principles has helped me become a much more effective programmer. Writing software takes self-discipline. By abiding by these principles, I save both development and maintenance time, and conquer lots of other bottlenecks which generally arise in later development phases.
These principles will help you write or deliver good, clean, and high-quality code.
“Defensive programming” is a form of defensive design intended to ensure the application should behave in a consistent and predictable manner even in the case of unexpected conditions. This may be as simple as ending a loop when
i >= 100 instead of just
i == 100.
Murphy’s Law: “Anything that can go wrong will go wrong”.
There are many different ways to achieve this depending on what you are trying to accomplish, and the programming language being used. However one universal rule of defensive programming is to never trust user input. Always assume that at some point your method will receive invalid input. Always assert validate your input.
Defensive programming is a technique where you assume the worst, and try to eloquently catch those exceptions.
The “Keep It Simple, Stupid” principle (pardon the name calling) is pretty much a rule for everything in life. Most things work best if they are kept simple rather than made complex. Therefore simplicity should be a key goal in design and unnecessary complexity should be avoided.
Tip: A good question to ask one’s self when programming is “What is the simplest thing that could possibly work?” This helps keep us on the path towards simplicity in the design.
Simple code takes less time to write, has fewer bugs, and is easier to modify.
“Don’t Repeat Yourself” is really a fundamental programming principle. It works hand in hand with keeping your code simple. This means each significant piece of functionality should be implemented in just one place in the source code.
Every piece of knowledge must have a single, unambiguous, authoritative representation within a system.
Keeping your programming DRY reduces the repetition of software patterns, replacing it with abstractions, or repetition of the same data, using data normalization to avoid redundancy.
Reusing code improves code reliability and decrease development time.
“Separation of Concerns” is a design principle for separating a program into distinct pieces that work together, such that each piece addresses a separate function or concern. This is very similar to the principle of “Single Responsibility” which states that every class should only concern itself with one specific functionality.
When concerns are well-separated, individual sections can be reused, as well as developed and updated independently. Thus simplify development and maintenance of the software.
A well-known example of this is the Model-View-Controller (MVC) pattern, which separates a application’s concerns into three distinct areas: the data “model”, the logic “controller”, and the user interface “view”.
The “You Aren’t Gonna Need It” principle states a programmer should not add functionality until deemed necessary. Chances are, you won’t need it and it will be a waste of effort— and it could needlessly increase your code’s complexity.
Additionally try to Avoid Premature Optimization. Don’t even think about optimization unless your code is working, but slower than you want. Only then should you can you measure the programs bottlenecks.
By optimizing too early you may waste valuable time trying to speed up a function that isn’t as slow as you think or doesn’t get called as often as you’d expect.
These principles of good programming have helped me become a better software developer over the years by allowing me to be more efficient and to produce code which is easier to maintain and has fewer defects.
In my humble opinion, continuing to improve on yours skill set through learning new languages and how to optimize your code is what sets the real developers apart from those who “don’t know how to do that..”