You can always tell the guys who came from the world of C / C++

[Andy Brummer]

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

[Andy Brummer]

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

[Rob Grainger]

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.

[Rob Grainger]

Andy Brummer wrote:

I highly recommend: Javascript the good parts

I think this should be required reading for any JS developer.

[Super Lloyd]

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.

[Erik Rude]

.Net collections and the large object heap[^]

[dave dolan]

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.

[djdanlib 0]

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!"

[djdanlib 0]

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]

Definitely, it's one of the things I ask about when interviewing candidates.

Curvature of the Mind now with 3D

[Stefan_Lang]

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:

[patbob]

"They're the ones who actually check for null before using an object." I'll give you a clue.. there's a reason we write code that way. In 10-20 years, you'll understand, and probably be doing it yourself.

patbob

[Rick Shaub]

I prefer managed code because an unitialized reference is always null. In C or C++, an unitialized pointer could be any value. Also, there's a big advantage to letting the exception be thrown if you don't have a way to handle a null reference. If it's your responsibility to initialize the reference, then you'll find out your mistake as soon as you test the code.

[PHLIPH]

I thought if you programmed in C# you alrteady were in jail. :)

[Fabio Franco]

I feel your pain. One of the problems I see people running the most (and myself when using other people's code) is the NullReferenceException. Although I have some C/C++ background, it's not one with lots of experience, but I don know that checking for null is a very good practice. It surprises me that some people try to argue against checking for null saying: "But it will never be null! You don't need to check that!", and often these people don't realize all possible ways a variable can become null or never instantiated. And the same people complain over and over because they don't know why such an exception is being thrown :doh: Good thing I don't have a JS background, I'd hate to have created nasty habits like the ones possible in JS.