How to improve writing code

Preface: Code is something we write to interact with computer but its is important to write clean and understandable code so that other can understand your code & collaborate with it if necessary. In this article I tried to give you some idea how to write good code.

• Indentation: It does not matter if you use tabs or space just follow the convention of writing code with proper spacing. Many modern IDE gives you the suggestion to write properly indented code. Follow existing code indentation. Do not write more than 120 character in one line. Most IDE shows a vertical line never exceed that. Indentation is very important for reading and writing code.
•  Name properly: Name your variable or method or class properly. It is said that “codes are for computer to execute and human to understand”, so name properly so that other programmer who read your code understand your intention for writing this code. 
•  Comment why not what: I see people writing code without comment. It is perfectly fine if your code is easy to understand. I also see some who writes unnecessary comment e.g.
  
  “i++ // increment”.
  
  We all know what “i++” does we don’t need to comment this kind of lines in our code. Comment about a method or line of code should say why you wrote this code not what is does. Again if your code is easy to understand then no need to write comments. 
•  Avoid long method : Everyone who reads codes knows how hard it is to read and understand long method. We should keep our code as small as possible. There is principle that good code writers follow which is “Single responsibility” principle. A method should do one thing and one thing properly. It is easier to understand then what you want to do in this code also it is easy to test. Open any code that "JDK" provides and see how small and well organize code they writes. These should give you encouragement to write good code. 
•  Write clear code not cleaver code: This especially applies for many developer I know who writes cleaver code and takes pride in it. Cleaver code is very hard to understand. You are not writing code to put your name is guinness book of world records of complex code. You are writing code so that other fellow developer can understand it and extend your work from there. Wring clever code make you feel good but it’s hell for you colleague to understand it. 
•  Avoid primitive obsession: Whenever a developer gets a problem, he tries to solve this as soon as possible by himself, rather than looking to see if this problem is already solved or not. I used to do this when I was young and I am sure many of you done this as well. This is called primitive obsession. I remember once when I was trying to solve one problem in an spring application and did manage to solve it after three days. Later on I found that there is a existing feature that is available by spring framework that already solves this problem with no more than one line of code. So before solving any problem see if this is already solved by someone else before diving deep into the problem domain. 
•  Loose Coupling: Implement loose coupling in your code do not put a lot of information in one method or in one class. Try to write similar code together. Avoid writing code that combine multiple logic together. For example for a typical scenario like you need to insert a row in a database. What we do normally is write 5 lines of code to create connection to the database then 3 lines to write insert logic and finally write 5 lines of code to close the connection. We just needed to insert one line to database and we wrote 13 lines of code for it. This is really bad. Rather we can write 3 method instead of one for three section of the code, that will make our code more clear. Framework like spring give us the power of dependency injection which allows us to write this kind of code with proper configuration with only one line of code. 
• Lower technical debt: Finally I would like to say spend some time to lowering your technical debt. I think we all know people who write code to solve a problem and never comes back to that code to refactor it. If there is a problem with the code later on, then they just patch the code bare minimum so that it runs to code properly. Rather than doing this we should find some time to write optimized code to our knowledge. If you don’t refactor your code it becomes legacy code within 6 months or less. And we all know how it feels to modify or upgrade a legacy system.