Programming is just like telling a story to a fellow programmer where variables are characters in your story some plays their role till the end and some end up in the middle, different functions are telling different parts of your story and connecting all the classes or functions in a specific order can only complete the story. To write down the story further, you want everything in a specific order so that you can understand the story easily and continue it adding your own lines from where it was left.
No matter how good coder you are, in programming your job is not just writing code that works and give you the desired output, your job is also writing a code that is maintainable, extensible and easy to understand so later the one who continues or maintains your project can understand it and he/she doesn’t have to go through a horror story which gives him/her a nightmare.
7 Common Programming Principles
- DRY (Don’t repeat yourself): Duplication of data, logic or function in code not only makes your code lengthy but also wastes a lot of time when it comes to maintain, debug or modify the code. If you need to make a small change in your code then you need to do it at several places. “Don’t Repeat Yourself (DRY)” principal goal is to reduce the repetition of code. It states that a piece of code should be implemented in just one place in the source code. The opposite of the DRY principle is WET (“write everything twice” or “waste everyone’s time”) which breaks the DRY principle if you are writing the same logic at several places. You can create a common function or abstract your code to avoid the repetition in your code.
- Test ruthlessly: Test early, often and automatically. After writing your tests, ask yourself: did I test all the boundary conditions? Create a safety net with regression tests — tests that compare the output of the current test with previous known values. As you develop, run your tests to ensure nothing has broken. There are many kinds of software testing, make sure you cover most of the types: unit testing, integration testing, validation and verification, resource exhaustion, performance and usability.
- Single Responsibility Principle (SRP): Single Responsibility Principle is another SOLID design principle, and represent “S” on the SOLID acronym. As per SRP, there should not be more than one reason for a class to change, or a class should always handle single functionality.
- KISS (Keep It Simple, Stupid): The “keep it simple, stupid” principle applies to pretty much all of life, but it’s especially necessary in medium-to-large programming projects. It starts way in the beginning when you’re defining the scope of what you want to create. Just because you’re passionate about game development doesn’t mean you can create the next World of Warcraft or Grand Theft Auto. When you think you’ve simplified enough, simplify it one level further — feature creep is inevitable, so start small.
- YAGNI: Your software or program can become larger and complex if you are writing some code which you may need in future but not at the moment. “You Aren’t Gonna Need It (YAGNI)” principle states that “don’t implement something until it is necessary” because in most of the cases you are not going to use that piece of code in future. Most of the programmers while implementing software think about the future possibility and add some code or logic for some other features which they don’t need at present. They add all the unnecessary class and functionality which maybe they never use in the future. Doing this is completely wrong and you will eventually end up in writing bloated code also your project becomes complicated and difficult to maintain. We recommend all the programmers to avoid this mistake to save a lot of time and effort.
- Liskov Substitution Principle (LSP): According to the Liskov Substitution Principle, Subtypes must be substitutable for supertype I mean methods or functions which uses superclass type must be able to work with the object of subclass without any issue”. LSP is closely related to the Single responsibility principle and Interface Segregation Principle. If a class has more functionality than subclass might not support some of the functionality and does violate LSP.
In order to follow LSP SOLID design principle, derived class or subclass must enhance functionality, but not reduce them. LSP represents “L” on the SOLID acronym.
- Avoid Premature Optimization: The no premature optimization principle is similar to the YAGNI principle. The difference is that YAGNI addresses the tendency to implement behaviors before they’re necessary while this principle addresses the tendency to speed up algorithms before it’s necessary. The problem with premature optimization is that you can never really know where a program’s bottlenecks will be until after the fact. You can guess, of course, and sometimes you may even be right. But more often than not, you’ll 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. Reach your milestones as simply as you can, then profile your code to identify true bottlenecks.