Programming is an intricate and dynamic field that constantly evolves. As a Software Developer, it's crucial to adhere to certain principles that not only enhance the quality and efficiency of your code but also facilitate collaboration and maintainability. This article is a compilation of some principles that every Software Developer should know. The list is incomplete, and sometimes trade-offs need to be made between conflicting principles. However, higher ranked principles usually beat lower ranked ones.
The list was inspired by The Principles of Good Programming (down? Google's cache). This article is a fork of programming-principles repository by Lars Kappert, who has done most of the work collecting the material.
- The Principles of Programming World
Programming Principles are fundamental guidelines or rules that help guide the process of writing efficient, maintainable, and reliable software.
- Readability and Collaboration
- Flexibility, Maintainability and Scalability
- Modularity and Reliability
The KISS principle is about striving for simplicity, KISS states that a solution is better when it uses less inheritance, less polymorphism, fewer classes, ect. This does not mean that features like inheritance or polymorphism should not be used at all. Rather they should only be used when they are necessary or there's some substantial advantage.
Strategy
- Avoid:
- Complicated OOP concepts like inheritance, polymorphism or dynamic binding.
- Low-level optimization of algorithms, especially when involving Assembler, Bit-operators and pointers.
- Numerous classes and methods as well as large code blocks.
- Avoid general solutions needing parameterization.
- Should:
- Use simple brute-force solutions. Slower algorithms will work in the first place.
- Use private methods instead of an additional class for slightly unrelated but rather small functional pieces.
Note: Many principles are contrary to KISS, Some of these needing consideration: Generation Principle, Murphy's Law, Model Principle.
References
- Keep It Simple Stupid (KISS), (principles-wiki.net)
- KISS principle, (wikipedia.org)
- Shafayetul Islam, Keep it Simple, Stupid – How to Use the KISS Principle in Design
The MIMC Principle is a rule of thumb stating that the introduction of further modules usually has a higher complexity as a drawback. The capabilities of the human mind are certainly limited. If there are many modules, looking for a particular module takes a long time, the longer the searching takes, the more one will have forgotten what has been read previously. This results in the worst readability, understandability, and thus maintainability.
Strategy
- Avoid Many modules
- Merge several modules into one.
- Put the functionality into another module instead of introduce new module.
- Avoid Big modules
- Divide large modules into several smaller ones.
- Introduce new modules to group related functionality.
References
The YAGNI states a Programmer shouldn't add functionality until deemed necessary. This principle encourages a minimalist approach to development, focusing on delivering the most critical features ini a timely manner.
Strategy: Always implement things when you actually need them, never when you just foresee that you need them.
References
Every piece of knowledge must have a single, unambiguous, authoritative representation within a system. DRY principle states that if there is duplication, there shall be some "single source of truth". When one piece of information has several representations DRY demands one and only one representation being the definitive one.
Strategy
- Factor out a common base class.
- Add a new invokable module (a function, a method, a class, etc.) or use polymorphism instead of duplicating code.
- Use code generation when information has to be represented in multiple forms.
- Apply the Rule of Three.
References
- Andrew Hunt and David Thomas, The Pragmatic Programmer
- Don't Repeat Yourself (DRY), (principles-wiki.net)
RoE states that explicit solutions are better than implicit ones. Indirection, side effects, configuration files, implicit conversions, etc. should be avoided.
Strategy
- Avoid indirection: (but keep LC in mind)
- Events, listeners, observers, etc. Use direct references instead.
- Messaging middleware in favor of direct communication.
- Avoid configurability (but keep GP in mind):Configuration files for specifying behavior. Instead implement varying behavior explicitly.
- Explicitly state which module to use: Avoid importing all classes of a given package/namespace, import the needed classes explicitly.
- Explicitly name parameters:
- Avoid long parameter lists and use objects with explicit attribute assignments instead.
- Use parameter types that explicitly state what the input is. Rather use specific types for parameters like customers, articles, URLs, colors, money, etc. instead of using strings or integers for these values.
References
The Boy Scouts have a rule: "Always leave the campground cleaner than you found it". In development, we follow a similar rule in our code: "Always check a module in cleaner than when you checked it out".
Strategy
- Instituting frequent code reviews
- With each commit make sure it does not degrade the codebase quality.
- Any time someone sees some code that isn't as clear as it should be, they should take the opportunity to fix it right there and then.
References