Legend:

If you're not sure what the conventions are, then ask. If you can think of a better way of doing it then let us know on the mailing list. This goes for development process and the use of library functions, as much as formatting and commenting style. The DDC project was started some time ago, and times change...

7

7

8

== General Rules for all Languages ==

9

10

=== Comments ===

8

== Comments ==

11

9

* '''Critital:''' If you tried to understand something but gave up before doing so then open a ticket on the trac and set the ticket type to `document`. This is a bug against the maintainability of the software. Don't assume that the next person that looks at the same code will be able to make more sense of it than you could, or have more patience.

* We try to avoid having multiple competing layout styles in DDC. Having different styles creates "accidental complexity", that is, syntactic differences in the source that don't equate to real functional differences. If we change styles then they should be documented so the we can migrate the code base towards using them.

* If part of a variable name reflects its type, then put that part out the front. For example, source code variables of type `Shared.Var` should be named something like `vThing`, with a `v` out the front. Sets or lists of variables should be named `vsThing` with `vs` out the front. Avoid using names like `thingVar` and `thingVars`. We're not mandating Hungarian Notation, but if you're going to name a variable after a type anyway, then put the type part out the front.

82

81

83

=== Structure ===

82

== Structure ==

84

83

* Keep the sizes of the modules small. If a module has more than about 400 lines then consider breaking it up. Modules with just 100 lines are fine. Using small modules makes them easier to digest, forces you to think about the overall structure of the code, and helps parallel builds.