3 ms·

I'm a bit torn on this because I always avoided having too many method calls on the same line. Code Complete recommended this a long time ago. However now I se

by rb808 8y ago

I'm a bit torn on this because I always avoided having too many method calls on the same line. Code Complete recommended this a long time ago. However now I see just about everyone stacking this method calls one after the other. Is this just acceptable now? state = stateFromPostcode(customer.getAddress().getPostCode());

EpicEng 8y ago
Depends really. Can getAddress() return null or is it guaranteed to be there per your system design? If it's not then that code is wrong, but if you know your invariants and enforce them higher up the chain then perhaps not. I realize that all sounds very obvious, but like most things... it really does depend. It can certainly make debugging harder if you need to step through. Personally I try to write code which simply doesn't allow nulls below the first layer they may be encountered. Not always possible though (e.g. nullable fields in entities and whatnot.)
- nradov 8y ago
  This is where annotation based null analysis can really help. https://dzone.com/articles/eclipse-annotation-based-null-analysis https://dzone.com/articles/eclipse-annotation-based-null-ana...
toyg 8y ago
> Is this just acceptable now? No, but where before it was a hard requirement in Java to deal with NPEs, newer libs are less likely to return nulls, so it's usually a bit safer than it was. You also avoid leaving references around that could potentially leak. There is also a bit of fashion with streams and JS-inspired call-chaining.
jandrese 8y ago
Isn't this what you get when you drink heavily of the Lambda Kool-Aid?
- hnthroaway1926 8y ago
  Yes, that and also when you aren't working with code that is older than three months.
lmm 8y ago
> However now I see just about everyone stacking this method calls one after the other. Is this just acceptable now? Not only acceptable but a great idea. Vertical space is a much more limited resource than anything else.
cytzol 8y ago
> Is this just acceptable now? That’s a matter of opinion, and my opinion is hell yes that’s not only acceptable but recommended! If creating a variable makes the code more readable, then do it; if it doesn’t, then don’t. But certainly don’t worry about NPEs. A similar piece of advice is that you shouldn’t do this: if (a.equals("hello")) You should instead, the advice goes, do this: if ("hello".equals(a)) because this doesn’t throw an NPE if `a` happens to be null. The only problem is that you want to be aware that your value is null; you don’t want to hide the error, then wonder why your program blows up further down the call stack. You haven’t solved the problem. You haven’t fixed a bug. All you’ve done is make that particular error message go away. It turns out that the real advice is not “structure your code to avoid NullPointerExceptions”, but “avoid null”. With this in mind, rules like this one, as well as guidelines telling you not to have too many function calls on the same line, are rendered useless.
opportune 8y ago
In Scala, no (that's what val is for) but I think Java it's ok. For builder patterns with long method names I'll just put some of the methods on their own lines

by rb808 8y ago

EpicEng 8y ago

Depends really. Can getAddress() return null or is it guaranteed to be there per your system design? If it's not then that code is wrong, but if you know your invariants and enforce them higher up the chain then perhaps not. I realize that all sounds very obvious, but like most things... it really does depend. It can certainly make debugging harder if you need to step through. Personally I try to write code which simply doesn't allow nulls below the first layer they may be encountered. Not always possible though (e.g. nullable fields in entities and whatnot.)

nradov 8y ago
This is where annotation based null analysis can really help. https://dzone.com/articles/eclipse-annotation-based-null-analysis https://dzone.com/articles/eclipse-annotation-based-null-ana...

toyg 8y ago

> Is this just acceptable now? No, but where before it was a hard requirement in Java to deal with NPEs, newer libs are less likely to return nulls, so it's usually a bit safer than it was. You also avoid leaving references around that could potentially leak. There is also a bit of fashion with streams and JS-inspired call-chaining.

jandrese 8y ago

Isn't this what you get when you drink heavily of the Lambda Kool-Aid?

hnthroaway1926 8y ago
Yes, that and also when you aren't working with code that is older than three months.

lmm 8y ago

> However now I see just about everyone stacking this method calls one after the other. Is this just acceptable now? Not only acceptable but a great idea. Vertical space is a much more limited resource than anything else.

cytzol 8y ago

> Is this just acceptable now? That’s a matter of opinion, and my opinion is hell yes that’s not only acceptable but recommended! If creating a variable makes the code more readable, then do it; if it doesn’t, then don’t. But certainly don’t worry about NPEs. A similar piece of advice is that you shouldn’t do this: if (a.equals("hello")) You should instead, the advice goes, do this: if ("hello".equals(a)) because this doesn’t throw an NPE if `a` happens to be null. The only problem is that you want to be aware that your value is null; you don’t want to hide the error, then wonder why your program blows up further down the call stack. You haven’t solved the problem. You haven’t fixed a bug. All you’ve done is make that particular error message go away. It turns out that the real advice is not “structure your code to avoid NullPointerExceptions”, but “avoid null”. With this in mind, rules like this one, as well as guidelines telling you not to have too many function calls on the same line, are rendered useless.

opportune 8y ago

In Scala, no (that's what val is for) but I think Java it's ok. For builder patterns with long method names I'll just put some of the methods on their own lines