Keep It Simple, Stupid!
Do not write complex code.
Simplify your code by following principles as DRY, separation of concerns and single responsibility principle. Everyone who takes a look at your code should be able to understand what it does as fast as possible. If one of your methods is very long (30 lines and up), or needs comments to be easy human readable you are probably writing overcomplicated code. Try to further split up your logic, divide it into smaller, easier bits of code.
Some signs your method may be overcomplicated:
- you cannot name it in a way so you do not need additional comments to explain its functionality
- it is longer than 30 lines
- it is split up into various parts which all deal with a different part of the problem (read out file, process its contents, append lines, save it again)
- you need comments to explain its functionality
Of course, if you need to implement an encryption or a compression algorithm, the code for this specific task may be rather complex. Still, for any other part of your application KISS is applicable.
Don’t Repeat Yourself
Write each line of code only once.
If somewhere in your application you feel like you have written very similar code before, or worse, are copy-pasting code from somewhere else, you are probably doing something wrong. Duplicated code makes it hard for other developers and you to extract the really relevant instructions, and debugging a living hell (as you correct a mistake in copy-pasted code, you will have to do the same thing at all other places where you have used that code).
You can omit duplicated code by abstraction; write your code in a way that it works for all inputs. Use interfaces and common parent classes to execute tasks on similar objects: bad vs good (see method
public double CalculateAreas())
If you can’t reduce the problem by implementing interfaces or inheriting from common parents, you can take it a step further and try reflection: Reflection allows you to determine at runtime what properties and what methods you want to call from an object. As this topic is rather complex, and differs a lot from language to language, it is probably best if you look up for yourself how it is implemented in the language of your choice.
Separation of Concerns is like the Single Responsibility Principle, but in a larger context. You basically split different parts of your application into different parts in your code. If you build a RSS reader you can divide you code into the following sections:
- download the RSS feed from a URL
- parse the feed, and extract the relevant data
- display the feed to the user
This has following advantages:
- extensibility & maintainability
- multiple developers can work at the same project at the same time, each one has its own clear defined task
- you may be able to reuse large parts of your code for other projects, for example the download part in a weather application
This is maybe one of the most important principles there is, and probably every developer uses this to some degree instinctively, even without knowing its fancy name. The better you divide your logic, the easier development is.
This principle is quite simple: a class should have one, and only one purpose in your application. Use a Person object only to store data about a person (name, age, address..) but you may not use it to format how the date is displayed. Use a DownloadHelper to download a file but not to process its content.
Why is this desirable?
- extensibility & maintainability
- It avoids code duplication
- It forces the developer to break down his application into smaller, easier manageable parts
As an example, if you as a developer new to a large project have the task to change the formatting of the date, you would not need to know which objects display dates, you only have to find and adapt a class with a name similar to FormatHelper or DateTimeFormater.