First of all Happy New Year to all my readers. Today, I’m going to talk about some basic problems which developers usually commit while writing the code. Generally, it happens because of last minute changes what you do in your code just to meet the deadline or fix some unforeseen errors.
The first step is understanding why your code is hard to read. Because you are writing to solve a problem statement. In order to solve any problem we first need to form a model of that problem. Think of this as the intent of your program. Next you need to form a model of a solution that will achieve your programs’ intent. Lets call this the semantic model. Never confuse the intent of your program with your solution to that intent. Eliminating as much of this accidental complexity as possible is crucial if you want easy to maintain, simple code. The problems we are trying to solve are complex enough. Don’t add to it if you don’t have to.
Poor translation of understanding into code:-
Once you have understood the problem, it needs to be properly labeled with Nouns so that you can identify the same while starting to design the solution. You should always write code with proper labels and comments so that others can understand the piece easily.
Single responsibility principle (SRP):-
The SRP is one of the core Object Oriented Design Principles and ties in with good class and variable names. The idea behind using SRP is your class should stick to job thats it. you should overdo your class otherwise again you need to do refactoring at later point of time.
I always choose my class names as descriptive ones which we identified during user story discussion.In Domain Driven Design, it is extremely important that you stick to proper class designs and attributes you are going to include in that. Even if you don’t buy any design pattern approach you should be very careful about class structure and names.
Variable, parameter and method names:-
At many places i have seen people write their method names very generic like Process,Post,Get,…etc. This is not at all a good practice, this will confuse you also while debugging or troubleshooting. Please be descriptive about your Methods like FetchMovie or FetchMovieReview. This way you can cut down your analysis effort if you are doing at later point of time. Everybody loves clean code but very few makes this practice.
Something that can be very useful when dealing with readable code is to look at the code from the front-end first. Using programming by wishful thinking lets you write the “flow” first and incorporate the technicalities later. Together with frequently looking up synonyms for the word you want to use will let you write code that is as explanatory as English. Example:
foreach (Touch _touch in touchList)
here you actually have 3 opportunities to find synonyms and words to describe what is going on the class name of the Touch, the local reference var and where they are stored… like
foreach (Touch _selection in User.actions)
and suddenly we have a much greater overview of what’s going on.