If you feel this erlang coding standard could benefit from a new rule, or some other modification, we would like to know!
Suggestions should be added as Github issues whose title begins with "Suggestion:", with the following format:
Do NOT do this! Do this instead.
%% bad
horrible_erlang_code() ->
just_awful.
%% good
beautiful_erlang_code() ->
much_better.Reasoning: I swear I heard Joe mutter this while taking a nap at the office.
One rule per issue.
When discussed and approved, it will be moved to either the Conventions or the Great Ideas list. If rejected, it will be moved to the Rejected list.
"The devil is in the details."
- Mies van der Rohe
These are the rules we try to abide by at Inaka, we're just sticklers for the rules and consistency! We don't expect everyone to agree with them, we just want to share them in the hope that they will be useful to other teams. That's why we insist on a 'reasoning' section for each rule.
Furthermore, we know for a fact that other erlang teams go against some of these guidelines on purpose. 😱
So obviously, we can't accept rules or guidelines which go against our way of doing things, because it would be disruptive for our team. Aside from that, we are very open minded and willing to see and adopt new rules, especially if they have some fundament.
In general, we try to follow the community. Erlang has some tough-earned battle experience on ways to do things, and we would be fools to ignore them.
So, to sum up, if you add some fundament or reasoning it'll be more likely to be accepted, even if it's "everyone else is doing it".