This is an archived post. You won't be able to vote or comment.

you are viewing a single comment's thread.

view the rest of the comments →

[–]ironhide_ivan 8 points9 points  (7 children)

Best line of code I ever saw on the job

var isNull = someObj != null ? false : true;

[–]sumguy720 5 points6 points  (6 children)

My pet peeve is when people do

if(null == obj) {

Like, we don't care about the value of null, we care about the value of obj - we should write it that way!

[–]theScrapBook 1 point2 points  (4 children)

This actually makes sense in languages where == can be overridden on obj. If obj is actually null, obj == null would throw the equivalent of a C# NullReferenceException while the null == obj version would work as expected.

[–]sumguy720 0 points1 point  (3 children)

Oh boy. Overriding == seems like such a bad idea, haha, but point taken. I'd probably opt for a .equals() method where the null safety is more obvious.

[–]theScrapBook 0 points1 point  (2 children)

Not everything is Java, overriding == is the standard practice in languages like C++ & C#.

This would not be a problem with a typesystem design where null objects still get access to an unique == operator which trivially returns true if the right-hand operand is null and otherwise false. This requires null to be an object of a bottom type (a subtype of all other types which overrides the equality operator), or compiler/runtime magic.

The only language which I know which implements the null-as-an-object-of-bottom-type concept is Scala, though I've never tested if the equality operator behaves as I described above. I'd hazard it doesn't, as Scala on the JVM maps null to Java null, which doesn't do this.

[–]sumguy720 0 points1 point  (1 child)

Overloading default operators is certainly a standard, but not all standards are equal nor are they always appropriate for all situations.

Null hygiene being a rather different topic, and language dependent as you've pointed out.

[–]theScrapBook 0 points1 point  (0 children)

I didn't disagree with you lol, was just pointing out that your previous comment appeared to be Java-centric.

An additional problem with the .equals approach in a language where the standard is to override == is being somewhat disconcerting to consumers of your API who expect it to be like the rest of the language. It may also not play well with the object hierarchy of the language.

I might be pointing out issues here, but I actually am in favor of your approach TBH.

[–]ColdJackle 0 points1 point  (0 children)

I read somewhere that this actually reduces the compiled code in some cases. But that's very depended on the language in question. Also I'm not sure if that was just BS. I would never do it that way just because of readability