String input = anyObject.getInput();
input = input.trim();
The book indicated that more experienced programmers tend to do this in one statement
String input = anyObject.getInput().trim();
I took it a step further and appended toLowerCase() too.
String input = anyObject.getInput().trim().toLowerCase();
I was wondering if this is good form? More or less efficient? Is it possible down the road the compiler won't parse this successfully?
Lastly, is there a term for this kind of usage where multiple methods are appended/concatenated to an object?
there may be some minor efficiency/memory gains for not creating temporary references to the intermediate objects, but those will be offset by the time lost beating your head against the wall trying to figure out where your code is failing and why.
That's just my 2cents.
Also, please check your private messages for an important administrative matter. Thanks
Generally, as a coding style, I look askance at any of my developer that does this, although I let it slide if there are no other issues. From a performance persepctive, both ways are equal. Internally, Hotspot will "optimize" example 1 and example 2 to work like example 3. The only reason I prefer example 1, is because it improves readability and makes it easier to debug. Well sometimes example 2 improves readability.. It's kind of a when you see it you know it thing.
For example. I would find this easier to debug and read
to be more readable than
However, OTH, I would prefer this
ANd I would absolutely hate this
I would prefer
just get the banana and be done with it, already!
Jayesh A Lalwani wrote:Yeah it's called "showing off" :p
Hardly. It's considered quite normal where I work. We generally consider method chaining to be more readable than the non-chained alternatives. Bear in mind that "readable" often boils down to "it looks like I expect it to look like", and is thus highly subjective, based on what each person or group is used to. But from my perspective, it improves readability by removing visual noise - I already know what object we were working on, and I don't need its name restated over and over (and over and over...).
fred rosenberger wrote: the problem comes when one method fails or returns a null. you then try and call a method on what is basically a null object, getting a NPE. This masks the real problem, and makes fixing things harder.
Yes, this is the one big problem with the style. You know that one of those methods is returning null, but can't tell which one. It's easy to find out if you can reproduce the problem in a debugger, but it's more of a pain if you're looking at an error log in production. It's a pity that Java doesn't support putting a horizontal position as well as a line number into a stack trace - then this sort of problem would be trivial to resolve.
sandy chops wrote:Method chaining is best suited if the methods return type is void.
Method chaining is impossible if the return type is void. In Java under its current rules at least. I think there was a Project Coin proposal to allow any void method to return itself, instead, implicitly. But this proposal was not adopted.
sandy chops wrote:Otherwise its difficult to debug and understand.
Really, it seems trivially easy to understand. The problems with debugging are there, but have little to do with the return type as far as I can tell.
Incidentally, method chaining is a key component of an API style which Martin Fowler calls a Fluent interface, which has been increasingly popular in the last few years.
Jayesh A Lalwani wrote:Yeah it's called "showing off"
Hogwash. It's a useful and perfectly valid style.
I look askance at any of my developer that does this
Look askance at me then. I use this copiously when appropriate. (See fred's post.)
although I let it slide if there are no other issues.
How generous of you.
I myself don't think it's bad or good BY ITSELF. Whether it is more readable likely depends on how the methods' functions are related, how many different return types are involved, whether all the steps make sense together, whether the usage is extreme (20 uses at once? 50?) and, yes, personal preference. It seems obvious the book you were reading has a bias ("more experienced programmers...", no doubt printed in a deep, wise font as though spoken by Morgan Freeman). But I think considering pluses and minuses, even left open-ended, is more use to practically all readers than just stating things as fact for which there doesn't seem to be much basis.