General Design Principles

  1. Simplicity, Simplicity, Simplicity
  2. Components / Utility code that is generic and can be used across different companies
  3. Easy to use API's as a result of Test Driven Development & real-world needs / use-cases
  4. 0 xml config files ( You should not require any xml config file to be required to configure any components ). Programmatic / Fluent validation only.
  5. 0 third-party / external dependences ( This project does not use any other dlls other than Nunit for unit-tests )
  6. Concise names
  7. Good documentation and examples of all components

Coding Conventions

Listed below are the coding conventions that should be generally followed. There may be instances where 1 or more of these conventions may not apply.
Every single coding convention ( e.g. naming conventions for members / classes) has not been listed because for the most part they are in line w/ code conventions in most other projects such as Enterprise Library, Spring Core, and conventions listed by microsoft itself. However the conventions listed below are particularly important within commonlibrary.

Code length
  1. Methods should not bee too long ( Ideally a method should fit on a computer screen
  2. Classes should not be too long ( Perhaps no more than 1000 lines of code per class ? )
  3. Avoid methods with more than 7 parameters
  4. Avoid over-engineering
  5. Avoid long names for variables, parameters, classes, methods etc.

Visual Styles
  1. Private / protected data members must be prefixed with '_' as in private int _userId;
  2. 2 lines of space between methods
  3. 3 lines of space between classes
  4. Classes should have the following sequence of code in sequential order:
    1. Static code : public properties, methods
    2. Instance code: public constructors, properties, methods
    3. Instance code: protected properties, methods
    4. Instance code: private properties, methods

Other
  1. Avoid cyclic references within the projects ( Can be detected using NDepend ) - currently being cleaned up.
  2. Document all public / protected methods

Process for bug fixes

  1. Make bug fix
  2. Add / update unit test for the bug-fix ( Unit Tests are located in the "Unit Tests project"
  3. Run all unit-tests unit NUnit. ( Make sure to run all the unit-tests not just the unit-tests for your project, this is because there may be a possiblity that the component you changed/fixed is being used in another component )
  4. If tests pass, check-in code to repository(SVN)

New components

  1. New components should be in their own namespace
  2. New components should be in their own folder
  3. A typical set of classes that tend to be included in a component are "Component", "ComponentService", "ComponentConstants", "ComponentHelper", "ComponentValidater" etc.
  4. New components should have unit-tests
  5. New components should have an example app ( See below )
  6. Each file that is added or part of a new component must contain the "License" text at the top of the file ( See any file as an example )
  7. Each component's namespace must begin w/ "ComLib"

Example Code

  1. Example code is located in <ROOT>\src\Lib\CommonLibrary.NET\Samples for various components
  2. Examples are compiled as part of CommonLibrary.NET to make sure the examples are valid w/ respect to any updates
  3. Example code for a new component be named with convention being Example_<ComponentName> e.g. Example_Arguments
  4. Every example should be tested after being written the first time and after any changes to the component that its associated with.
  5. Every example implements the IApp interface

Last edited Apr 11, 2011 at 5:02 AM by kishore_reddy, version 13

Comments

No comments yet.