Hacker News Reader

Comment by vishnugupta | Hacker News Reader

>In Java there's a culture of favoring verbosity over cleverness.

I've been programming in Java (gulp) all my professional life of about a decade. I can totally attest to this.

Just couple of days ago in one of the code reviews I gave a lengthy explanation for using StringUtils.equals("foo", someVariable) over "foo".equals(someVariable). I could have instead just said what you've stated; prefer verbosity over cleverness :)

View on HN

I am java programmer and liked java culture. And I see nothing wrong with "foo".equals(someVariable).

If code review ends with lengthy explanation over why not use "foo".equals(someVariable) or some other maintenance/readability/effectivity/other important consideration non-affecting issue, I see something wrong with code review.

In this case code review is actually the reviewer trying to boost ego and stamp authority on reviewee

I agree... StringUtils is awesome, but "foo".equals(someVariable) is not a case where it's use is important.

Oh Java is the Kingdom of Nouns. :-D

http://steve-yegge.blogspot.hk/2006/03/execution-in-kingdom-...

And there's the culture I was talking about! I'm not a fan of stuff that's too weird and magical, but "foo".equals(bar) is shorter and just as clear to me, if not more so.

"foo".equals(bar) is definitely clear and shorter. However it is "clever" in the sense that it circumvents NPE with some sort of trick. Those who are new to Java don't get why and how it avoids NPE. To make matters worse they may even reverse the arguments for better readability, bar.equals("foo") which is a ticking NPE time bomb!

StringUtils.equals(a, b) on the other hand clearly states in its interface document that it is null safe and there's no NPE trap.

There, I said it :). That was my lengthy argument for using StringUtils.equals!

Of course, StringUtils is not in the core API; the first idiom "foo".equals(bar) works in Java everywhere, StringUtils.equals("foo", bar) will only work in projects that pull in org.apache.commons. Personally I prefer using facilities in the core API over third party APIs, even if the third party API is included anyway for some essential function.

I've been coding in Java for over 10 years. If I ran across pretty much any project that wasn't including Apache commons I'd be startled. I get your point, but some libraries are in such common use that for all practical purposes I consider them part of the language API.

But the problem with your use of StringUtils, IMHO, is that it hides intent. If bar is expected to potentially be null, test for null. If bar should not be null, throw an NPE, and the fix the calling code.

Making code that shouldn't need to be "null safe" masks errors, and ultimately makes them harder to track down.

Understanding that there is the possibility of an NPE and reading enough of StringUtils contract to understand that it deals with requires approximately the same level of "cleverness" as understanding the "foo".equals(bar) behavior.

Code reviews should focus on more important things than this, IMO.

As you may have guessed from my previous comment, I hate it when people write "foo".equals(bar). This kind of a clever trick is an accident waiting to happen unless you're really, really ok with null being a valid value for bar (and more often than not, you're not ok with that). If null is not a valid value for bar, then it's better to catch it and deal with it as early as possible.

Wow, sounds like a productive code review.

By the way, nobody should ever use "foo".equals(someVariable) anyway. If anything, it should be someVariable.equals("foo"), unless you really know what you're doing and are ok with null being a valid value of someVariable.

Either style would be fine as long as you check your preconditions.

Reply on news.ycombinator.com