Hacker News Reader

Comment by windsurfer | Hacker News Reader

About your last point: You can get around it by typing return (a);

I should have used a better example, but there are a good number of cases where the Java compiler complains about missing return statements that just don't need to be there. It's a wart in the language.

Can you cite a specific example where the condition is NOT ambiguous and the Java compiler WILL produce an error? The example you cite is incorrect (see my post later) - you can compile code of this form just fine.

I'm not aware of unambiguous situations where the compiler will complain; if you see an error it's usually pebkac!

It isn't always that straightforward. For example:

  if (a)
    return (some && complicated || boolean && calculation);
  else
    return (some || other && boolean || calculation);

edit: I suppose you can get rid of the "else", but you shouldn't have to sacrifice readability for a compiler shortcoming. I'm with mdasen; the compiler should figure it out.

Readability is improved by not having the else clause. It makes it clear that the return in the then-block is there and the code won't continue after the end-if.

You (and some posters below you) missed the point. It's just an example. Think of the more general case.

or...

if (a) { return true; } return false;

agreed, if (a) then just return a;

if (a) { return true; } is just as redundant as an if (a == true) statement.

Hmm... not sure what justified the -1 on this. Perhaps that in some languages if (a) can be used as a shortcut for if (a != null), where a is an object and not a boolean. So, as a correction to my previous comment. If (typeof a == "Boolean" || a instanceof boolean), I still stand by reducing redundancy, but if a is an object, then fine, if (a) return true;

Reply on news.ycombinator.com