Vote!

a - o.getName().equals("Admin")
b - "Admin".equals(o.getName())

b seems very much counterintuitive, why would you even consider it?

a.

@kamen because it can't throw NPE

a

@11000100111000 That's why you'd check if o exists beforehand I guess

@kamen Yeah, and with b you don't have to remember to check it, so you can't forget it.

@s0LA if thay was an option i would prefear the unknown variable before the static value in my comparioson

@s0LA Depending on the language == and equals() may not be the same operations.

E.g. Java, where == compares the reference/pointer of the operands, where equals() compares the content.

So "Admin" == o.getName() will always be false then.

A

B.

@kamen i mean when o.getName returns null

@kamen Yeah, and then you end up with:

if (o != null) {
if (o.getName() != null && o.getName().equals("Admin")
&& o.getPin() != null && o.getPin().equals(ADMIN_PIN)
&& o.getRole() != null && o.getRole().equals("ADMIN")
&& ....) {
o.setAdmin(true);
}
}

VERY easy to read and maintain, right?

Now try:

if (o != null) {
if ("Admin".equals(o.getName())
&& ADMIN_PIN.equals(o.getPin())
&& "ADMIN".equals(o.getRole())
&& ....) {
o.setAdmin(true);
}
}

A.

Easier to read

Always A. I hate when I see comparison ordered as in B.

Little real life example:
a) if shirt is blue
b) if blue is shirt
B doesn't make sense at all.

@irene this is just an example

Enum and strict equality, done.

In modern and well designed languages, you don't need this kind of confusing tricks to make your code NPE safe.

@Lensflare agreed, but obviously this is java so there's nothing modern about it :P

@irene the same reason why databases have null entries :) couldn't stand them at first, but now I see lack of nulls would be a huge problem

@irene inventor of null? 😁😁
ref plz 😁 I want to know who invented....Nothing 😁

In c#
If (o?.Name == “Admin”)
{
}

@irene thank you :)
but I disagree. The point of null is to say 'there is NO VALUE set yet'. An empty string is still a value, which more often than not is invalid. So you'll eventually end up empty-string-checking those values.
In APIs
in databases
in your logic
everywhere

which is so wrong.. Because to check whether you user has not set a value you'd be checking whether the value is not some other value. I.E. You're assuming the user DID set the wrong value :) when he did no such thing.

Getting rid of nulls would make everyone and everything a liar and a lie.

Languages, including java [some of you are incapable to understand], have ability to hide nullchecks in optionals, maybes, etc.

@irene nope :) that's exactly what it is NOT

@irene okay, if it's a value, then.. What properties does it have? What's its length? Size? TYPE?? What would be its mathematical expression?

It cannot be zeroes, because we do have 0 that's a Real. And Real is not null.

In oop null means the object pointer is empty, it points to nothing. The pointer evaluates to nothing.

@irene can you elaborate? How is zero value [null] different from zero [0] then? :)

@irene oh, in machine code.. Missed that, sorry :)
yes, in machine code it somewhere IS a zero indeed

but we are not writing machine code, are we? We do not have nulls in asm. We have zeroes.

Nulls come in higher level languages, the level where we operate in logical structures, logical objects. Hence the logical null, meaning absence of value 'at the end of the road'

@irene well everytging in programming is a headache when you either ignore things or have no idea how to use them.

Humour me.

A simple use case. A boolean in a database column SHOULD_IMPRISON.

A new record is to be created after the court ruling. A secretary forgot to fill that value in and a bug in FE allowed to submit the form.

What value would you see appropriate to store in db in that case, considering you have no nulls [bcz, you know, they should not exist]? A default TRUE might imprison an innocent person. A default FALSE might release a serial killer.

Also the BE must have received either true or false in that case [bcz no nulls, remember?]. Which would that be?

How would you know the secretary forgot that single field?

How would you sort this out?

@irene
true. You also do not write such [or any as a matter of fact] software believing frontend will handle all cases properly and no bits will be lost at medium.

bugs happen. Interferences happen. So how would you handle that particular case without nulls? :)

@irene why so? I was under impression that anything that does not have a value ends up with default value transparently? :) I mean in a world without nulls. Because your last comment defines exactly what happens when you try to use null as a primitive boolean -- an error -- a nullpointerexception :)

@irene what if the word is not there at all?
If we're talking json, what value would FE pass to BE if the field in a form is left out empty?

I'm not creating a problem and you understand that very well :)

In Java, the problem is not null. The problem is you can not have non-null reference types.

@irene fe - frontend. Be - backend. Json - javascript object notation Sorry, I thought that was obvious. My bad :)

@ddephor why would 1==1 give an error...