I made a new thread for this since I think every new developer should understand this.
I would like to know why is splitting some lines of codes neater and more readable since honestly in some cases I find this
Way neater, easily readable and more organized than this:
I believe it was Cambell who told me that the smallest method should be at least 3 lines long, and even though I agree that sometimes I do go too far by having in some cases a method that should be 4 - 5 lines in 1, but in some cases I prefer grouping them up as shown in the former code.
It’s not as much about how neat it looks but how readable it is to another programmer.
It’s advised to keep the method signature on one line and the body of the method indented.
As I am sure you have seen, Indentation and carriage returns help a lot to identify right away a specific block of code.
I understand it might not seem crucial on your example of just a return statement but when I see a tight portion of code like your first example, I think more of variables declaration rather than methods definitions.
One of the lines that I did object to in your code was:
I would add some spaces and braces to get this:
And people get into religious wars over things like the placement of braces. This my preferred layout. I find it much easier to visually detect missing or misaligned braces. The down side being that less code is visible on a page at a time, but that is less of a factor in today's world of viewing (mostly) everything on large monitors.
Yosuf Ibrahim wrote:I would like to know why is splitting some lines of codes neater and more readable
That is because of convention, which is being used probably by 99% of Java developers. If all of your team members prefer that style - probably that is fine as long as team doesn't change. But if all of your team members leave the company and then regular Java developer being hired, this is where problems start - there is a bigger chance that such developer got used to a conventional style.
Another thing. Now you have methods:
Let's assume you found out you need another method, getDescriptionByProductCode(), so you have:
Nice, so let's combine them:
Let me guess what you do next, go back to all methods previously defined and sort out spacing:
Then one of senior developers said, you know, productCode parameter name isn't really clear enough, nor searcheable, can you please change to eanCode, you say, ok, good idea:
What's next, yet again? Thanks, but no! So you don't do that kind of stuff as it complicates things. Such convention was created for a reason, and is used in many languages, even modern (more recent than Java), I trust it was developed through many years of research.
Now imagine you got an exception, and once you need to identify where it happened, you go and look for stack trace and its specified line number, now since there are couple of places where one or another exception can happen, all of them would be specified as a same line - that complicates things from the debugging point of view. What you want to achieve by looking to stack trace, is that whenever you see a line number, you'd be pretty confident that once you there, you'd see the cause right away.
However, your second example isn't good enough too, because each successive method supposed to be separated by an empty line.
Slightly out off topic, I think you can improve the name of method getImage(), because it actually returns ImageIcon, while method suggests different, field name you have image too, what it is after all? icon or image or imageIcon? Such confusion shouldn't arise for a code reader.
What you then posted is incorrectly indented; you need empty lines between successive methods. No wonder that isn't clear.
Yosuf Ibrahim wrote:. . . Way neater, easily readable and more organized than this. . .
See, three lines, and yes, I did say that. That method is now clearly indented, so everybody can see where it starts and finishes, how many statements it contains, etc. If you use Allman indentation, that becomes four lines.If you find Allman indentation easier to read, then make a policy of using it. If you are using an IDE, Junilu is right to say feed the options to your IDE and let it do all the indenting, and also that all members of a team must conform to local conventions.
the smallest method should be at least 3 lines long . . .
Campbell Ritchie wrote:If you use Allman indentation, that becomes four lines.
From what I've experienced many Java programmers do not use Allman indentation and many C# programmers do. I was not aware of the name Allman before this post.
With this code:
you may be fine at the start. However you may run into issues when you need to modify the code. It could then end up being something like
Now getClassName() on line 2, which has a simple if really stands out and the code does not look that tidy.
Yes a ternary operator could be used for this example to make it shorter however ternary operator are not that easy to read some times.
So now that the method getClassName() is longer does it get different indention? If so what is the rule as to what is on one line and what isn't?
Doing spacing like posted in the first example when one function is on one line can also be misleading to the next developer.
Some programming languages like COBOL, RPG IV. to name a couple, require you to have functions defined in certain columns.
So if a novice/new Java programmer picks up your code they may fell that the columns mean certain things can they may choose to continue on that way.
In doing so they may have a function/method which is all defined on one long single line.
I do agree with Campbell regarding spacing and that does appear to be the convention.
COBOL Syntax explained:
RPG VI Sample program: