|
The problems are not about nullable types. Thay are about ordinary references being null.
|
|
|
|
|
There is a bridge joining the two buildings in our location. Any "developer" whose code crashes in production because of a bad pointer gets hanged from the bridge pour encourager les autres.
So no, this is not a common problem.
Seriously, all the developers I work with (even the young 'uns) know what a null reference is, and know to avoid it
Freedom is the freedom to say that two plus two make four. If that is granted, all else follows.
-- 6079 Smith W.
modified 5-Mar-23 12:05pm.
|
|
|
|
|
Quote: Seriously, all the developers I work with (even the young 'uns) know what a null reference is, and know to avoid it
Same here. All the young serious developers I'm working with, know how to handle it.
|
|
|
|
|
0x01AA wrote: Same here.
Here too.
"If we don't change direction, we'll end up where we're going"
|
|
|
|
|
Richard MacCutchan wrote: Do those of you who still work in teams find this is a common problem with younger team members?
Yes, all the time. I almost think it is something you have to learn the hard way, because in my experience, most are not aware of this as they code.
Now, new IntelliSense with VS 2022 and ReSharper will point this out/alert you right away when it happens, but still, everyone should grok this concept.
|
|
|
|
|
A guy on the team I just joined was somewhat miffed about the whole nullable feature in C#. He had learned in university that object oriented languages had nullable references. And C# is an object oriented language... so obviously we could not force references to have values.
|
|
|
|
|
Richard, this is a problem of perception, you seem to think anyone who posts in Q&A is a "developer". Most are probably just learning (and you are their teaching resource) and a lot of them are code monkeys at best.
Never underestimate the power of human stupidity -
RAH
I'm old. I know stuff - JSOP
|
|
|
|
|
trønderen has also said it well.
Even the C language has confusion on this topic.
Yes, I too believe that they have distinct meanings.
Remember my posing the question of why is this a valid statement in C
zero = 0;
value = malloc( zero );
value is not null nor zero.
Why would I want to allocate zero memory?
Here is what ChatAI says
In the C programming language, calling malloc(0) is allowed and returns a pointer to a memory block of size 0. This is specified in the C standard, which states that malloc(0) is equivalent to malloc(1).
The reason for this behavior is that malloc is intended to allocate memory dynamically, and a request for 0 bytes of memory is considered a valid request. Allocating a block of memory with a size of 0 can be useful in certain situations, such as when you want to create a zero-length array or when you want to allocate memory that you will later reallocate to a different size using realloc.
However, it is important to note that malloc does not guarantee that it will return a pointer to a block of memory that is truly 0 bytes in size. The implementation of malloc may choose to return a block of memory that is larger than the requested size, in which case the additional memory will not be accessible to your program.
Clear as mud.
"A little time, a little trouble, your better day"
Badfinger
|
|
|
|
|
Forgive my ignorance, but what is the point or purpose of a zero length array?
Or at the lower level, reserving zero memory space?
|
|
|
|
|
To declare that it is known, but has a zero length value.
E.g. if my middle name is a zero length string, null, it is known that I have no middle name. If it is null, I may have a middle name not yet entered into the database.
|
|
|
|
|
exactly.
0 means zero in contrast to 1 .. NULL means void or does not exist.
However, this subtlety gets blurred by the programming and programmers making use of it.
In C, Null is meant to be void address. zero is number 0.
But if I do a boolean test on either one, I get false.
If you print them they are both zero.
Hence the blurriness.
They are equivalent at programming level yet we know they mean two different things.
Maybe C++ handles it differently.
Go figure
"A little time, a little trouble, your better day"
Badfinger
modified 6-Mar-23 23:05pm.
|
|
|
|
|
Excellent topic.
"A little time, a little trouble, your better day"
Badfinger
|
|
|
|
|
It seems to me not only null is the problem, but programming knowledge in general.
Throughout my career I've seen very bad code by very "experienced" people.
Not just the young kids, but the old farts too.
It's so bad I'm now convinced that about 90% of the people are just plain bad at their job 
|
|
|
|
|
Because there's null to understand.
"In testa che avete, Signor di Ceprano?"
-- Rigoletto
|
|
|
|
|
Nobody teaches to use a debugger, a real one at least. For my first months in the real World I debugged with printf - I did image analysis. Debugging imaging algorithms by printing 1024x1024 tables of numbers? I did that.
One of my dreams is to get a teaching position in CS. I will not let anybody out of the room until they learn to place breakpoints and use the watch window.
GCS/GE d--(d) s-/+ a C+++ U+++ P-- L+@ E-- W+++ N+ o+ K- w+++ O? M-- V? PS+ PE Y+ PGP t+ 5? X R+++ tv-- b+(+++) DI+++ D++ G e++ h--- r+++ y+++* Weapons extension: ma- k++ F+2 X
|
|
|
|
|
Depends on the definition of "young"  But, seriously, I see so many powers that be in a high tech company internalize their fears of mistakes by programmers who simply don't get the deeper meaning of a sort-of tri-state logic, so that when when you apply it correctly, you're going to get smacked by individuals who wallow in this fearmongering mindset. Thinking, "if I can't comprehend this to treat the information properly and make a mess, I'm going to force you into that same fear, so that I won't look incompetent and alone".
The real issue though, is the hiring policy. Like, who the ***k hired you, and worse, who made you the boss around here? Do you have more skeletons in the closet regarding your pretend-strong, feeble character?
Ok I digress. But if you lack the technical grid to understand what your responsibility is towards the state of a variable, you should really be looking for another job. No wonder IT systems have so many vulnerabilities.
|
|
|
|
|
This happens because young programmers learn (at first) languages like python, C#, or other high-level languages right away. Old farts like me have had to put up with C, if not even assembly language. At least on K&R, it is explained what a null pointer is, although my favorite chapter is the one where complicated declarations (which are not complicated at all) are described.
It's fine to learn high-level languages right away, but don't we want to take a look at how things work internally? Maybe with the help of the old, decrepit, and "very dangerous" C? I'm not saying to delve into Assembly ... C is sufficient.
I am always amazed when I see young computer science students get stunned when I tell them about the two's complement.
Old languages may be old and decrepit (though still widely used), but they would still be very useful for many people. To be picky, even high-level languages run on hardware whose principles are still those of John von Neumann's architecture, evolved or not. Many people would still have a lot to learn from "very very very ugly and dangerous" languages like C. And I don't find anything complicated or difficult to understand in malloc(0) either. It must be because I am an old fart.
Cheers
|
|
|
|
|
So true. I started with machine code and progressed to Assembler, and thence to high level languages. I still think C is the most elegant and easy to learn of all.
giulicard wrote: It must be because I am an old fart.
Ha, ha; you and me both.
|
|
|
|
|
Meh, because often it's a pain in the neck? Look at most languages and the various operators or functions built around 'null'. Then there's things like empty, not set, nothing, and default 'blank' types. Gets into a lot of fun, especially with databases and SQLs.
Speaking of fun, and a fun discussion, I had a young programmer use the three values of a boolean. I asked what he was doing. I said go get that switch on the wall to be 'not answered', lol. I'm a firm believer in two boolean values. If you're looking for 3 answers, use a different data type and clearly capture the intent. In my database designs, I leave no null values. Saves that pesky code, lol.
|
|
|
|
|
Because so many programmers do not understand pointers… or the fact that a pointer has to point to something/anything before you use it/dereference it.
If you understand pointers, then you know how Java/C#/etc deal with objects.
|
|
|
|
|
I don't understand the problem. People actually don't know what null is? Are you able to educate them on it once you get your jaw off the floor?
|
|
|
|
|
In my case, before retiring, it wasn't youth. It was aggressive ignorance by people who were "professional" developers for decades.
Hence my retirement.
|
|
|
|
|
i tried to explain that to C# students (back when i had a few) by saying that a "null reference" is a named/typed placeholder/slot for a pointer/reference to something which is not defined.
you, the programmer, have the "freedom" to create the named/typed slot.
and, that the common exception "null reference" was what happened after your running code made demanded/needed/required a defined pointer.
you have a favorite metaphor, or explanation ... i am all ears !
of course, now, Visual Studio/C# compiler (and ReSharper) are going to ... suggest a check.
and, now, C#/>NET has new Attributes for static Type analysis: [^].
«The mind is not a vessel to be filled but a fire to be kindled» Plutarch
|
|
|
|
|
See my leash metaphor further down
|
|
|
|
|
I have to deal with Microsoft employees not understanding null for dates or GUIDs, thereby actually making programming, especially if a database is involved, even more difficult.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
