6

This foo that is returned by lookup could be null.

That's why I'm trying to avoid calling foo.getFooStr() on a null value by first returning null if foo is null.

But is there a better (more concise) way to write this?

public static String getFooStr(String input)
{
    Foo foo = lookup(input);
    if(foo==null)
    {
        return null;
    }
    return foo.getFooStr();
}
Brandon Pike
  • 61
  • 2
  • This question is similar enough (but not identical) to hopefully give you some insight: http://stackoverflow.com/questions/271526/how-to-avoid-null-statements-in-java – Mansoor Siddiqui Sep 11 '11 at 22:51
  • 4
    There is nothing wrong with what you've written. Writing it so that it looks shorter doesn't necessarily make it better. – hookenz Sep 11 '11 at 22:54
  • 2
    Plus, you can have breakpoints in different lines for the case of the string being null or nonnull. That helps with debugging. – Roland Illig Sep 12 '11 at 06:26

7 Answers7

34

You've two questions: is there a better way to write the code, and is there a more concise way to write the code.

Regarding more concise, this could work:

public static String getFooStr(String input) {
    Foo foo = lookup(input);          
    return foo == null ? null : foo.getFooStr();
}

Regarding better: I value readability over conciseness any day, and by a wide margin. Your original code looks fine to me. What matters is what looks good to you, and which is easier for you to understand and debug 3 months from now. I've heard someone say it best -- write your code so that is easily understandable by others, and even more importantly, by your future self.

Mateen Ulhaq
  • 24,552
  • 19
  • 101
  • 135
Hovercraft Full Of Eels
  • 283,665
  • 25
  • 256
  • 373
  • 6
    +1 IMHO less code is good as long as it's still clear, and this is. btw, I removed the bracket noise (ie `foo == null` instead of `(foo == null)`) for better readability - hope you don't mind. – Bohemian Sep 11 '11 at 22:54
  • 5
    @Bohem: HFOE said it well, what matters is what ... is easier for you to understand and debug ... and so that it is easily understandable by others. The "bracket noise" you removed may be only noise for those of us who know the grammar of C-like operators as almost a mother tongue; for less experienced people (which is far more people, but may not be your audience), the parentheses make it more readable, because they don't have to know whether `?:` has higher precedence than `==`. I'm not saying you're wrong to remove the parens, but they're not noise, and I would more likely leave them in. – LarsH Mar 14 '12 at 11:11
  • 1
    +1. I often advise my minions (students) that come to me with suggestions about shaving off a few milliseconds, that they should first optimise for _readability._ Whatever time they save may well be wiped out by the next coder wasting an hour trying to understand their optimisation six months later :-) – paxdiablo Jan 30 '13 at 04:51
  • @paxdiablo like backups they need to have tried it personally to understand why :) better they do it while it is not important yet. – Thorbjørn Ravn Andersen Sep 04 '13 at 03:28
6

Why isn't there a lookup that returns the appropriate foo string?

Daniel A. White
  • 187,200
  • 47
  • 362
  • 445
3

I'm not into java, but I do like clean code... Source code should be easy to read and understand for humans - the machine doesn't care how it looks but your colleagues do. More concise code usually takes a moment or two longer to grasp (sometimes much longeer depending on the quantity and complexity). Keep code understandable and it will be maintainable (even if it is a bit more verbose)!

Jon Gilbert
  • 866
  • 8
  • 5
3

Groovy does it nicer.

return lookup(input)?.fooStr

or even just:

lookup(input)?.fooStr

Paul Grime
  • 14,970
  • 4
  • 36
  • 58
2

For Java 7, at some point it was planned that you could just write this:

public static String getFooStr(String input)
{
    Foo foo = lookup(input);
    return foo?.getFooStr();
}

But until this feature is widely known, you will have to stick to the ?: operator.

Roland Illig
  • 40,703
  • 10
  • 88
  • 121
  • Is this currently availble in Java7 any doco please link if possible.I would be interested in reading up on this. – Java Ka Baby Sep 11 '11 at 23:52
  • That feature didn't get into Java7 though and I doubt it'll be added any time soon. Though C# obviously has it ;-) – Voo Sep 11 '11 at 23:58
  • 4
    The Elvis operator was dropped from Java 7 in 2009. The Project COIN site says this: *"While the Elvis operator and related operators are helpful in Groovy, differences between Groovy and Java, such as the presence of primitive types and interactions with boxing/unboxing render the operators less useful in Java. JDK 7 will support other ways to ease the pain of null-handling, such as the null checking enabled by JSR 308."* (JSR 308 is type annotations, and that got deffered to JDK 8) – Stephen C Sep 12 '11 at 05:00
  • 1
    Just to be technically correct the elvis operator is `?:`, not `?.`. The `?.` operator is the null safe dereferencing operator. Elvis is/was not one eyed. – Brett Ryan Oct 31 '13 at 04:07
1

I do not like multiple returns any where in any code. I will just change it to 

public static String getFooStr(String input)
{
    Foo foo = lookup(input);
    String fooString;
    if(foo!=null)
    {
        fooString = foo.getFooStr();
    }
    return fooString;
}

Also the version from @Hovercraft Full Of Eels is good in my opinion but less readable but still a common way of doing.

Java Ka Baby
  • 4,880
  • 11
  • 39
  • 51
0

In Java8:

Optional.ofNullable(lookup(input)).map(f->f.getFooStr()).orElse(null);
vince
  • 176
  • 1
  • 4