On 4/26/16 12:32 AM, Johan Hedberg wrote:
Hi,
On Mon, Apr 25, 2016, will sanfilippo wrote:
9) I think the 79 character line length is not really helpful. I¹d rather
see slightly longer lines. I often prefer To use longer names for example
int res = hal_adc_get_resolution_mvolts(padc) to make it clear what is
going on and the units, but that may make lots of wrapping with an 80
column limit. This simple statement used 45 characters already. I know
its been standard forever, but screens are 5x wider than they used to be.
Can¹t we stretch this to 120. I hope you are reading this email with
80 columns!!
Good luck getting others to change this :-) I would be fine personally.
I almost always have my editor split with at least two side-by-side
views of the source code so I can easily compare different places and
copy/move code around. At least on my laptop display I need to have a
large enough font that if the line width was much greater than 80 this
wouldn't be possible.
I do the same. Plus, going over 80 lines likely means you need to
refactor your code into functions and use shorter function names (hint,
hint.)
This:
#define PRETTY (0)
#define VERY_PRETTY (1)
#define BEAUTIFUL (2)
What's with the obsession of putting "atomic" things like integers
inside an extra pair of parenthesis? :) Seems excessive to me. Should
the coding style document make a note of this? (which ever way is the
preferred convention)
I'm not passionate about this one either way, I do keep atomic things
like integers within parentheses, because:
(1) it keeps it consistent with non-atomic things
(2) atomic things can become non-atomic things, and i want to avoid
breakages due to laziness when they do.
Another thing, should this document also cover git commit message
conventions? Summary line prefixes, line widths, etc?
I think that would be great. Johan, you've probably had the best
experience here with these things, would you mind taking a first stab at
a set of conventions?
Sterling
