4 ms·
About your last point: You can get around it by typing return (a);
by windsurfer 18y ago
About your last point:
You can get around it by typing
return (a);
- jaxn 18y agoor... if (a) { return true; } return false;
- RWilson 18y agoagreed, if (a) then just return a; if (a) { return true; } is just as redundant as an if (a == true) statement.
- RWilson 18y agoHmm... 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;
- mdasen 18y agoI 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.
- dcminter 18y agoCan 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!
- zain 18y agoIt 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.
- ralph 18y agoReadability 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.
- ars 18y agoYou (and some posters below you) missed the point. It's just an example. Think of the more general case.