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.

This entry was posted in . Bookmark the permalink.

44 Responses to 20 Software Development Best Practices

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

  2. Anonymous says:

    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. Anonymous says:

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

  4. Anonymous says:

    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. RZ says:

    >> 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. Gautam says:

    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. Ginamri says:

    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. CB says:

    Thanks for the comments & additions.

    @Ginamri: This list is only a "compilation" as stated. It does not include all best practices about software engineering. The main subject is version controling and coding here. Other practices can be the subject of another post. Thanks.

  10. kunderez says:

    "Don't use so many arguments with methods. Keep the number at most 8-10. If more is required, review your design." - I feel sick if function argument list grows larger than 3...

    "Use multi attributed object parameters instead." - Sounds veeeery scary... hell will break loose...
    sendEmail( (object)array( "title" => "..", "content" => "...", "sender" => array( "name" => "email" ), "recipient" => array( array( "name" => "email" ) ) );
    Builder methods FTW... Email::create()->setTitle( '..' )->setContent( '...' )->setSender( 'name', 'email' )->addRecipient( 'name', 'email' )->send();

  11. CB says:

    @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.

  12. P-Mo says:

    Regarding "17. Don't use method alternatives with boolean flag variables", What do you think about:
    doSomething (bool flag) { ... }
    doSomethingTrue { doSomething(true) }
    doSomethingFalse { doSomething(false) }

  13. CB says:

    @P-Mo: "doSomethingTrue" and "doSomethingFalse" are invalid namings for a method. Public method namings may be "enableSomething" and "disableSomething" for example. Item 17 is also valid for multiple parameter methods doSomething(int a, string b, ..., bool flag). Thanks.

  14. P-Mo says:

    @CB. You're absolutely right, but do you think it is a valid solution to wrap private doSomething() with public enableSomething() and public disableSomething(), or is there a better solution, considering all these methods belong to the same class? Thank you for taking the time to answer my noob questions.

  15. CB says:

    @P-Mo: "doSomething" is assumed as a public method here. You can define two public methods without flag but you can use your flagged private method in those two methods.

  16. Andrew says:

    Articles are created to express different body of knowledge. That is why I admire writers who are passionate of doing such incredible job. By the way, I like you post for it is specifically talk about current issues and technicalities in life. I look forward for your subsequent post.I look forward for your next article.Thanks Marks Liferay Blog

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

  18. Valuable post for software development.

  19. This is a nice article..
    Its very easy to understand ..
    And this article is using to learn something about it..

    c#, dot.net, php tutorial

    Thanks a lot..!

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

  21. Thank you for helpful tips and good review. Well done. To make somes business improvements, usually it uses custom software development company that meets various business expectations and needs in software development.

  22. Harish says:

    Hi. Greetings. This post is really good and blog is really interesting. It gives good details.
    Software Product Development

  23. 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().

  24. 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!

  25. 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,

  26. Anonymous says:

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

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

  28. Excellent pieces. Keep posting such kind of information on your blog. I really impressed by your blog.

  29. khan says:

    excellent work and thoughts , mind blowing
    Web Development Services

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

    Software Development Company Odisha

  31. Uk simran says:

    Point 1 to point 2 all are very help full thanks for sharing software product development

  32. Anonymous says:

    Anyone who is preρared to get a effectiѵely-toned stomаch can use this

    Heгe is my blog рοst - Flex Belt Reviews

  33. Anonymous says:

    The basic rice cooker is cheaper compared
    to other types of rice cookers. Granola is delicious with quinoa as one of its
    components. Cooker- The cooker prepares best
    quality rice with perfection.

    Feel free to surf to my page - noi com dien

  34. Thanks for share 20 software development parasitic tips.......

  35. Hello friend..
    Excellent job in 20 software parasitic steps in there. I read it and apply our work.And my result is good.!

  36. This comment has been removed by a blog administrator.
  37. Rarely this type of blogs can be find with such a wonderful information about software development. I would like to recommend people to visit your blog and also wish to share some information about our products we are into custom mobile application development and are well known for providing best service.

  38. I like you post for it is specifically talk about current issues and technicalities in life. Sometimes bigger functions/classes are ok, forcing e.g. a bigger catch into smaller functions makes the code unreadable .

  39. more info says:

    good article i really like your article.

  40. Hello, I stumbled upon your blog using yahoo. It is a well prepared article. I will definitely come back in order to browse more of your materials. Thanks for the post.

  41. Thanks admin hope to read more. Can I too got some information about Web development software

  42. This comment has been removed by a blog administrator.
  43. As I am new to the software development, this process is very useful for me. I am bookmarking and will definitely try to consider the points.

Leave a Reply