[quote=“Z-Man,post:56,topic:38743”]
WHY?!? Expand tabs to spaces >_<
As for curly braces, always on a new line. Partly because it’s what I’m used to reading and partly because my CS teacher would not accept programs written any other way -_-
EDIT:
Oh and, this
What is wrong with you?! Tabs are more convenient and easier to delete. I see no upsides to spaces.
And your teacher sucks balls. ;D
I use spaces, because if I copy and paste code into a bug or example, tabs get reformatted to something weird, or sometimes just stripped outright. This is made worse when tabs and spaces start getting mixed, which is always going to happen when you want to align things like long parameter lists, because they never manage to line up nicely on a tab stop. I’d use tabs everywhere if the formatting weren’t so damn “unportable”.
In my religion…
Method javadocs are necessary to document method contracts. For all my code, no method returns null and no parameter can be null unless specified in the javadocs. Eg “@param moo Can be null. @return May be null.” I also use javadocs to let the user know about a default value. Eg “Default is X.”. Javadocs are also needed to document what methods can be overridden by a subclass and in that case, what the default implementation does and if super must be called. Method javadocs are NOT the place for stories about how everything works, example code, unimportant implementation details, reasons why alternate implementations were not used, etc.
Class javadocs explain what the class is for and can be used to also explain how it works, but should be concise. External documentation is the place to go into great detail. Some people try to outline the entire usage of a class and end up referencing many methods in the class javadoc, but I prefer explanations on methods where it makes sense.
Implementation details do no belong in javadocs at all unless it is somehow relevant to the user (eg, big O). Non-javadoc comments often contain implementation details and are necessary when they help code to be understood. Think of them as “private” comments. I use them extremely sparingly and as others have mentioned, often code can be written so that non-javadoc comments are not needed. However, javadoc comments are different and are needed to clarify method contracts so that people know how to use your code.
Remember that comments do not replace real documentation. As such, keep them concise and simple, incomplete sentences are fine. In ALL my comments and documentation I try to avoid the word “you”. Give it a try, it makes everything more professional and more concise.
Of course, all this is only relevant when writing OSS libraries or when coding for work where others may need to maintain your code. For private projects, do whatever the hell you want.
So don’t align things. No ASCII art in source code! I use Eclipse to format, so never have mixed tabs and spaces. Tabs are better because the individual can decide how wide they want a tab. I prefer a 3 column tab, as 2 columns isn’t quite enough, and 4 is a bit too much and 3 gives me horizontal space.
Javadoc is one of the saviours of Java, mind. There’s nothing remotely as pervasive or supported for any other language I’ve ever used or seen.
Cas 
Such a short sentence to capture the entire essence of it - but it does. Win!
totally option two, I usually do not care in other people’s code, but when I look at my one, that extra line helps me to better differentiate between methods/loops which when I am scrolling through huge classes is very helpful :).
hehe no kidding. Maybe I am just not experienced enough but when I have 1k plus lines of code I very much like to see exactly what is what. Later as I will get more experianced I may go the other way so, as someone has already said, I see more code on the screen at once.
Javadoc is API documentation that just happens to be written as specially formatted comments. It’s definitely a different thing than code comments, and I can’t say enough how huge a fan I am of writing lavish API documentation. Actually I’m a huge fan of someone else writing lavish documentation, because I’m terrible about it