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());
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());
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.
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.)
https://dzone.com/articles/eclipse-annotation-based-null-ana...
Not only acceptable but a great idea. Vertical space is a much more limited resource than anything else.
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.