> Do not place spaces around code in parentheses or square brackets
The violation of this rule in Mono code is probably 60% of the reason I'd never want to contribute to it. I simply can't stand the abomination of looking at method calls like:
I used to be like this, but I have recently warmed to this idea. foo.bar( baz ) is a little "verbose looking", but when you generalize to arbitrary expressions:
foo.bar( baz => quux, gorch => 42 );
it starts looking a lot nicer. The foo.bar(baz) is really the outlier, and for the sake of consistency, you might as well add a space.
(That said, sometimes I don't, and I would never "care" one way or the other. If you are writing good code, where the spaces are is of little importance.)
Much of our non-.NET code adheres to this convention, and I've found I kinda like it. We don't require it for .NET code (C#, primarily), simply because that would require tweaking the IDE's default formatting behavior.
I am accustomed to something like the GNU style for method calls, which is
foo.bar (baz)
One of the things about Ruby that drives me nuts is that I can't always do this any more because of the complex lexical rules; in particular foo[4] and foo [4] mean different things.
Huh, they changed their Python style guide to be essentially Pep8 - it used to be two spaces, all CamelCase, very nasty. Anybody know when they did that?
> Does anyone know if Google has a Java style guide?
It's essentially very similar to the official Java Style Guide with some minor extra bits but, to get a flavour, you can just browse the source of any Google open-source Java project (e.g. http://code.google.com/p/gdata-java-client/source/browse/#sv...).
still useful advice, I always have two source files side-by-side. (At 1024x600 my eeepc has just enough room for a 160 column terminal in a font-size I can read).
Ok, virtual terminals (though I did use a VT220 for a good while). But I do still stick to an 80x24 screen. My theory is that if my code is too complicated for me to understand without expanding the screen, then it needs to be refactored or reorganized.
120x43 for me, thanks. 120 is a nice width, and I inherited 43 from the old EGA mode, and together they make a reasonable aspect ratio for cascading on the desktop.
According to Zed (who from my understanding has programmed in R a fair amount), these are some of the worst style guidelines ever: http://twitter.com/zedshaw/status/3690822968.
Zed Shaw trades on being loud & opinionated, so he pretty much has to say something :) On some points he's correct, but a lot of these are definitely found in R books, and R code in general. Periods certainly predominate in variable names everywhere, the reason being (as I understand it) that the underscore is synonymous with the assignment operator <- in S-Plus--pretty hideous. Verbing and camelcasing your function names is a bit outta left field, most functions tend to look like variables (indeed, technically they are.) Maybe it's not such a bad thing to distinguish them. kConstantName I definitely don't like, reminds me too much of Hungarian notation and CONSTANT just makes more sense and is more common. Almost no one uses = in place of <-, which is a shame because there is no <- key on the my keyboard :)
I know in a lot of Smalltalks _ was the assignment operator, because in an old prerelease version of ASCII the symbol in that position was ←. I suppose it's possible S had this confusion too, although it's pretty obscure.
The violation of this rule in Mono code is probably 60% of the reason I'd never want to contribute to it. I simply can't stand the abomination of looking at method calls like:
Ugh.