Programming Principles
To write high-quality, maintainable, and efficient code, programmers must consider a variety of programming principles or programming rules of thumb. In this page, we will discuss several such principles that can help developers write better programs.
DRY Principle [1]
The "don't repeat yourself" (DRY) principle emphasizes the importance of avoiding duplications, by replacing them with loop constructions or abstractions (methods, objects, ...), or using data normalization to avoid redundancy. Due to the DRY principle, every piece of knowledge must have a single, unambiguous, authoritative representation within a system.
The opposing view to DRY is called WET ("write everything twice" or "write every time"). WET solutions are applied when the DRY approach conflicts with other principles.
AHA Principle [2]
Another approach to abstractions is the AHA principle, which stands for "avoid hasty abstractions", and is based on the idea that duplication is far cheaper than the wrong abstraction. AHA programming suggests that rather than starting with an abstraction or abstracting after a specific number of duplicates, abstraction should be done when it is needed, i.e., when the duplication itself has become a barrier, and the functionality of the abstraction is known.
Rule of three [3]
The "rule of three" (three strikes and you refactor) is a principle for deciding when similar pieces of code should be refactored. It states that two instances of similar code do not require refactoring, but when a similar code is used three times, it should be extracted into a distinct procedure.
KISS Principle [4]
The "Keep It Simple, Stupid" (KISS) principle states that most systems work best if they are kept simple. Therefore, simplicity should be a key goal in design, and unnecessary complexity should be avoided.
YAGNI Principle [5]
"You aren't gonna need it" (YAGNI) is a principle that states a programmer should not add functionality until deemed necessary. Always implement things when you actually need them, never when you foresee that you will need them.
YAGNI is meant to be used in combination with continuous refactoring, unit testing, and integration. Otherwise, it could lead to technical debt.
Principle of Least Astonishment [6]
The "principle of least astonishment" (POLA), aka the "principle of least surprise", proposes that a component of a system should behave in a way that most users will expect it to behave, and therefore not astonish or surprise users. This applies to user interfaces and software design and is based on the belief that people are part of the system. Thus, the design should match the user's experience, expectations, and mental models. If a necessary feature has a high astonishment factor, it may be necessary to redesign the feature.
Gall's law [7]
"Gall's law" is a rule of thumb for systems design, from the book "Systemantics: How Systems Really Work and Especially How They Fail" by John Gall. It states:
A complex system that works, is invariably found to have evolved from a simple system that worked. A complex system designed from scratch never works, and cannot be patched up to make it work. You have to start over with a working simple system.
Fail-Fast Principle [8]
A fail-fast system is one which immediately reports any condition that indicates a failure, rather than attempting to continue a possibly flawed process.
Fail-fast code decreases internal software entropy and reduces debugging effort because it makes it easier to pinpoint the cause of a failure since the system reports the failure as close as possible to the time it occurs.
- A fail-fast function checks input parameters in the precondition and throws a runtime exception if some abnormal condition is found.
- A fail-fast object initializes the object's internal state in the constructor, and launches an exception if something is wrong, rather than allowing partially initialized objects that will fail later, due to a wrong setter.
- In client-server architectures, fail-fast will check the client request just upon arrival, before processing or redirecting it, and return an error if the request fails.
- In software engineering, the principle of fail-fast is closely associated with Agile methodologies. In that concept, failing fast means having a process of starting work on a project, immediately gathering feedback, and then determining whether to continue working on that task or take a different approach.
Separation of Concerns Principle [9]
In software engineering, "separation of concerns" (SoC) is a design principle for separating a computer program into distinct sections. Each section addresses a separate concern, a set of information that affects the code of a computer program. A program that embodies the SoC well is called modular. Modularity, and hence the separation of concerns, is achieved by encapsulating information inside a section of code that has a well-defined interface. N-tier architecture and MVC architecture are some other embodiments of the Soc.
Command-Query Separation Principle [10]
The "command-query separation" (CQS) principle states that every method should either be a command that performs an action, or a query that returns data to the caller, but not both. In other words, asking a question should not change the answer. More formally, methods should return a value only if they are referentially transparent and hence possess no side effects.
Principle of Avoid Premature Optimization [11]
William Wulf once noted, "More computing sins are committed in the name of efficiency, without necessarily achieving it, than for any other single reason." The principle of "avoid premature optimization" recommends that programmers should not let performance considerations affect the design of their code. This can lead to a less elegant design or incorrect code because of needless complexity.
A general rule of thumb (known as the 90/10 law) states that 90% of a computer program's execution time is spent on only 10% of the code. As a result, programmers should not sacrifice code readability for some perceived efficiency, as most of their code will not significantly impact the program's run-time. Real efficiency gains come from improving the algorithm's complexity order. A better approach is to design first, code from the design, and then test the resulting code to identify which parts should be optimized. Following Wes Dyer's advice, "Make it correct. Make it clear. Make it concise. Make it fast. In that order."
Ninety-Ninety Rule [12]
In software engineering, the "ninety-ninety rule" is a humorous aphorism that states:
The first 90 percent of the code accounts for the first 90 percent of the development time. The remaining 10 percent of the code accounts for the other 90 percent of the development time!
Change One Thing at a Time Principle [13]
This principle suggests that programmers should only implement one change at a time to easily comprehend the relationship between the change and its effect on the code. This approach can help to simplify the debugging process and make it easier to determine the root cause of any problems. A good practice is to conduct tests after each alteration to validate the change's impact.
The Principle of Deliberate Naming [14]
This principle emphasizes naming identifiers (variables, functions, classes, objects, etc.) very semantically and following a consistent naming convention. Names should either be descriptive of the contents or a name that is common programming practice for the language (such as using i, j, k for loop and array indexes). Commonly, functions should have verb/verb phrase names as each of them should specify one specific task. Variables should have noun or adjective names as variables represent things or attributes of something.
1. https://en.wikipedia.org/wiki/Don%27t_repeat_yourself
2. https://en.wikipedia.org/wiki/Don%27t_repeat_yourself#AHA
3. https://en.wikipedia.org/wiki/Rule_of_three_(computer_programming)
4. https://en.wikipedia.org/wiki/KISS_principle
5. https://en.wikipedia.org/wiki/You_aren%27t_gonna_need_it
6. https://en.wikipedia.org/wiki/Principle_of_least_astonishment
7. https://en.wikipedia.org/wiki/John_Gall_(author)#Gall's_law
8. https://en.wikipedia.org/wiki/Fail-fast
9. https://en.wikipedia.org/wiki/Separation_of_concerns
10. https://en.wikipedia.org/wiki/Command%E2%80%93query_separatio
11. https://en.wikipedia.org/wiki/Program_optimization#When_to_optimize
12. https://en.wikipedia.org/wiki/Ninety%E2%80%93ninety_rule
13. https://vedantsopinions.medium.com/software-engineering-rules-of-thumb-63060ca51b94
14. https://en.wikipedia.org/wiki/Naming_convention_(programming)