Validate User Input, Not Developer Input

I have a very simple rule, I like to follow that helps to simplify my code.

\n\n

“Don’t validate developer input”

\n\n

This rule simply means that we should not try and validate input that came from a source that is not a user or external system.\n\nAnother way to put it would be, don’t validate parameters you pass around in your own code.\n\n

γνῶθι σεαυτόν

\n\n(Know thyself)\n\n\n\nWhile you can’t guarantee input from another source is valid, you can know that your own code’s input is valid.\n\nWhen writing a method, we should really strive to know who is calling that method and put the onus on the caller of the method not to pass in junk.\n\nI know this isn’t a popular opinion, because it seems to go against the idea of “defensive programming,” but the idea of defensive programming is misunderstood.\n\nChuck Norris himself once said:\n\n

They say the best defense is not to offend.

\n\n

\n\nThat slogan applies well here.  Your strategy should be to make sure you always pass valid values into methods rather than trying to code methods to defensively do things with bad input.\n\n(Let’s not be uncivilized!)\n\nLet me give you an example:\n\n

\n\n \n\nDoesn’t that code look silly?\n\nThis is the exact opposite of what I am suggesting.\n\nRather than trying to decide which of these checks we should keep, and trying to follow some complex set of rules of when should we validate input like this, I am merely suggesting we get rid of all of it!\n\nI’ve written about not checking nulls before, but I am convinced now that checking any input from code you control is a code smell.\n\n

What can you do?

\n\nThrow an exception at best, at worst, infer what was meant by the caller and corrupt data.\n\nWhat purpose does throwing an exception there serve?  If you try and dereference a null object, you get an exception anyway.\n\nAre you even going to catch an exception if you throw it?\n\nIf so, does that mean you are wrapping every method call you make in a try / catch block?\n\nThe big problem with trying to validate input that was passed to you by code you control is that you can’t really do anything useful.  You are just cluttering up your code.\n\nAnother question, if you are still gung-ho on validating input on all method calls… Do you even do it?\n\nDo you actually check every parameter, or just when you remember.  Because, if you aren’t applying the checks uniformly, you cannot count on them.\n\n

Context

\n\nOne major reason why I advocate validating what you pass into a method rather than what is passed into a method, is context.\n\nIf you are inside a method and someone passes you a null, you have no context.\n\nWhat was going on that cause this parameter to be null?  I don’t know—I can’t know!\n\nBut—on the other hand, if I am about to call a method and I am about to pass that method a null, I know why.  I know that the list I got back was null and I could check for that and instead pass in an empty list to the method I was about to call.\n\nBetter yet, I can take it one more step further and not ever pass null back from the method that returns the list in the first place.\n\nThe point is that you have way more context before you call the method, than you do when you are in the method.  If you are going to validate the input, do it in a place where context will allow you to do something meaningful, rather than just throwing a random exception.\n\n

Better code

\n\nThinking this way will force you to write better code.  I firmly believe it.  \n\nMost of us don’t really think about what we are passing into methods or whether or we are returning nulls from methods, we instead tend to think about what we are being passed.\n\nBy changing things around, it leads us into better coding practices that are less error prone.\n\nWe are forced to think about standardizing and restricting ranges of values for parameters.\n\nWe are forced to start considering making our objects immutable, so that if we properly initialize them, they cannot contain null values.\n\nMost importantly, our code becomes cleaner, because it isn’t littered with error checking.  Instead of checking for errors everywhere, we are coding in a way that prevents them from being possible.\n\nSo the next time you are thinking about validating parameters passed into your method, by another method you have control over, don’t do it!\n\nIf you can’t trust yourself, who can you trust?  (Chuck Norris perhaps?)