Google's updated Java coding guidelines
google-styleguide.googlecode.com
google-styleguide.googlecode.com
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?
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.
If a series of if-else statements can be rewritten as a switch statement, it will almost always be slightly more concise as a switch statement, and a more semantically correct representation of the logic.
Including an empty default statement come down to a matter of preference, but a pretty good argument for including it is that it favors the explicit over the implicit. It's better to be clear to other programmers that yes, you did intend to have nothing occur if the switched value didn't have a matching case. If you intend to handle all cases, you can put "assert false" or similar in the default case to be explicit about it. I can see that one going either way with enums, though, if you get a compile-time error when forgetting to handle a value (it's been too long since I've worked in Java to remember how it handles that).
For enums, the default case should be left out, since 'default' actually masks the missing case, as you note.
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).
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.
<th>First Name</th>
dons flame retardant suit
I suspect part of the problem is that there is a huge ecosystem of tools that work on plain text, and it's also easy to write more tools that work on plain text. You lose all of that when the database or parse tree is the primary representation, which means that when someone goes to make an adoption decision and their favorite tool doesn't work, they go back to the old way.
Otoh, if you're going to suggest binary structures, I wont be able to approve you if they're not easy to manage in Git.
I'm reminded of the project I recall reading about from steve yeggie regarding a language agnostic IDE framework (whatever happened to that anyways?). A language agnostic, semantically rich file format would allow entire classes of transforms to apply across all languages that could be marked up by the language agnostic file format.
There are so many possibilities here, and yet a non-trivial amount of programmers are still anchored by the supposed benefits of editing code from the console! Programmers should be the first to be looking forward rather than being tied down to the past.
The option you suggest could have been done since long and it hasn't: I'm inclined to wonder why. Probably text-file editing has reached the good-enough level where we've got enough tooling to cope with the drawbacks, and the basics of open source is, it has to be the most urgent solution for the one who takes the initiative.
}
}
}
That's the real shame of two-space indents. They basically require that all developers use monospaced fonts in their editors.
One of my most core principles for coding style is that the code should be equally readable in a proportional font or a monospaced font.
Why is that a core principle for me? Because I like proportional fonts. I don't use less-readable monospaced fonts when I write; I don't know why I should have to use them when I code.
You can't achieve this with two-space indents. When you view the code in a proportional font, it looks like one-space indentation.
For me, a proportional font is so much more readable, and lets me see so much more code at once, that I'm bummed that so many popular coding styles use conventions that only work monospaced.
To their credit, this coding standard actively discourages "column alignment". Abandoning column alignment is a wonderful thing: it gets you most of the way there toward having code that's perfectly readable in a proportional font.
It's unfortunate that they throw this benefit away by mandating two-space indents.
I had a phase like that about 15 years ago. In the end I just felt that it wasn't worth it. Whenever I looked at other peoples code through the lens of a proportional font, it would look awkward. Any attempt on the authors part of lining things up would just make things worse.
It turns out that proportional fonts are designed for text, not code.
I recognize that I'm in a tiny minority: the vast majority of developers code in monospaced fonts.
That's one reason why I value an editor that makes it easy to switch between a proportional font and monospaced, so I can code in the font I like or switch to a monospaced font when necessary. One of the few that does this well is Komodo, where each "theme" includes both proportional and monospaced fonts, and you can easily switch between them. (I just wish IntelliJ IDEA did this!)
It's also why I wouldn't presume to use a coding standard that worked only in a proportional font but looked bad in monospaced.
But to my eyes, a coding standard that works equally well in proportional and monospaced fonts is superior to one that works only in monospaced.
I must respectfully disagree that "It turns out that proportional fonts are designed for text, not code." All of the code I've written in the last 10-15 years is just as readable in a proportional font or monospaced. It really makes no difference at all which kind of font you read the code in, if the coding standard was designed to support both.
Fonts designed for programming typically take extra care of making sure that certain groups of glyphs look different: "O0" and "1lI" for example.
Now I'm curious: what proportional fonts do you use for coding?
It's not perfect; Georgia's lowercase o looks a lot like 0. But in practice that has never been a problem for me. And unlike many proportional fonts which have monospaced numbers, even the numbers are proportional in Georgia.
But I just like the way it looks and the readability it has - for my eyes.
I spend a lot of time reading code. I read other peoples code every day. To a very large extent, that code is going to use various layout tricks that are based on a monospaced font. Someone might line comments up like this:
// 1. Blah blah, blah
// blah and more blah.
// 2. Second piece of blah.
void func(int arg1,
int arg2...
Looking at code that wasn't specifically written for proportional fonts is death by a thousand cuts. The readability suffers greatly.
The problem for me is simply that a two-space indent looks like one space in a proportional font, and that makes it pretty hard to follow even one or two levels of indentation.
(And apologies for not replying sooner!)
That said, the C++ guide has a bunch of peculiar quirks.
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.)
That doesn't obviate the need for a style definition in the first place, and I'm happy to see the canonical version of such a document embodied in human readable text rather than in source code or some kind of meta-language monstrosity (a la xsd).
Given that Go does this far better than any other language that I can think of at the moment[0], maybe it's a case of the cobbler's kids making their own shoes.
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/...
[2] http://www.amazon.com/Clean-Code-Handbook-Software-Craftsman...
http://www.experimentgarden.com/2009/07/facts-behind-code-in...
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.
} else {
† I think K&R does make use of new line braces, for functions.
As a tab-using heathen, can somebody please explain why spaces would be preferable?
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.
Edit: Or an eclipse formatter config?
1) Don't