
Google's updated Java coding guidelines - ternaryoperator
http://google-styleguide.googlecode.com/svn/trunk/javaguide.html
======
erichocean
_Each switch statement includes a default statement group, even if it contains
no code._

I've never understood this one: adding `default` just prevents the compiler
from telling you when you forgot to handle a particular case...in which case
(heh), why use a switch statement at all? What are you buying over a series of
if-else statements, other than possible code reuse due to the fall-through
behavior?

~~~
mhurron
> What are you buying over a series of if-else statement

Code clarity. Depending on how and what you're doing in each case a switch
statement can be easier to read than a whole series of if .. else blocks.

And sometimes, given that they are equivalent, it's just a style choice on the
part of the programmer.

------
fournm
I don't like their indent guidelines, 2 spaces just feels incredibly "cramped"
to me with Java. I understand it with an 80 or 100 col line limit (I also tend
to 120, but 100's okay), but really, that's the only thing. I personally agree
with most of this and we have warnings generated on commit (thanks Sonar!) if
people don't follow some of these because they just lead to too many issues
down the line that are really easy to accidentally skip over.

I wouldn't imagine it would be too hard to get an IDE auto-formatter to follow
all of this (it's more or less what I use with mine, anyways).

~~~
mynameishere
If they used tabs instead of spaces, it wouldn't be an issue. People could
format code on their machine whatever number of columns they prefer. But no...
Spaces. Jesus. If you're looking at someone's HTML and it's got this kind of
thing strewn about...

    
    
      &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
    

...you know with certainty that you're dealing with either 1) an amateur, or
2) someone constrained by top-down corporate numbnuttery.

~~~
ender7
The debate over spaces vs. tabs is as old as time. Associating one side of the
argument with "top-down corporate numbnuttery" betrays a lack of familiarity
with the issue.

The fact is that whatever shop you work at should have an opinion one way or
the other, and you should follow it. Programmers will endlessly bikeshed the
issue regardless of which style is chosen.

~~~
lostcolony
Happily, the Tab-letariat can agree with the Space-eoisie that a separation of
the whitespace classes is necessary and good, and any commingling of the two
is an affront to God.

~~~
frou_dh
Hell, God is an amateur? He should know that tabs indent and spaces align.
There's nothing to be confused about.

------
blt
Interesting how this document focuses on formatting and naming, whereas their
C++ style is full of stuff like "don't use exceptions" or "avoid doing too
much work in the constructor." I guess Java guides you into a uniform coding
style much more than C++.

~~~
vinkelhake
C++ is a sprawling language that lends itself to many different coding styles.
It's also a language with many pitfalls. The guide both encourages a common
style so that things look uniform and a style that tries to avoid pitfalls.

That said, the C++ guide has a bunch of peculiar quirks.

------
thebear
I guess they were right when they said that the cobbler's kids wear no shoes.
It stumps me how one of the biggest, most powerful, and most resourceful
software companies in the world would have a bunch of humans write a document
on how to format source code, then have all their programmers read that
document and memorize it to the point where they can abide by it every second
of their work day. _Formatting code is the kind of thing that a computer can
do._ Write a program that formats the code the way you want it to be
formatted, and invoke it in the appropriate place. Preferably, make it
invokable in people's IDEs, so that they can go conformant whenever they wish.

~~~
nostrademons
It's better than many other companies, where nobody bothers to to write or
read that document, let alone use a formatter.

Anyway, this problem doesn't exist in Go (gofmt), C++ (clang-format), or at
least 2 of the in-house languages. It still exists in Java, Python, and
Javascript because of the lack of robust standalone parsers for those
languages, but there are editor plugins for vim, emacs, Eclipse, and I think
IntelliJ that automatically enforce the styleguide. (Google does not mandate a
single editor the way it mandates languages.)

------
datawander
My favorite rule is 4.1.1; always use braces even where optional. I think a
small fraction of the economy may have been damaged by the bugs caused by the
silliness of leaving out optional braces and then having another developer
come along and, well, you know how that goes :)

As someone who once read the Sun Java Style Coding [1] (which at a quick
glance, appears to be a super set of the Google style guidelines) standard
years ago and found it exciting and very helpful material, I unfortunately did
not get such a kick skimming through this. Perhaps it's because after having
read Clean Code [2], I feel that there is much missing that can lend itself to
better code.

[1]
[http://www.oracle.com/technetwork/java/javase/documentation/...](http://www.oracle.com/technetwork/java/javase/documentation/codeconvtoc-136057.html)

[2] [http://www.amazon.com/Clean-Code-Handbook-Software-
Craftsman...](http://www.amazon.com/Clean-Code-Handbook-Software-
Craftsmanship/dp/0132350882)

~~~
jrmenon
More on braces, I am squarely in the Allman camp for the reasons described
here:

[http://www.experimentgarden.com/2009/07/facts-behind-code-
in...](http://www.experimentgarden.com/2009/07/facts-behind-code-indention-
style-war.html)

It is amazing the old-style K&R still persists. I think there was one more
reason it was preferred in the early days which is not mentioned in the
aforesaid link: storage space which was also expensive. The K&R style saves a
new-line char which would be a significant saving in large codebases.

~~~
frou_dh

        } else {
    

just looks too good to be wrong. I used Allman style for my first ~10 years of
programming, then switched to "compact" style†, and didn't find it a big deal
to adjust. Brace concerns melt away just like parens do in Lisp.

† I think K&R does make use of new line braces, for functions.

------
guelo
I'm glad they got rid of the stupid m for mFieldName, it's been infecting all
the Android developers.

~~~
myko
This has never been part of Google's internal guidelines. This is part of the
Android guidelines which are separate and available here:
[http://source.android.com/source/code-
style.html](http://source.android.com/source/code-style.html)

------
Chromozon
+1 for no tabs allowed anywhere (must use spaces)

~~~
chroem
I've never understood all of the hate for using tabs instead of spaces while
indenting. My thinking has always been that tabs just make it easier to adjust
indentation.

As a tab-using heathen, can somebody please explain why spaces would be
preferable?

~~~
mtinkerhess
If everyone has to use the same level of indentation (as with spaces), then
everyone can adhere to the same width limit, and every source file in your
codebase will fit in the same sized window. If some programmer sets their tab
width to two spaces and then writes code that fits in 80 characters on their
screen, it might not fit in some other programmer's screen.

From a philosophical perspective, tabs just aren't necessary. You need spaces
in your source code in places besides indentation, but you don't need tabs.
It's simpler to only have a single type of whitespace character.

------
rgbrgb
Is there a checkstyle config floating around somewhere that I can use to
enforce this style?

Edit: Or an eclipse formatter config?

~~~
EtienneK
I think this might be it: [https://code.google.com/p/google-
styleguide/source/browse/tr...](https://code.google.com/p/google-
styleguide/source/browse/trunk/eclipse-java-google-style.xml)

~~~
rgbrgb
Thanks!

------
suyash
This is Oracle's Java Code Convention:
[http://www.oracle.com/technetwork/java/codeconv-138413.html](http://www.oracle.com/technetwork/java/codeconv-138413.html)

------
joncp
My single Java coding guideline:

1) Don't

