There's a number of questions in there that I don't think have correct answers. There also wasn't a question on vertical whitespace. I can't see my responses but the whole thing basically boils down to breaking the unit/modifier theory on whitespace.
Basically, pick a unit (four spaces appears to have consensus) and then decide on modifiers for particular cases. For the most part the modifier is generally (N+1) where N is the modifier for the previous scope. There are a few cases where that needs to change though (ie, function argument continuation because it can be confusing to have it at the same alignment as the contents of the function). Then there's also the question on when to avoid indentation entirely. For instance in the funciton invocation example (re:run/3 IIRC) I would've used a temporary variable for the long options parameter rather than try and write it directly as an argument. Since everyone else is mentioning whitespace between functions, I much prefer two with a single line between function clauses when lots of clauses exist. The reasoning for this is that when you get a big function with many clauses (think complicated gen_server handle_call implementations) its easier to read the whole thing if there's a bit of whitespace, and each clause is generally independent anyway so the whitespace can signify that a bit. And obviously if we have one line of whitespace for clauses then two between functions is necessary so that its harder to confuse function boundaries. For functions that fit on a single line I tend to omit the single whitespace line and also for functions that are recursive bodies (ie, the standard, "foo([], Acc) -> lists:reverse(Acc); foo([Thing | Rest], Acc) -> foo(Rest, [do_thing(Thing) | Acc])." pattern. And that's all I have to say about that for now. On Fri, Mar 28, 2014 at 4:11 PM, Joan Touzet <woh...@apache.org> wrote: > Time for everyone's favourite topic: whitespace standards. > > I know many of you are fed up with not being able to auto format in > your favourite editor and match the CouchDB Erlang coding standards, or > receiving pull requests that are formatted poorly. > > I'd like to fix that with an appropriate whitespace standard, and > supplementary plugins for vi and emacs that will just Do The Right Thing > and let us all stop worrying about whitespace corrections in pull > requests. > > The basic rules seem to be: > > * Indent everything 4 spaces (not 2 or 8, and no tabs) > * Single blank lines between functions > * No blank lines between guarded versions of the > same function (e.g. couch_btree.erl#L36-L47) > > but beyond that there is some inconsistency in both the code and in > discussion with other devs. > > Here's a short poll I threw together in Google Docs. I'd love it if you > could take 5 minutes to reply to it. Early next week I'll summarize and > post the results. Once we have agreement we can toss up a super small > Markdown guide / wiki page / whatever and get started on the emacs/vi > modifications to support it. > > https://docs.google.com/forms/d/1b7KcQGgNbSCZVRwLjrUl5Z6C2TBx8X1btlU5fwrNHpg/edit# > > Thanks, > Joan
