You can always tell the guys who came from the world of C / C++
-
They're the ones who actually check for null before using an object. I've found that it's comparatively rare in the C# world to see this test as a standard coding practice. Who knows, maybe tripping over a null value is less evil in today's condom protected world of managed software development (and I'm talking about the programmers, not the code, being "managed") than it used to be. Try a stunt like that in the world of C and you might trash memory that you later regret. Loss of data, screw up the OS, spontaneously reboot the machine... shucks, there's just all sorts of havoc that a wild pointer can do in C. And don't even get me started on wild programmers. Maybe the memory management in .net makes it less hazardous to access a null object, but it sure as hell isn't any less embarrassing. I mean, it's bad enough if you do decent error handling / reporting and give the user a message that says, "Damn. That was embarrassing. Care to try again now that we're sober?" But to get a YSOD or system popup message saying something arcane about a null value being encountered is just amateur hour. Nowhere is this more prevalent than the world of client side javascript, something I've successfully avoided for years. Now that I'm digging into it a bit, it's just amazing to me the degree of half assed techniques, cryptic, one letter names, untested variables and other such grade school level sloppiness in what should be professionally written code. Write code like that in any other part of the system in a decent development shop and you may have a brief and unexpected encounter with the Exit sign. But as long as you're only writing javascript, I guess it's okay. I mean, it's not like a customer would see an embarrassing error message pop up out of their browser and make your company look stupid or anything. Actually, though it sounds like I'm cranky and having a bad day, at the moment I'm nose deep in a personal project and having quite the good time. But sometimes you just wanna whack someone upside the head with a whiteboard eraser, you know? :-D
Christopher Duncan Author of The Career Programmer Watch Bad Programmer! - Premieres May, 2011
I personally think it's a huge gotcha to think that .NET manages memory. It really doesn't, not very well.
Christian Graus Driven to the arms of OSX by Vista. Read my blog to find out how I've worked around bugs in Microsoft tools and frameworks.
-
They're the ones who actually check for null before using an object. I've found that it's comparatively rare in the C# world to see this test as a standard coding practice. Who knows, maybe tripping over a null value is less evil in today's condom protected world of managed software development (and I'm talking about the programmers, not the code, being "managed") than it used to be. Try a stunt like that in the world of C and you might trash memory that you later regret. Loss of data, screw up the OS, spontaneously reboot the machine... shucks, there's just all sorts of havoc that a wild pointer can do in C. And don't even get me started on wild programmers. Maybe the memory management in .net makes it less hazardous to access a null object, but it sure as hell isn't any less embarrassing. I mean, it's bad enough if you do decent error handling / reporting and give the user a message that says, "Damn. That was embarrassing. Care to try again now that we're sober?" But to get a YSOD or system popup message saying something arcane about a null value being encountered is just amateur hour. Nowhere is this more prevalent than the world of client side javascript, something I've successfully avoided for years. Now that I'm digging into it a bit, it's just amazing to me the degree of half assed techniques, cryptic, one letter names, untested variables and other such grade school level sloppiness in what should be professionally written code. Write code like that in any other part of the system in a decent development shop and you may have a brief and unexpected encounter with the Exit sign. But as long as you're only writing javascript, I guess it's okay. I mean, it's not like a customer would see an embarrassing error message pop up out of their browser and make your company look stupid or anything. Actually, though it sounds like I'm cranky and having a bad day, at the moment I'm nose deep in a personal project and having quite the good time. But sometimes you just wanna whack someone upside the head with a whiteboard eraser, you know? :-D
Christopher Duncan Author of The Career Programmer Watch Bad Programmer! - Premieres May, 2011
Anyone that has ever debugged a pointer problem in c/c++ uses and appreciates the check for null, I guess it just carries over...habit?
Semper Fi http://www.hq4thmarinescomm.com[^]
www.jaxcoder.com[^] WinHeist -
Anyone that has ever debugged a pointer problem in c/c++ uses and appreciates the check for null, I guess it just carries over...habit?
Semper Fi http://www.hq4thmarinescomm.com[^]
www.jaxcoder.com[^] WinHeistOr perhaps rampant paranoia? :-D
Christopher Duncan Author of The Career Programmer Watch Bad Programmer! - Premieres May, 2011
-
I personally think it's a huge gotcha to think that .NET manages memory. It really doesn't, not very well.
Christian Graus Driven to the arms of OSX by Vista. Read my blog to find out how I've worked around bugs in Microsoft tools and frameworks.
No, but they manage suckers programmers quite well, don't they?
Christopher Duncan Author of The Career Programmer Watch Bad Programmer! - Premieres May, 2011
-
Or perhaps rampant paranoia? :-D
Christopher Duncan Author of The Career Programmer Watch Bad Programmer! - Premieres May, 2011
Hey I've spent a lot of money and time in therapy, I got it whipped. :)
Semper Fi http://www.hq4thmarinescomm.com[^]
www.jaxcoder.com[^] WinHeist -
Anyone that has ever debugged a pointer problem in c/c++ uses and appreciates the check for null, I guess it just carries over...habit?
Semper Fi http://www.hq4thmarinescomm.com[^]
www.jaxcoder.com[^] WinHeistWell I never did C++ coding much but I always do null checks. How else do you avoid the object not set to an instance of an object exception??? Of course if they slap try catches around it and ignore the exception..... :omg:
-
Hey I've spent a lot of money and time in therapy, I got it whipped. :)
Semper Fi http://www.hq4thmarinescomm.com[^]
www.jaxcoder.com[^] WinHeist:laugh:
Christopher Duncan Author of The Career Programmer Watch Bad Programmer! - Premieres May, 2011
-
Well I never did C++ coding much but I always do null checks. How else do you avoid the object not set to an instance of an object exception??? Of course if they slap try catches around it and ignore the exception..... :omg:
Michael J. Eber wrote:
Of course if they slap try catches around it and ignore the exception..... :OMG:
:omg: You mean that's legal? I thought they put you in jail for that sort of thing.
Christopher Duncan Author of The Career Programmer Watch Bad Programmer! - Premieres May, 2011
-
They're the ones who actually check for null before using an object. I've found that it's comparatively rare in the C# world to see this test as a standard coding practice. Who knows, maybe tripping over a null value is less evil in today's condom protected world of managed software development (and I'm talking about the programmers, not the code, being "managed") than it used to be. Try a stunt like that in the world of C and you might trash memory that you later regret. Loss of data, screw up the OS, spontaneously reboot the machine... shucks, there's just all sorts of havoc that a wild pointer can do in C. And don't even get me started on wild programmers. Maybe the memory management in .net makes it less hazardous to access a null object, but it sure as hell isn't any less embarrassing. I mean, it's bad enough if you do decent error handling / reporting and give the user a message that says, "Damn. That was embarrassing. Care to try again now that we're sober?" But to get a YSOD or system popup message saying something arcane about a null value being encountered is just amateur hour. Nowhere is this more prevalent than the world of client side javascript, something I've successfully avoided for years. Now that I'm digging into it a bit, it's just amazing to me the degree of half assed techniques, cryptic, one letter names, untested variables and other such grade school level sloppiness in what should be professionally written code. Write code like that in any other part of the system in a decent development shop and you may have a brief and unexpected encounter with the Exit sign. But as long as you're only writing javascript, I guess it's okay. I mean, it's not like a customer would see an embarrassing error message pop up out of their browser and make your company look stupid or anything. Actually, though it sounds like I'm cranky and having a bad day, at the moment I'm nose deep in a personal project and having quite the good time. But sometimes you just wanna whack someone upside the head with a whiteboard eraser, you know? :-D
Christopher Duncan Author of The Career Programmer Watch Bad Programmer! - Premieres May, 2011
I wouldn't check for null in C# unless I expected that the input should sometimes be null. You'll get a NullReferenceException if you try do do anything with a null value. No crazy memory stuff like in the old days.
-
I wouldn't check for null in C# unless I expected that the input should sometimes be null. You'll get a NullReferenceException if you try do do anything with a null value. No crazy memory stuff like in the old days.
Well, if you're trapping and handling your exceptions you're essentially still checking for null values, just in a different manner. Of course, for those who don't, then an unhandled exception gets thrown. As damaging as the C world? Perhaps not, but it still makes your product look bad.
AspDotNetDev wrote:
unless I expected that the input should sometimes be null.
The best bugs are always the ones that weren't expected. :)
Christopher Duncan Author of The Career Programmer Watch Bad Programmer! - Premieres May, 2011
-
They're the ones who actually check for null before using an object. I've found that it's comparatively rare in the C# world to see this test as a standard coding practice. Who knows, maybe tripping over a null value is less evil in today's condom protected world of managed software development (and I'm talking about the programmers, not the code, being "managed") than it used to be. Try a stunt like that in the world of C and you might trash memory that you later regret. Loss of data, screw up the OS, spontaneously reboot the machine... shucks, there's just all sorts of havoc that a wild pointer can do in C. And don't even get me started on wild programmers. Maybe the memory management in .net makes it less hazardous to access a null object, but it sure as hell isn't any less embarrassing. I mean, it's bad enough if you do decent error handling / reporting and give the user a message that says, "Damn. That was embarrassing. Care to try again now that we're sober?" But to get a YSOD or system popup message saying something arcane about a null value being encountered is just amateur hour. Nowhere is this more prevalent than the world of client side javascript, something I've successfully avoided for years. Now that I'm digging into it a bit, it's just amazing to me the degree of half assed techniques, cryptic, one letter names, untested variables and other such grade school level sloppiness in what should be professionally written code. Write code like that in any other part of the system in a decent development shop and you may have a brief and unexpected encounter with the Exit sign. But as long as you're only writing javascript, I guess it's okay. I mean, it's not like a customer would see an embarrassing error message pop up out of their browser and make your company look stupid or anything. Actually, though it sounds like I'm cranky and having a bad day, at the moment I'm nose deep in a personal project and having quite the good time. But sometimes you just wanna whack someone upside the head with a whiteboard eraser, you know? :-D
Christopher Duncan Author of The Career Programmer Watch Bad Programmer! - Premieres May, 2011
I always place checks for nulls on all parameters received by public methods. Had a really bad time in my past job where developers programmed like @rsses and thought that just by calling a routine, it should do whatever they needed, careless that they fed the parameters with nulls because they didn't need them...like a context! :doh:
"Whether you think you can, or you think you can't--either way, you are right." — Henry Ford
-
They're the ones who actually check for null before using an object. I've found that it's comparatively rare in the C# world to see this test as a standard coding practice. Who knows, maybe tripping over a null value is less evil in today's condom protected world of managed software development (and I'm talking about the programmers, not the code, being "managed") than it used to be. Try a stunt like that in the world of C and you might trash memory that you later regret. Loss of data, screw up the OS, spontaneously reboot the machine... shucks, there's just all sorts of havoc that a wild pointer can do in C. And don't even get me started on wild programmers. Maybe the memory management in .net makes it less hazardous to access a null object, but it sure as hell isn't any less embarrassing. I mean, it's bad enough if you do decent error handling / reporting and give the user a message that says, "Damn. That was embarrassing. Care to try again now that we're sober?" But to get a YSOD or system popup message saying something arcane about a null value being encountered is just amateur hour. Nowhere is this more prevalent than the world of client side javascript, something I've successfully avoided for years. Now that I'm digging into it a bit, it's just amazing to me the degree of half assed techniques, cryptic, one letter names, untested variables and other such grade school level sloppiness in what should be professionally written code. Write code like that in any other part of the system in a decent development shop and you may have a brief and unexpected encounter with the Exit sign. But as long as you're only writing javascript, I guess it's okay. I mean, it's not like a customer would see an embarrassing error message pop up out of their browser and make your company look stupid or anything. Actually, though it sounds like I'm cranky and having a bad day, at the moment I'm nose deep in a personal project and having quite the good time. But sometimes you just wanna whack someone upside the head with a whiteboard eraser, you know? :-D
Christopher Duncan Author of The Career Programmer Watch Bad Programmer! - Premieres May, 2011
-
Christopher Duncan wrote:
I've found that it's comparatively rare in the C# world to see this test as a standard coding practice.
It's frequently added as a part of the debugging process, though.
:laugh:
Christopher Duncan Author of The Career Programmer Watch Bad Programmer! - Premieres May, 2011
-
They're the ones who actually check for null before using an object. I've found that it's comparatively rare in the C# world to see this test as a standard coding practice. Who knows, maybe tripping over a null value is less evil in today's condom protected world of managed software development (and I'm talking about the programmers, not the code, being "managed") than it used to be. Try a stunt like that in the world of C and you might trash memory that you later regret. Loss of data, screw up the OS, spontaneously reboot the machine... shucks, there's just all sorts of havoc that a wild pointer can do in C. And don't even get me started on wild programmers. Maybe the memory management in .net makes it less hazardous to access a null object, but it sure as hell isn't any less embarrassing. I mean, it's bad enough if you do decent error handling / reporting and give the user a message that says, "Damn. That was embarrassing. Care to try again now that we're sober?" But to get a YSOD or system popup message saying something arcane about a null value being encountered is just amateur hour. Nowhere is this more prevalent than the world of client side javascript, something I've successfully avoided for years. Now that I'm digging into it a bit, it's just amazing to me the degree of half assed techniques, cryptic, one letter names, untested variables and other such grade school level sloppiness in what should be professionally written code. Write code like that in any other part of the system in a decent development shop and you may have a brief and unexpected encounter with the Exit sign. But as long as you're only writing javascript, I guess it's okay. I mean, it's not like a customer would see an embarrassing error message pop up out of their browser and make your company look stupid or anything. Actually, though it sounds like I'm cranky and having a bad day, at the moment I'm nose deep in a personal project and having quite the good time. But sometimes you just wanna whack someone upside the head with a whiteboard eraser, you know? :-D
Christopher Duncan Author of The Career Programmer Watch Bad Programmer! - Premieres May, 2011
Two things come to mind (I have never had the displeasure of working with c++)
Christopher Duncan wrote:
Try a stunt like that in the world of C and you might trash memory that you later regret. Loss of data, screw up the OS, spontaneously reboot the machine
I believe the consequences are not as dramatic in managed code.
Christopher Duncan wrote:
half assed techniques, cryptic, one letter names, untested variables and other such grade school level sloppiness
Does the corrollery to that indicate that people that use single character variables are steeped in javascript? It has always made me wonder when working through an example or a snaffled snippet when I come across a single character variable whether the coder was just too lazy to type more than 1 character.
Never underestimate the power of human stupidity RAH
-
They're the ones who actually check for null before using an object. I've found that it's comparatively rare in the C# world to see this test as a standard coding practice. Who knows, maybe tripping over a null value is less evil in today's condom protected world of managed software development (and I'm talking about the programmers, not the code, being "managed") than it used to be. Try a stunt like that in the world of C and you might trash memory that you later regret. Loss of data, screw up the OS, spontaneously reboot the machine... shucks, there's just all sorts of havoc that a wild pointer can do in C. And don't even get me started on wild programmers. Maybe the memory management in .net makes it less hazardous to access a null object, but it sure as hell isn't any less embarrassing. I mean, it's bad enough if you do decent error handling / reporting and give the user a message that says, "Damn. That was embarrassing. Care to try again now that we're sober?" But to get a YSOD or system popup message saying something arcane about a null value being encountered is just amateur hour. Nowhere is this more prevalent than the world of client side javascript, something I've successfully avoided for years. Now that I'm digging into it a bit, it's just amazing to me the degree of half assed techniques, cryptic, one letter names, untested variables and other such grade school level sloppiness in what should be professionally written code. Write code like that in any other part of the system in a decent development shop and you may have a brief and unexpected encounter with the Exit sign. But as long as you're only writing javascript, I guess it's okay. I mean, it's not like a customer would see an embarrassing error message pop up out of their browser and make your company look stupid or anything. Actually, though it sounds like I'm cranky and having a bad day, at the moment I'm nose deep in a personal project and having quite the good time. But sometimes you just wanna whack someone upside the head with a whiteboard eraser, you know? :-D
Christopher Duncan Author of The Career Programmer Watch Bad Programmer! - Premieres May, 2011
They (me) spend time hand optimizing their (my) code - even though the complier will do it too :doh: I keep telling myself that fewer lines of code will be easier to maintain in the long run :rolleyes:
Steve _________________ I C(++) therefore I am
-
They're the ones who actually check for null before using an object. I've found that it's comparatively rare in the C# world to see this test as a standard coding practice. Who knows, maybe tripping over a null value is less evil in today's condom protected world of managed software development (and I'm talking about the programmers, not the code, being "managed") than it used to be. Try a stunt like that in the world of C and you might trash memory that you later regret. Loss of data, screw up the OS, spontaneously reboot the machine... shucks, there's just all sorts of havoc that a wild pointer can do in C. And don't even get me started on wild programmers. Maybe the memory management in .net makes it less hazardous to access a null object, but it sure as hell isn't any less embarrassing. I mean, it's bad enough if you do decent error handling / reporting and give the user a message that says, "Damn. That was embarrassing. Care to try again now that we're sober?" But to get a YSOD or system popup message saying something arcane about a null value being encountered is just amateur hour. Nowhere is this more prevalent than the world of client side javascript, something I've successfully avoided for years. Now that I'm digging into it a bit, it's just amazing to me the degree of half assed techniques, cryptic, one letter names, untested variables and other such grade school level sloppiness in what should be professionally written code. Write code like that in any other part of the system in a decent development shop and you may have a brief and unexpected encounter with the Exit sign. But as long as you're only writing javascript, I guess it's okay. I mean, it's not like a customer would see an embarrassing error message pop up out of their browser and make your company look stupid or anything. Actually, though it sounds like I'm cranky and having a bad day, at the moment I'm nose deep in a personal project and having quite the good time. But sometimes you just wanna whack someone upside the head with a whiteboard eraser, you know? :-D
Christopher Duncan Author of The Career Programmer Watch Bad Programmer! - Premieres May, 2011
I saw some code for Air Traffic Control System.
Plane* p = FindIncomingPlane();
if (p != NULL)
{
Cordinate* coord = p->Coordinate();if (coord != NULL)
{
Controller* c = GetController();while(c != NULL) { if (!c->IsSleeping()) break; c = GetNextController(); }if (c != NULL)
{
c->Post(coord);
}
}
}Of course the migrated C# code is much simpler
Plane p = FindIncomingPlane();
// Air Traffic Controller being awake? That's a joke ust return from the function
return; -
I saw some code for Air Traffic Control System.
Plane* p = FindIncomingPlane();
if (p != NULL)
{
Cordinate* coord = p->Coordinate();if (coord != NULL)
{
Controller* c = GetController();while(c != NULL) { if (!c->IsSleeping()) break; c = GetNextController(); }if (c != NULL)
{
c->Post(coord);
}
}
}Of course the migrated C# code is much simpler
Plane p = FindIncomingPlane();
// Air Traffic Controller being awake? That's a joke ust return from the function
return;You know I used to write air traffic control software, right? :) We actually had a much simpler system. If the controllers were asleep, we just flipped a switch that sent a large amount of voltage into their chairs. Sadly, the unions wouldn't let us roll that change out. :doh:
Christopher Duncan Author of The Career Programmer Watch Bad Programmer! - Premieres May, 2011
-
They (me) spend time hand optimizing their (my) code - even though the complier will do it too :doh: I keep telling myself that fewer lines of code will be easier to maintain in the long run :rolleyes:
Steve _________________ I C(++) therefore I am
I gave up on the concept of optimizing at that level when Windows 3.1 came out. I figured there was no point since Windows was just going to suck the life out of the performance anyway. Nonetheless... solidarity, brother! :-D
Christopher Duncan Author of The Career Programmer Watch Bad Programmer! - Premieres May, 2011
-
You know I used to write air traffic control software, right? :) We actually had a much simpler system. If the controllers were asleep, we just flipped a switch that sent a large amount of voltage into their chairs. Sadly, the unions wouldn't let us roll that change out. :doh:
Christopher Duncan Author of The Career Programmer Watch Bad Programmer! - Premieres May, 2011
I'm all for that. I mean, that should never ever happen anyway, right? :rolleyes:
-
I'm all for that. I mean, that should never ever happen anyway, right? :rolleyes:
Hey! Keep it quiet, would you? People are trying to sleep. :)
Christopher Duncan Author of The Career Programmer Watch Bad Programmer! - Premieres May, 2011
