Contributing

How do I contribute?

Here's some simple steps on how contributing works.

• Fork the master branch (Or another branch in case of critical bugs)
• Modify the branch until satisfied
• Create a pull request
• Once accepted it'll be merged into the respective branch

Contribution guide-lines

Curly brackets

Starting curly brackets must never be placed on a new line. Ending curly brackets must always be placed on a new line. There is one exception to the above, which is for getter properties.

Invalid:

if (foo)
{
}

Invalid:

if (foo) {
} else {
}

Valid:

if (foo) {
}
else {
}

if, else if and else

Do not create if, else if or else statements without brackets.

Invalid:

if (foo) bar();

Valid:

if (foo) {
    bar();
}

Error handling

Attempt to handle as little errors internally with try/catches as possible. If exceptions are thrown, work-arounds shouldn't be try/catches. It should be fixed properly. Error handling is also something that should be done by the project implementing Diamond and not Diamond itself.

Third-party code and reliability

Do not rely on third party code at anytime. Diamond should always be able to work stand-alone. The only time third party code integration is allowed is through vibe.d. Always remember that vibe.d is only accessible through the WebServer and WebService version and thus must always be ensured to only be referenced through that.

Versions

You must decide what version specific code blocks belong to when you're developing for Diamond. There are three code blocks. WebServer, WebService and everything else. WebServer and WebService are special in the way they require vibe.d. And thus anything that is related to vibe.d must be encapsulated as one of those; it's important unecessary code isn't compiled either. An example is views. Views are only compiled for WebServer, where WebService doesn't have them at all. It's an important fator in compile-time for Diamond.

Compile-time

If things can be evaluated at compile-time, do so.

public, private, protected and static

You must never declare members of a struct or class by the above directly. They mustn't y always be declared by scope with either : or { } They must also be indented to the same level as the first member inheriting the attribute.

Invalid:

public void foo() {
}

Valid:

public:
void foo() {
}

Properties

Properties should always be declared by scope and not per field. Getter properties are the only fields allowing ending curly brackets on the same line.

Invalid:

@property auto foo() { return _foo; }

@property auto bar() { return _bar; }

Valid:

@property {
    auto foo() { return _foo; }

    auto bar() { return _bar; }
}

Compatiblity

Diamond should always be as backward compatible as possible, to make sure existing projects implementing Diamond doesn't break.

This list will be updated.