People can argue at length about spaces. I'd write
But either of the ones you wrote in code review would be fine too.
I don't see why you'd add a blank line after a method name though. Either of these seems fine to me. I probably would say something about the random blank line after a method name that you have because it isn't common.
I don't think there is a "definitive writing style" that makes every piece of code looks more readable for every single developer.
Like Jeane said, we could argue all day (and more) about this. Truth is, you have to follow the same standard everyone else in your group is following ,that way the code will look the same, and the cognitive load associated to reading it will diminish.
That said, there are many factors that affect code readability, not just spaces and tabs, so take the above statement with a grain of salt.
Noorul Hameed wrote:Dear Author,
Space character is one of key element in readability of programming statements.
Below code identified well standard in reading with spaces.
And not as:
Indentation is another important concept. Also, inserting blank lines between important part of code improves readability.
after method declaration, code should be like
Should it be good writing style in coding? How about program sizes which has been taken up?
I have added code tags to one of the quotes below.
Noorul Hameed wrote:. . .
And not as:
Agree there. But as FD says, different people will have slightly different styles; The old JavaRanch style suggestions would allow only one of the following:- if(x < 3) ... and if (x < 3) ... But few people even notice!
Most people don't separate unary operators from their operands by whitespace.
. . . blank lines . . . improves readability.
after method declaration, code should be like. . .
Disagree. Whitespace between successive methods or other sections of code does enhance legibility, but too many empty lines make the code much more difficult to read. The comment you wrote is inside the method declaration, after the method header. You can find the grammar in this part of the JLS (=Java® Language Specification). The header should be followed immediately by the method body logically. The logic doesn't permit anything to intervene between the header and the body, so I would never insert a blank line there.
I'm of the camp that likes to isolate operands with spaces to make it easier to see them as isolated tokens. I'm also fairly generous with blank lines, BUT primarily I use them to make a sequence of code stand out. That is, if I have a set of statements doing a particular thing, blank lines may precede and/or follow them. Likewise, if I have declarative statements, usually I'll put a blank line between them and the active code.
The secret of how to be miserable is to constantly expect things are going to happen the way that they are "supposed" to happen.
You can have faith, which carries the understanding that you may be disappointed. Then there's being a willfully-blind idiot, which virtually guarantees it.
The easiest style for me to read is the one I've been working with most recently. When I change positions, the new/different style is the worst I've ever seen and I can't imagine why anyone would do it that way...until I become used to it and find it the best ever.
To try and find some actual best, you'd have to control for what each person was used to seeing, which seems like it'd be quite difficult.
And ultimately, it doesn't matter what's best. You need to code in the style determined by your team.
There are only two hard things in computer science: cache invalidation, naming things, and off-by-one errors