As new year is about to come, thought to share thoughts with you all. First of all I would like to thank you all for being awesome, reading and appreciating the content. It gives me immense satisfaction writing and sharing posts with you guys.
Code Review is a normal practice and it’s in almost every Software Industry’s DNA. We’ve been conditioned with the idea that it’s always good to have a second set of eyes look at your work prior to production movement.
Writing and reviewing code is no exception. It’s pretty easy to forget minor things like proper variable initializing, disposing and freeing up resources at the end of execution and many more things. Therefore, having someone review your work only makes sense. In fact, it makes so much sense that software departments formalized the process, calling it “code review.”
It gives me immense satisfaction writing and dedicating this post to all my readers, who always gave me valuable and honest feedback for the posts. Because of you people only, This year I Received Microsoft MVP Award. This year has been exciting journey for me. I learned lots of new things and shared the same with you guys as well. I’ve been making my year-end “best of” lists since couple of days. When I started making my lists, almost nobody else online was making lists, I feel so. Then I realize that the internet was a place where you could make a list about things that happened in a year, and then share that list with people whom you admire and love most. And I capitalized on that realization.
So why am I bringing up this history?
I always believe, this is one of the best way to remind yourself, that still destination is miles ahead. This was just the beginning and with interim success, one should not get settle down. Also, I have seen when it comes to lists, we have a problem, and we usually say I want to propose a solution. I feel that when people look at a year-end list — whether it’s a best-of list, or a worst-of list, or a this-is-what-happened-this-year, it should show you actual picture like what you did correct or wrong. In either case there is always a room for improvement.
Therefore, whatever you guys are doing in whatever field do it full-heartedly and try to give your best. Now, this post is really getting tough for me as philosophy is not my area of interest. In the end, I will just say, Keep learning, Happy Learning and Happy New Year.
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.