|
|
@ -9,45 +9,70 @@ See [Community and Resources](README.md#community-and-resources). |
|
|
Code style |
|
|
Code style |
|
|
---------- |
|
|
---------- |
|
|
|
|
|
|
|
|
The following rules must be followed: |
|
|
|
|
|
|
|
|
The following rules apply: |
|
|
* Do not introduce trailing whitespace |
|
|
* Do not introduce trailing whitespace |
|
|
* Do not mix spaces and tabs |
|
|
|
|
|
* Do not introduce lines longer than 80 characters |
|
|
|
|
|
|
|
|
|
|
|
The following rules should be followed: |
|
|
|
|
|
|
|
|
* We use spaces for indenting only |
|
|
|
|
|
* Try not to introduce lines longer than 80 characters |
|
|
* Write small functions whenever possible |
|
|
* Write small functions whenever possible |
|
|
* Avoid having too many clauses containing clauses containing clauses. |
|
|
* Avoid having too many clauses containing clauses containing clauses. |
|
|
Basically, avoid deeply nested functions. |
|
|
Basically, avoid deeply nested functions. |
|
|
|
|
|
|
|
|
[erlang-mode (emacs)](http://www.erlang.org/doc/man/erlang.el.html) |
|
|
|
|
|
indentation is preferred. This will keep the code base consistent. |
|
|
|
|
|
vi users are encouraged to give [Vim emulation](http://emacswiki.org/emacs/Evil) ([more |
|
|
|
|
|
info](https://gitorious.org/evil/pages/Home)) a try. |
|
|
|
|
|
|
|
|
Follow the indentation style of existing files. The [erlang-mode for |
|
|
|
|
|
(emacs)](http://www.erlang.org/doc/man/erlang.el.html) indentation is going to |
|
|
|
|
|
always work. Other users may want to use 4-width spaces and make sure things |
|
|
|
|
|
align mostly the way they would with Emacs code, or with the rest of the |
|
|
|
|
|
project. |
|
|
|
|
|
|
|
|
|
|
|
Where possible, include type specifications for your code so type analysis |
|
|
|
|
|
will be as accurate as possible. |
|
|
|
|
|
|
|
|
|
|
|
Please add comments around tricky fixes or workarounds so that we can |
|
|
|
|
|
easily know why they're there at a glance. |
|
|
|
|
|
|
|
|
Pull requests and branching |
|
|
Pull requests and branching |
|
|
--------------------------- |
|
|
--------------------------- |
|
|
|
|
|
|
|
|
Use one topic branch per pull request. If you do that, you can add extra commits or fix up |
|
|
|
|
|
buggy commits via `git rebase -i`, and update the branch. The updated branch will be |
|
|
|
|
|
visible in the same pull request. Therefore, you should not open a new pull request when |
|
|
|
|
|
you have to fix your changes. |
|
|
|
|
|
|
|
|
All fixes to rebar end up requiring a +1 from one or more of the project's |
|
|
|
|
|
maintainers. When opening a pull request, explain what the patch is doing |
|
|
|
|
|
and if it makes sense, why the proposed implementation was chosen. |
|
|
|
|
|
|
|
|
|
|
|
Try to use well-defined commits (one feature per commit) so that reading |
|
|
|
|
|
them and testing them is easier for reviewers and while bissecting the code |
|
|
|
|
|
base for issues. |
|
|
|
|
|
|
|
|
|
|
|
During the review process, you may be asked to correct or edit a few things |
|
|
|
|
|
before a final rebase to merge things. |
|
|
|
|
|
|
|
|
Do not commit to master in your fork. |
|
|
|
|
|
|
|
|
Please work in feature branches, and do not commit to `master` in your fork. |
|
|
|
|
|
|
|
|
Provide a clean branch without merge commits. |
|
|
Provide a clean branch without merge commits. |
|
|
|
|
|
|
|
|
Tests |
|
|
Tests |
|
|
----- |
|
|
----- |
|
|
|
|
|
|
|
|
As a general rule, any behavioral change to rebar requires a test to go with it. If there's |
|
|
|
|
|
already a test case, you may have to modify that one. If there isn't a test case or a test |
|
|
|
|
|
suite, add a new test case or suite in `test/`. |
|
|
|
|
|
|
|
|
As a general rule, any behavioral change to rebar requires a test to go with |
|
|
|
|
|
it. If there's already a test case, you may have to modify that one. If there |
|
|
|
|
|
isn't a test case or a test suite, add a new test case or suite in `test/`. |
|
|
|
|
|
|
|
|
|
|
|
To run the tests: |
|
|
|
|
|
|
|
|
```sh |
|
|
```sh |
|
|
$ ./bootstrap |
|
|
$ ./bootstrap |
|
|
$ ./rebar3 ct |
|
|
$ ./rebar3 ct |
|
|
``` |
|
|
``` |
|
|
|
|
|
|
|
|
|
|
|
The rebar3 test suite is written using Common Test. As many of the tests as |
|
|
|
|
|
possible are written by using the programmatic rebar3 API rather than |
|
|
|
|
|
by running the escriptized project directly. The tests should be restricted |
|
|
|
|
|
to their `priv_dir` and leave the system clean after a run. |
|
|
|
|
|
|
|
|
|
|
|
If such tests prove hard to write, you can ask for help doing that in your |
|
|
|
|
|
pull request. |
|
|
|
|
|
|
|
|
|
|
|
For tests having a lot to do with I/O and terminal interaction, consider |
|
|
|
|
|
adding them to https://github.com/tsloughter/rebar3_tests |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Credit |
|
|
Credit |
|
|
------ |
|
|
------ |
|
|
|
|
|
|
|
|
@ -62,10 +87,10 @@ To do that run `./rebar3 ct` and `./rebar3 as dialyze dialyzer`. |
|
|
|
|
|
|
|
|
#### Structuring your commits |
|
|
#### Structuring your commits |
|
|
|
|
|
|
|
|
Fixing a bug is one commit. |
|
|
|
|
|
Adding a feature is one commit. |
|
|
|
|
|
Adding two features is two commits. |
|
|
|
|
|
Two unrelated changes is two commits. |
|
|
|
|
|
|
|
|
- Fixing a bug is one commit. |
|
|
|
|
|
- Adding a feature is one commit. |
|
|
|
|
|
- Adding two features is two commits. |
|
|
|
|
|
- Two unrelated changes is two commits (and likely two Pull requests) |
|
|
|
|
|
|
|
|
If you fix a (buggy) commit, squash (`git rebase -i`) the changes as a fixup commit into |
|
|
If you fix a (buggy) commit, squash (`git rebase -i`) the changes as a fixup commit into |
|
|
the original commit. |
|
|
the original commit. |
|
|
|
Fred Hebert
10 年之前
Tristan Sloughter