Sunday, February 27, 2011

20 Software Development Best Practices

Below are a compilation of 20 software development best practices:

  1. Always use source control system even if the project has only one developer. By doing that, you don't lose some or whole code immediately, can share same source file by multiple person and can take the whole advantage of coding histories. 
  2. Follow coding standards and check that standard with automized tools.
  3. Be consistent. If you do operations in a specific way, do that kind of operations in the same way (e.g. defining variable/method/class names, paranthesis usage etc.).
  4. More code does not mean better code. Keep it simple and reduce complexity.
  5. Don't use magic numbers and strings directly in the code. Use constants. This method provides more modularity and understandability.
  6. Don't use comment lines to delete code, just delete. Version controling system will help you if deleted code is required.
  7. Delete unused methods and classes. Version controling system will help you if deleted code is required.
  8. Catch specific exceptions instead of highest level class 'Exception'. This will provide understandability and more performance.
  9. Use understandable and long names for variables. Loop variable names can be i, j, k, index etc., local variable names must be longer than loop variables, parameter names must be longer than local variables and static variable names must be longer than parameters;  proportional with scope size.
  10. Package related classes (that changed together and/or used together) together.
  11. Use understandable comments. Bad comment is worse than no comment.
  12. Use positive conditionals. Readability of positive conditionals are better than negative ones.
  13. Use dependency injection to manage too many singletons.
  14. Use exceptions only for catching exceptions, not for control flow. Think as required and perform control flow with control statements/conditionals.
  15. Don't use so many arguments with methods. Keep the number at most 8-10. If more is required, review your design.
  16. Don't use method alternatives with boolean flag variables (public void someMethod(bool flag)). Write more than one method for each flag condition.  
  17. Method names must include "what is done by this method" information.
  18. Think twice before defining a method as static and be sure if you really need to. Static methods are harder to manage.
  19. Avoid using methods with reference parameters. Use multi attributed object parameters instead.
  20. Number of interface methods must be minimized to decrease coupling/dependency.


  1. Totally agree with your sayings!Although all of them are well known practices it good to see them grouped together!Good work :)

  2. Some things as important:
    - keep methods small, keep classes small
    - don t make too many imports from different packages on same class
    - static methods are good but should mostly live on dedicated proper classes
    - deliver often, get user feedback in a continuous regular and intense flow
    - dont try to be too much smarter than customer, just enough
    - do only whats needed to deliver the functionality expected in each step in the best possible way
    - make sure you love and care about your work, code, user and customer

  3. DI is good .. but using too many singleton is bad. AFAIK, avoid this pattern if you can.

  4. Someone agree on the "don't comment out code, delete it", however once it is out of sight it is also out of mind and therefore new developers may be tempted to re-implement the same code. Also a solution to a problem that is no longer needed, may be helpful in resolving similar problems that crop up in the future. Having the prior solution readily available in comment code can be quite helpful.

  5. >> 6. Don't use comment lines to delete code, just delete.

    Deleted code can be easily resurrected (in one form or another) by someone else (a new developer in the team) after some period of time (1-2 years). Even if I left the comment in commit message he would not bother to scan all the commit comments of the file.
    Sometimes it is better to comment the code and leave the comment about the cause.

  6. good article. Really like "Package related classes (that changed together and/or used together) together".

  7. This is the first time I heard using posiitive conditionals being recommended. I think I need to chew on that for a while before I implement it.

  8. Let's assume this list has been 'googled/binged' by a Manager. He might assume the list is in order of importance. Would you then reorder the list or keep it as it is?

    Also, what about "Unit Testing",e "prefer composition over inheritance" and related best practices...

  9. @kunderez: "Reference parameters" means e.g. ref/out parameters of C#. Of course string or string array parameters can be used for a mail method or any other method. Thanks.

  10. This is a very interesting post, really useful tips indeed. I think that coding standard is an important thing to consider. Thanks for sharing.

  11. Agree on these. Sometimes bigger functions/classes are ok, forcing e.g. a bigger catch into smaller functions makes the code unreadable

  12. Regarding point 16. with the boolean flag parameters I would also suggest in some cases the following alternative - rather than using a boolean flag use an enum as this makes can make the code more readable IMO. An example would be if someMethod had different output but the same logic if a user is logged in or not e.g. - someMethod(true) vs. someMethod(Status.UserLoggedIn) vs someMethodUserLoggedIn().

  13. I just wanted to add a comment here to mention thanks for you very nice ideas. Blogs are troublesome to run and time consuming thus I appreciate when I see well written material. Your time isn’t going to waste with your posts. Thanks so much and stick with it No doubt you will definitely reach your goals! have a great day!

  14. Wow, Fantastic Blog, it’s so helpful to me, and your blog is very good,
    I’ve learned a lot from your blog here, Keep on going, my friend, I will keep an eye on it,

  15. Very basic comments about coding standards, it's nice.

  16. Lot of useful points are there. Its really keeps me updated.