I really hate having to deal with coding-style issues. Generally I'll
accept anything that conforms to the Gluster  and/or Linux  coding
standards, and a whole lot that doesn't. However, I do believe that
consistency with existing code is important, and some practices are
demonstrably bad for readability and maintainability . So, here are
some rough guidelines.
* Tabs are eight spaces, and indents should be eight spaces as well.
Don't use indent=4 or pure spaces.
* Lines should *generally* be wrapped at 80 columns. An occasional
hard-to-avoid long line is OK, but code with a high density of
> 80-column lines becomes unreadable.
* Don't do assignments within conditions.
* Don't rely on precedence of boolean/arithmetic/comparisons (pretty
much any binary operation besides selection). Fully parenthesize nested
expressions involving these.
* Do put braces around if/else/for/while blocks, even if they only
contain a single statement.
* If you're going to use a goto-like flow of control for exception
handling, use a real goto. Break statements in a "do ... while (0)" are
just label-less gotos, which is less readable and can cause unexpected
breakage if the form is nested.
I'm not going to demand that existing code be changed, and I'm generally
not going to clean them up myself (though I will be pushing a patch for
some of this in the uidmap code shortly), but as we move forward I'd
appreciate it if people could try to follow these guidelines. Thanks.
I discarded the commit email because it was long and contained no
information that hadn't been in other messages, but you can see it in
the git tree. Thank you, Kaleb, for all of your hard work on this.