3 ms·

You didn't just tell us all that being forced to check for null references strengthens the spirit, now did you? That is akin to saying that being forced to chec

You didn't just tell us all that being forced to check for null references strengthens the spirit, now did you? That is akin to saying that being forced to check for buffer overflows is edifying, or that no programmer from a good family uses garbage collectors.

Stormbringer 16y ago
No it's not. Checking for nulls (and it's brother-by-a-different-mother catching exceptions) is entirely in keeping with the philosophy of being lenient in what you accept as input. Checking for nulls is good practice because it makes you think about what is happening in the code. It makes you think about making design decisions about how you will handle nulls. It makes you aware that some libraries out there may return null from a method call. It makes you aware that no matter how often you make your co-workers sign a death pact in their own blood that they will never return a null or pass you a null, that they may do so anyway either through omission or commission (incompetence or miscomprehension or some weird boundary condition). Checking for nulls is compatible with a philosophy of thoroughly testing your code. Even if you are the perfect programmer, others are not. Refusing to check for nulls is to be at risk of disagreeing with reality how it should work. Reality always wins. Realising that if everyone else is not perfect, that perhaps they are also not perfect, is what causes the personal growth benefit I ascribed to being a more careful programmer.
- whateverer 16y ago
  Thanks for the response. Well, the thing is, that you shouldn't have to fear for null to creep up somewhere in the code at any time. Sure, if your language (like most, sadly) has null as an alternate value for almost any type you'll have to do that, just like in C you have to check for the bounds of the buffers into which you read strings, but that doesn't have to be the case! There are languages that made away with null in general, such as Haskell (yes, I know, I know), where if you have operations that require some null-equivalent, you declare it so by using the Maybe monad, and the compiler will ensure that the null gnomes won't throw a wrench at the rest of your code :) On not trusting the output of other layers/code: it's a great policy, but I do think that we should strive to be able to take more and more things for granted in our code, or at least reasonably for granted, like we usually trust that random bits won't change in our integers because of cosmic rays. And for that the language designers can give us tools in some form or another, if they do their homework. It will only make it easier to live with our limitations.

Stormbringer 16y ago

No it's not. Checking for nulls (and it's brother-by-a-different-mother catching exceptions) is entirely in keeping with the philosophy of being lenient in what you accept as input. Checking for nulls is good practice because it makes you think about what is happening in the code. It makes you think about making design decisions about how you will handle nulls. It makes you aware that some libraries out there may return null from a method call. It makes you aware that no matter how often you make your co-workers sign a death pact in their own blood that they will never return a null or pass you a null, that they may do so anyway either through omission or commission (incompetence or miscomprehension or some weird boundary condition). Checking for nulls is compatible with a philosophy of thoroughly testing your code. Even if you are the perfect programmer, others are not. Refusing to check for nulls is to be at risk of disagreeing with reality how it should work. Reality always wins. Realising that if everyone else is not perfect, that perhaps they are also not perfect, is what causes the personal growth benefit I ascribed to being a more careful programmer.

whateverer 16y ago
Thanks for the response. Well, the thing is, that you shouldn't have to fear for null to creep up somewhere in the code at any time. Sure, if your language (like most, sadly) has null as an alternate value for almost any type you'll have to do that, just like in C you have to check for the bounds of the buffers into which you read strings, but that doesn't have to be the case! There are languages that made away with null in general, such as Haskell (yes, I know, I know), where if you have operations that require some null-equivalent, you declare it so by using the Maybe monad, and the compiler will ensure that the null gnomes won't throw a wrench at the rest of your code :) On not trusting the output of other layers/code: it's a great policy, but I do think that we should strive to be able to take more and more things for granted in our code, or at least reasonably for granted, like we usually trust that random bits won't change in our integers because of cosmic rays. And for that the language designers can give us tools in some form or another, if they do their homework. It will only make it easier to live with our limitations.