You can always tell the guys who came from the world of C / C++
-
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.
-
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
Andy Brummer wrote:
I highly recommend: Javascript the good parts
I think this should be required reading for any JS developer.
-
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
One reason to not test null value... what's the difference, really, between..
void Foo(object mightbeNull)
{
if(mightBeNull == null)
throw new NullArgumentException()
// ...
}or
void Foo(object mightbeNull)
{
mightBeNull.Snafu()
// ...
}I test for null only if I can handle it. Or if there is multiple argument, so that I can throw an argument exception with a value added exception message! ;P
A train station is where the train stops. A bus station is where the bus stops. On my desk, I have a work station.... _________________________________________________________ My programs never have bugs, they just develop random features.
-
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
-
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
I think if you get a null, when you're not expecting one, most of the time you WANT to throw an exception anyway. I mean, what are you going to do anyway? Suppress the error and hang out? Personally, I usually check for them and try to throw 'informative' exceptions about what exactly was null, but beyond debugging this is really moot. An unexpected null means something is wrong, and you should probably let it blow up in grand style anyway.
-
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
Sometimes, they probably should. Eating an exception ought to be an offense :) Then again, I've been guilty of eating an exception or two in my day... for example, in a particularly offensive project... when setting up logging to a file AND the event log AND email, it was okay if the email object couldn't be created sometimes as long as setting up the event log worked. "But officer, I swear, it's okay to eat just this one!"
-
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
I remember when BASIC (as in the old pre-GUI ones like BASIC/A, GWBASIC, etc) was the prime culprit for people who learned to use single-character variable names. Is Javascript the new BASIC? :~
-
Andy Brummer wrote:
I highly recommend: Javascript the good parts
I think this should be required reading for any JS developer.
Definitely, it's one of the things I ask about when interviewing candidates.
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've found that NULL pointers are much less of a problem than uninitialized ones. The former gives you a nice NULL-Pointer exception that you can pinpoint and fix rather easily, the latter gives you a very hard to replicate and fix seg fault, but only in release mode, because compiler vendors for some obscure reason think it's a good idea to zero out all memory on debug builds, rather than make sure it does exactly what the release build does... :mad: