This project is read-only.
Below are a set of "rules" that I follow when working on sauce, I ask that any one wanting to submit a patch or work on the source code follow them as well. I know not everyone will agree with these rules, however, it will be much happier for everyone involved if all the code "looks" the same. However, these are not hard and fast rules if the feature you are working on necessitates something and you can make a case for it.. its prob. ok.

General Rules

  • Use editor defaults for code spacing, tabs, etc
  • Avoid the use of var, especially when your are assigning the result of a function call
  • Put all objects (classes, enums, etc) into separate code files
  • Avoid the use of private classes
  • Do not "table" format your variable declarations

Coding Techniques

  • Fields
    • use camel casing for all field names
    • all fields should be private
    • start field names with an { _ (private int _myInt;) }
  • Use pascal casing for everything else
  • Organize your code as such (from top to bottom)
    • Fields
    • Properties
    • Constructors
    • Methods
  • Code with flexibility and extensibility in mind
  • Write short methods, when a method starts getting long please refactor and break it up

Unit Testing

  • Write a unit test to cover your code change
  • Make sure the unit test will pass for all data stores

Other Notes

  • Write XML comments for anything that you add (You dont have to right away, but lets try to keep the documentation up to date)
  • Try to follow the design patterns that are already present in the code base
  • Try not to put code that is specific to a particular RDBMS into the Core Library
    • If you do, make sure you can override it easily for the other supported data stores
    • Make sure you put the necessary code into the other data stores

Last edited Jul 13, 2012 at 5:54 PM by iamkrillin, version 5


No comments yet.