This shows you the differences between the selected revision and the current version of the page.
| — | contribute:coding_style_guidelines 2009/03/31 16:34 current | ||
|---|---|---|---|
| Line 1: | Line 1: | ||
| + | ====== Coding Style Guidelines ====== | ||
| + | These are general guidelines for SharpOS code. | ||
| + | |||
| + | * Follow the [[http://web.archive.org/web/20070227070827/http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpgenref/html/cpconnetframeworkdesignguidelines.asp|Microsoft design guidelines]] for the .NET Framework. | ||
| + | * Follow the [[http://www.mono-project.com/Coding_Guidelines|Mono coding guidelines]]. | ||
| + | * Follow good object oriented practices: | ||
| + | * Hide implementation details. | ||
| + | * Abstract common concepts into base classes. | ||
| + | * Keep coupling to a minimum: a class may depend on several basic types, but should depend on few of its peers. | ||
| + | * Keep cohesion to a maximum: a class should be focused on a single concept, embodied in the class's name, and should depend on as little data as possible to accomplish its goals. | ||
| + | * Remember that there are several ways to tie two classes together, such as inheritance, aggregation, and event handling. | ||
| + | * Always aim for reusability. The more easily a class can be lifted from its current project and used in another project, the more reusable it is. A good example is that of a file system: A FileSystemDriver that depends on peer drivers and a static I/O scheduler would be difficult to reuse. A FileSystem that is self-contained and depends on an abstract scheduler supplied in its constructor is easy to reuse. | ||
| + | * Strike a balance between virtual/abstract methods and final methods. Sealed types and final methods are fast, but cannot be overridden. Virtual methods are slower, but can be overridden. | ||
| + | * Avoid the singleton pattern. Singleton patterns are used where there should be only one instance of a type in an AppDomain. This is rarely ever the case; in fact, it's pretty much just another way of making a global variable, and it makes unit testing hard. | ||
| + | * Try to type variables and field names in full; avoid abbreviation. Abbreviation makes code harder to read. | ||
| + | * Make liberal use of named constants, where it makes sense to do so. | ||