On Monday, February 23, 2015, Gabriela Gibson <[email protected]> wrote:
> Hi All, > > Jan and Peter asked to start a discussion about coding standards on the > mailing list.(https://issues.apache.org/jira/browse/COR-46) > > I think the Subversion project has a very good strategy, see here: > http://subversion.apache.org/docs/community-guide/conventions.html > Personally I think we could easily just copy their rules and will not > regret it, plus their rules have stood the test of time. The "just" is a big word, as far as I can read we would need to reformat the whole code. As long as - those who program agree to the rules - they are not overwhelming complicated - they do not force to spent many hours refactoring the current source I am fine with it. just using the SVN standard seems like a lo of work? btw. I really do not like that the put the return type on a separate line. > > That all said, whatever rules are chosen I am fine with ;-) > > > Chars per line > -------------------- > > My personal rationale for liking 70 chars per line is that more gets > tedious to read (as in line too long) and, I like to be able to use emacs > over ssh, or, if local, -nw style. > > +1 like that, I too hate long lines. > Being a bit myopic (and a fan of my screen being at least 1m away from me), > I also manage to max out a 15" screen with just 70 chars, but my other half > (who is eagle eyed) manages to fit two editor windows next to each other > with 70 char wide each. > > The other thing this does is introduce shape to the code, because long > lines now have to be broken up. > > This help a lot when glancing over stuff on the quick, you see 3 lines and > know that this function declaration has 3 parameters, whereas if it's one > line, you have to count 'em. (and think! ;-) Plus, you can find stuff by > shape too, which can at times be useful, and if you have a long parameter > list, having the vars on their own line is also useful. (easy to count, and > easy to spot if they are in the wrong order for some strange reason and so > on). > > So, 70 is quite a good number I think, plus it's traditional for most > software I've seen, and new people will find it easy to get used to our > code as well this way, since it'll looks instantly familiar and they won't > have to change their set ups (and habits) very much and find it easier to > switch between projects during the same day too, if they don't have to > remember greatly differing rules. (I swear that fingers have brains too). > > > Spaces before variables > --------------------------------- > > Regards spaces between variables --- I think it makes it easier to scan > quickly, that way you don't have to wonder, is this a full stop or a > comma? Also, it makes a parameter list read more like a sentence, making > the individual type or variable much easier to spot --- a long or short var > name is instantly recognisable, without having to read the entire thing. +1 > > > Tabs/spaces > ------------------ > > Everyone uses spaces, tabs usually is not popular, for a very good reason > which I forgot by now. Personally I like 8 spaces (which grosses everyone > out, heh) but 4 is a good (better!) number, it's separates code levels > nicely visually without making nested code too crowded. (Some people use 8 > spaces to prevent code that is too deeply nested, notably, the Linux kernel > style guide does this.). I was used to 2 but Peter convinced me that 4 is double so good. > > > Brace styles > ------------------ > > K&R or Gnu --- K&R has the advantage to preserving vertical screen real > estate, Gnu is easier to spot (you know where the brace sits and don't have > to scan to the end of the line, plus it's easier to copy an entire block). > I think both styles are equally fine, just not at the same time. To change that would be a real chunk of work ( or do I see it wrong), so I would prefer to keep the style we have. > > > Page breaks > ------------------ > > I find them handy if the file is large, but can live without them. i have never used it, and have no opinion. > > > > ============================================================================================== > > > I also think that we should have the same discussion about log messages. > There is a lot to be said for uniformity (makes searches of the logs > visually much easier and also ensures that the logs are as informative as > can be) and I do like the svn rules here, and they also help a lot in > making patches higher quality and much easier to comprehend for readers. yeah we could be better at log messagees (read I should be better) rgds jan i > > Take a look: > > http://subversion.apache.org/docs/community-guide/conventions.html#log-messages > . > > > anyway, I hope you enjoyed reading this! > > G > > -- > Visit my Coding Diary: http://gabriela-gibson.blogspot.com/ > -- Sent from My iPad, sorry for any misspellings.
