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 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
-
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 beg to differ. Checking for every possible outcome is a necessary (but not sufficient) condition of a correctly written program. Modern operating systems allow you to forgo these checks by providing overall handlers for uncaught exceptions and prevent attempts to write to read-only memory and attempts to perform operations outside your privilege level. Imho, it all depends on the contract between your code and an invoked system. If a provider that returns an object is expected to throw a
ObjectNotFoundExceptioninstead of returning anullvalue, then checking fornullis superflous and a waste of execution time and program size. OTOH, if the contract declares the provider will returnnullif the object is not found, forgoing this check is plain wrong. Subsystems like Linq offer developers the ability to use either version of the contract by providing (for example).First()and.FirstOrDefault()implementations. /raviMy new year resolution: 2048 x 1536 Home | Articles | My .NET bits | Freeware ravib(at)ravib(dot)com
-
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'm in a 4 day MVP open day conference in Microsoft IDC. There are about 60 people in total, including about 40 Microsoft MVPs. Can you guess the number of C++ MVPs out of that? One. Yours truly. There's a good thing about it though. When others ask me what am I into, and I tell C++, they show me some immediate respect, usually saying something along the lines "Ooh, C++ - you guys are the *real* geeks". I hope this works out for me, and I become a rare scarce resource. I'm hoping to buy a nice Island sometime soon. :)
"Real men drive manual transmission" - Rajesh.
-
I'm in a 4 day MVP open day conference in Microsoft IDC. There are about 60 people in total, including about 40 Microsoft MVPs. Can you guess the number of C++ MVPs out of that? One. Yours truly. There's a good thing about it though. When others ask me what am I into, and I tell C++, they show me some immediate respect, usually saying something along the lines "Ooh, C++ - you guys are the *real* geeks". I hope this works out for me, and I become a rare scarce resource. I'm hoping to buy a nice Island sometime soon. :)
"Real men drive manual transmission" - Rajesh.
Save a rum and coke for me when you do! :)
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.
Christian Graus wrote:
it's a huge gotcha to think that .NET manages memory. It really doesn't, not very well.
Care to elaborate?
Regards Senthil _____________________________ My Home Page |My Blog | My Articles | My Flickr | WinMacro
-
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 recently wrote some .NET code where I check for null since the variable has three valid states: null, initialized by empty, initialized but full. (Going the other way, I get annoyed when people check for null in C++ before a delete (or free). Or who, IN GENERAL, check for null after allocations. My experience is that if you can't allocate memory, you are so screwed, there's nothing you can do about it. By that point, even trying to log the error will very likely fail.)
-
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.
Compared to what? Back when I did a lot of C++ I was skeptical about how well picking one general purpose memory allocation scheme could work. With C++ I could control allocation for every part of my app even if the default one was ridiculously slow. Almost 10 years later and I've only had to worry about memory allocation in C# for one app, and that was only when there were millions of objects taking up gigs of memory. Even then, I just switched from classes to arrays of structs and I got excellent performance.
Curvature of the Mind now with 3D
-
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 usually start out by beating sense into the dumbass that thought it was ok to return null as a common operation.
Christopher Duncan wrote:
But as long as you're only writing javascript, I guess it's okay.
Actually if you are writing if (a == null) it probably isn't doing what you think it is. if (a === null) will do what you are probably thinking of, but it is probably not what you want. This has some of the pitfalls http://www.mapbender.org/JavaScript_pitfalls:_null,_false,_undefined,_NaN[^] I highly recommend: Javascript the good parts.
Curvature of the Mind now with 3D
-
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:
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.
For the one-letter variable names, you could give them benefit of the doubt and assume they are running code through a minimizer to reduce download size. Realistically, that's probably not true though.