That tends to be a matter of opinion or, all too often, screaming disagreements. I might not have blank lines in all the places you do, and I definitely would drop the comments after each closing brace, but otherwise I think it's fine. You used spaces, not tabs, right?
I would also suggest that whatever you do, be consistent. You sometimes put a space before =, and sometimes not. And sometimes a space after the =, and sometimes not. Same for >, < and other similar symbols. Try picking one way of doing it, and doing it consistently. Most coding standards I've seen suggest one space before and after each binary operator or comparator (+, -, =, ==, >, <, etc) so that's what I'd do.
Campbell Ritchie wrote:You are also inconsistent with your comments. You are sometimes using /*...*/ and sometimes // for block comments.
@Ivan: One thing I would suggest is that you learn about Javadoc comments ('/** ... */') as soon as possible, and start using them wherever you can - ie, classes, methods and fields.
Personally, I use them everywhere, even on private members, because I know that it means I have ready-made documentation if/when I need it.
On the rare occasions that I also need to comment a particular piece of code (maybe because it's complex, or not obvious), I generally use the '//' style; but that's just for me so that I have a clear visual difference; it's certainly not mandatory.
In my view, Javadoc is one of the things that sets Java apart from every other language I've ever learned. It's also the basis of all that wonderful API documentation.
Isn't it funny how there's always time and money enough to do it WRONG?
Good reference, Ivan. I am a long-time adherent to what that article names "Allman style," which is pretty much this:
That's probably because I did a lot of Pascal programming before moving on to C. Over the next 30 years, I took lots of flak for it because most of my colleagues used what the article names "K&R style," which is pretty much this:
However, I also noticed that I was monkishly devoted to the use of my style choice, whereas most of my colleagues were less strict with themselves about their own choices. Not to beat this to death, but the article quotes K&R themselves, with what I believe is the best advice on this topic there is:
The position of braces is less important, although people hold passionate beliefs. We have chosen one of several popular styles. Pick a style that suits you, then use it consistently.
Nearly all else either matches between the styles, or is something people don't care enough about to get red-faced in fist-clenching rage over it (no kidding: where that opening brace goes can put your life in danger, if you show the "wrong" style to the wrong person). But, fwiw, I also noticed that, because I never depart from my choice, my colleagues eventually just got used to it and stopped bitching at me about it.
Of course, life gets more complicated when one is working for one of those soul-crushing sweatshops that requires everyone to adhere to the "company style manual." I'd avoid working in one of those, partly because company-wide enforcement of a style choice has, in my experience, been more to actualize some senior manager's personal wishes about where the opening brace goes than to improve productivity. As a working compromise, I simply adopt the style of whomever's code I am working with, and I ask others to maintain my style when they work on code I wrote. The exception is when I find I am working on code that does not consistently apply a single style, in which case I plant my flag, declare dominion, and reformat it all to my personal taste.
Life is, of course, too short to have spent as much time on this as I just already have, so, in general, it's best to be flexible about this, use the form that causes the least grief to all involved, and devote your energies to other things.