@C0D4 maybe we could give you two, or three junior positions at once? That should fill your day pretty good.

@C0D4 You're hired!

@C0D4 why can't the interviewee be a NULL hat? ;-) Thanks!

I don't work at open office space like this anymore. If the company is too cheap to provide programmers with rooms where maybe one to four people work, they are too cheap for me to consider them.

@Mbithy the purpose of NULL is to tell you that you read physical memory that has nothing saved in it. That can only be an issue in low level programming where you have such access.

@Codex404 it means as much as an empty page in a book.

@AlgoRythm NULL does not mean that nothing was found, but that something has no value and no type, these are two different statements. You are confused about it like many others. This might be OK in some old languages, but in an OOP environment you should return objects, not holes in the universe.

There is a reason the guy who invented NULL said it is a Billion Dollar Mistake:

https://infoq.com/presentations/...

Here is a good overview of all the issues:

https://yegor256.com/2014/05/...

You do you, but it's bad and one of the reasons so much software and source code is crappy.

@k0pernikus if you have a test that is using a known working query and it returns an empty list, you know you broke it, that's not an edge case.

I'm not at liberty to crash the APP our clients pay for. If there is an issue it needs to be handles in a way that allows the client to use any other feature. Thats what good software does. It is allowed to crash in the testing environment.

I understand your pain, but a bad, broken API is not an argument

@k0pernikus and NULL does not keep you wondering if your query was wrong, or even your code which messed up something and returned NULL instead of the proper list?

It also does not hide any bugs at all, as long as you have unit tests which would immediately find these kinds of issues. Thats way better than breaking production don't you think?

Exceptions in these cases are wrong, an empty list on a query is expected behaviour, not an exception.

Option/Maybe types on the other hand are a solution.

@AlgoRythm it works around the regular flow of the program, making it harder to understand.

Why is debugging harder? NULL makes it harder, because you don't know if you got NULL because it should be returned, or because there was an problem in the type system for example. The NOP Object will tell you that the code ran like expected.

You also do not need to construct new NOP objects, you need to create one and then you can point to it. In the worst case you use the Object Pool Pattern to make everything reusable. At the other hand the performance hit is negligible in most cases.

It does not go against any rooted standards and even if, "We always did it that way." is no argument.

@AlgoRythm with for example the Null Object Pattern you do not need any checks, which mean less code, better to read code and less bugs. This is what you want, checks are workarounds.

@AlgoRythm you could just return an empty list, or an empty resource, look into the "null object" pattern. NULL does not mean "no result".

@alexbrooklyn exceptions are way better, they convey meaning. NULL has no meaning, you cannot recover because how would you decide what to do? With an exception you can recover the state, or at least fail gracefully.

You might think NULL means False, or something failed - but in my specific example a validator returned NULL when the value was valid.

This is insanity.

idk I love my MacBooks

@alexbrooklyn then I would fire you maybe? ;-)

This function name means that I can supplied an id or NULL as a parameter, not that it does find something or returns null.

Fix and improve yourself first, start with cleaning your room; kiddo.

@rantsauce I tried that too, it just won't stop. Everyone is looking desperately for developers here.

Comments can be hard to understand too and in the worst case they are outdated, because someone change the code but not the comment.

Works on my machine!

@C0D4 who knows? If the returning method could know if the value is True or False if would not return NULL in the first place. There is no logical way to process NULL - except throwing an exception.

Casting it into False is as invalid as casting it into true.

Git works like snail mail. You ```git add```stuff to your envelop until you ```git commit``` to sealing the envelop. After that you ```git push`` it to the ```remote``` post office. If the contents of your envelop are illegal you get a ```merge conflict```with authorities.

You could say that about anything that involves work.

@irene well it can be

But she is old school, your joke ist just old.

@lestradee VIM is free

Learn Haskell

@kshep92 you are picking cherries, there are several hundred thousand company in the world producing code for relatively mundane companies who need custom software or who develop their own products in-house.

You argument is also very faulty .If companies only move forward like you say, their software will grow unmaintainable and unextendable. This will raise the cost of producing new features by a lot and make it slow. You can pay a growth spurt with technical debt, but you need to control it for sustainable growth. Otherwise you will end up with stagnation and failing products.

@kshep92 Simple, first you create a hot Fix, after that you immediately (next morning) create a regular fix for the issue - it is that easy.

@Fast-Nop I see a pattern, all these company's provide B2C Software and still represent a tiny part of the overall software marked

@Fast-Nop it does matter, most software products are not in such a situation.

@kshep92 that’s plain unprofessional