Project-wide

master-commit vs. branching

Only commit to master if the committed code does not leave the program in an unstable state.

E.g. a hotfix to insert a null-check can be committed to master, while rewriting how BahnLib handles pixel should be branched

Unit tests

All methods should be tested via unit tests, no matter how trivial they may seem

Commit details

Give commits semantic names. Write what you wanted to achieve, rather than how you achieved it.

E.g. "Keeped GraphicsArchive from crashing (Closing #7)"

Bad example: "Inserted null-check"

Code

Indent via tabs, align with spaces

Indent levels are logical levels of code, e.g. class-scope, method-scope, loop-scope These MUST be indented via tabs. They MUST NOT be indented with spaces

When aligning code or comments, always use spaces, as they are always one character wide in monospace fonts. Spaces MUST be used for alignment. Tabs MUST NOT be used to align.

Remove unused usings

Before pushing code, all new classes must have unused using-statements removed. If a class does not contain any using-statements, the class-file must start with a namespace declaration, not a new line.

Prefer static classes over hand calculations

Prefer using uint pixel = Pixel.Create(100, 0, 255); over uint pixel = 100 << 16 | 255; It's immediately clear what the code is trying to do and helps fixing bugs faster.

Document all public code

Code that can be accessed from outside BahnLib MUST be commented to best ability. Code that has other access modifiers (internal, private, etc.) SHOULD be commented to best ability.

Put code into regions

Code SHOULD always be member of a region

Avoid magic numbers if possible

Instead of writing items.GetLength(0), you should write items.GetLength(Width) and make Width a private constant. If magic numbers cannot be reasonably avoided with named constants, code MUST be commented.

e.g. item.SeekPosition += sizeof(int) * 5; // Skip the next 5 int fields in the stream (unused data)