Guidelines for better code writing

24 בספטמבר 2012

3 תגובות


In the last few weeks I have seen code written by many developers, each one have it’s own style and almost the same code can be written in different ways by different developers. some asked me what are my guidelines for writing code, without further ado, here it is, divided in categories:

  • Goals:
    • Robust – The code you write shouldn’t fail unexpectedly and stop, only when you intend it to stop it will do so.
    • Only what you need Implementation – Implement only what you needs, don’t implement nice to have features that needs testing and heavy maintenance afterwards.
    • Don’t over abstract – Use design patterns as much as you can when needed but don’t bend you code and logic so it sill match a design pattern.
    • Implementation – Stay focus on what you need to implement, ask yourself whether the code you written match the requirements.
    • Performance – your code executes in the time table given in the spec.
    • Readable – Ask your self will a fellow developer with out you assistance be able to understand your code and what you meant in each line of code and how hard will it be for him to fix a bug in your class.
  • Solution guidelines:
    • Logger – every software should support logging even a simple one.
    • Minimize module-scope dependencies.
    • Refactor as much as you can, delete obsolete code and unused code.
    • Versioning – Keep a version number of each solution.
    • Use coding standards (I use IDesign) for all classes.
    • Be consistent whatever you do, if you choose coding standards and guidelines stick with them.
    • Code the simplest  as you work, refactor later.
    • reduce Abstract class to the minimum prefer interfaces and help classes.
  • General guidelines for classes:
    • Put all the ‘using’ in the begging of the class and only the one’s you are really using.
    • Access members with 'this.’ (e.g. this.Age).
    • Delete comment out code if you are using any kind of source control (and of cause you should).
    • Don’t use operator overloading.
    • Don’t use static methods and fields (only if really, really necessary).
    • Don’t comment much, only when where an algorithm should be explained, the code should be written as a story and be self explanatory.
    • Nested classes – No real value of hiding them, someone might need them.
    • Don’t use ‘ref’ for method parameter.
    • Avoid at all cost GOTO statements.
    • Declare each variable in a new line.
    • Avoid usage of region – if you think some code should be in a specific region, extract it in to a method.
    • If you think of something to add later and you want to comment it use the convention “TODO:” for it.
    • Handle those to so as you write code, don’t forget them.
    • New line for each curly braces.
    • Put curly braces for everything, even for one row clause.
    • Minimize casts.
    • Avoid direct casts, use “as” parameter;
    • Avoid empty lines in code, only use empty lines to separate regions of logical, and for that, only one empty line.
    • Only lock private members.
    • Avoid lock(this)
    • Size:
      • more than 6 arguments per method.
      • No more than 10 fields per class.
      • No more than 200 lines per method.
      • No more than 1500 lines per class.
      • No more than 100 characters per line of code.
      • Only 1 class per file.
      • Only 1 namespace per file.
  • Exceptions:
    • At the execution entry point, try and catch all exception thrown and not handled in other parts of you application ( as well as ‘CurrentDomain_UnhandledException’).
    • Always pass descriptive string into the contractor of the exception before throwing it.
    • Use specific exception as much as possible (e.g. throw ArgumentException for wrong method input parameter).
    • Rethrow caught exceptions correctly – Don’t create a new exception, throw the one you caught.
    • Avoid empty catch block.
    • Catch exception only if you intend to do something with it.
  • Unit Tests:
    • Try to get the maximum code converge as possible not less than 60% try to reach at least 75% before deliver, the more the better.
    • Check for good and consistent naming conventions for tests.
    • For every found bug at least one unit test should be written.
    • Write tests for every logical code.
    • Don’t write test for logical less codes (properties and such).
    • Don’t write tests for integration code.
    • Make should before every check in that all the tests execute successfully, at best integrate it with the build server. (in VS2012 you can select that every build all the tests should be executed – really nice feature).
    • For each class create a test class for all the tests for the class call it NameOfTheClassTests (e.g. class name DoSomething, test class name DoSomethingTests).
    • Each test should be fast and will not take more the 150ms.
    • Tests Should not couple with other tests.
    • Each test should test only one thing, for each method write number of tests and don’t tests all the method’s logic in one test.
    • Make sure there is no more than one mock per test.
    • Use mocking for isolate logic (Shims and Stubs in Microsoft fakes).

Well, that it is, there are probably more but I already so used to them I can’t think of them right now, always remember this, the code you write will be read by many other developers, so think for your self, and try to make your code as readable as much as you can.

Happy coding !

הוסף תגובה
facebook linkedin twitter email

כתיבת תגובה

האימייל לא יוצג באתר. שדות החובה מסומנים *

3 תגובות

  1. ArnonGold25 בספטמבר 2012 ב 9:55

    Great guidlines, the only problem is that the programmers that understand them – don't need them. and the programmers that needs them – don't understand them….


  2. short_methods25 בספטמבר 2012 ב 10:08

    No more than 200 lines per method – should be 20

  3. menashe27 בספטמבר 2012 ב 0:10

    did like it. too general. not suitable for everybody.
    one can have his own coding standards