Development Model

[cgarciae]

The current proposal is this:

• Should be release/milestone based
• Features for each release/milestone should be defined in the roadmap
• Each feature should be implement broken first. Might be in the form of a new class with empty methods, new empty methods on an existing class, or an empty branch of code on an existing method.

Example:

class SomeClass
{
    C newMethod(A a, B b)
    {
        throw new UnimplmentedError();
    }

    D existingMethod (F f, H h, X newParam)
    {
        // Existing code
        ...
        // New Code
        if (someCondition)
        {
            throw new UnimplmentedError();
        }
        ...
    }
}

• Empty test for each feature should be written along with the broken implementation. Example

group ("New Feature X", ()
{
    test ("some test", ()
    {
        throw new UnimplementedError();
    });
});

• Tests should be checked by Travis or equivalent system. (Although I don't if there will be problems with GitHub since technically at least 1 test should fail until the very end).

The benefits of this are that once we agree what is to be implemented, and after we write the "interfaces" as empty methods/code branches and the empty tests, then development becomes easier because anybody can just look for missing sections and implement them, they just have to make sure it passes its corresponding tests, if there are none or are empty then its his job to also implement these.

[azenla]

I like it. Although, I would like to point out that we should always follow the Dart Style Guide.

[azenla]

Also @cgarciae, we have the meta label for issues that deal with non-code/documentation stuff, like this.

[cgarciae]

@kaendfinger Totally agree on the style guide. If I made/make any errors, please tell me :) Will use tags, sorry, I don't regularly tag issues.

[cgarciae]

@kaendfinger Should we include development information like this at the end of the roadmap? Maybe like some standard conventions on how to write code and develop.

[azenla]

@cgarciae No problem, I don't use them much either, but I think for something this popular it is necessary.

This is what it looks like with the Style Guide:

class SomeClass {
  C newMethod(A a, B b) {
    throw new UnimplmentedError();
  }

  D existingMethod(F f, H h, X newParam) {
    // Existing code
    ....
    // New Code
    if (someCondition) {
      throw new UnimplmentedError();
    }
    ...
  }
}

[azenla]

https://www.dartlang.org/articles/style-guide/