813

By default, older versions of IE (<=8) will submit form data in Latin-1 encoding if possible. By including a character that can't be expressed in Latin-1, IE is forced to use UTF-8 encoding for its form submissions, which simplifies various backend processes, for example database persistence. If the parameter was instead utf8=true then this wouldn't ...


167

The problem with your basic example isn't the null check, it's the silent fail. Null pointer/reference errors, more often than not, are programmer errors. Programmer errors are often best dealt with by failing immediately and loudly. You have three general ways to deal with the problem in this situation: Don't bother checking, and just let the runtime ...


64

Server side validation is absolutely necessary. Client side validation is purely a user experience improvement since the same validation should always happen on the server anyway. After all, you can always disable JavaScript or simply post arbitrary data directly via HTTP. If you can provide server side validation which gives just as smooth a user ...


57

It depends on whether knowing the validity of some input for a task that you aren't permitted to do is a security leak. If it is, you really should to do it the other way round. The only safe response to an unauthorised user is "access denied". If sometimes the response is "bad request" and other times "access denied", you are sending information to an ...


55

Since _someEntity can be modified at any stage, then it makes sense to test it every time that SetName is called. After all, it could have changed since the last time that method was called. But be aware that the code in SetName isn't thread-safe, so you can perform that check in one thread, have _someEntity set to null by another and then the code will barf ...


51

If the core of your question is this... If some client code passes an argument whose value is invalid for the thing that my data structure is modeling, should I reject the value or convert it to something sensible? ...then my general answer would be "reject", because this will help draw attention to potential bugs in the client code that are actually ...


47

There's an interesting article by Martin Fowler on that subject that highlights an aspect most people (including me) tend to overlook: But one thing that I think constantly trips people up is when they think object validity on a context independent way such as an isValid method implies. I think it's much more useful to think of validation as ...


42

That depends on how likely getUser and myMethod are to change, and more importantly, how likely they are to change independently of each other. If you somehow know for certain that getUser will never, ever, ever change in the future, then yes it's a waste of time validating it, as much as it is to waste time validating that i has a value of 3 immediately ...


26

Validation of data entry is one of those things where everyone starts out trying to make it pure and clean and (if they're smart about it) eventually gives up, because there are so many competing concerns. The UI layer must do some forms of validation right there on the client page/form in order to provide realtime feedback to the user. Otherwise the user ...


25

While I agree with JacquesB, if you can provide the same level of interaction server side, then client side validation isn't always needed - however some other points to consider. Point A (Speed): Client side validation is intended to be instant, as in 100% instant. While network speeds are improving, you're unlikely to be able to guarantee that this speed ...


24

Well, there are multiple types of validation: Cheap basic sanity-checking, which verifies that the request is not obviously malformed. This is typically at least partially duplicated client-side, to avoid futile round-trips. Anyway, it should be done before access-control to make things easier and less error-prone, as it doesn't risk any information-leak. ...


23

But should the method not have this check? This is your choice. By creating a public method, you are offering the public the opportunity to call it. This always comes along with an implicit contract on how to call that method and what to expect when doing so. This contract may (or may not) include "yeah, uhhm, if you pass null as a parameter value, it will ...


22

Ixrec's answer is good, but I will take a different approach because I believe that it is worth considering. For the purpose of this discussion I will be talking about assertions, since that's the name by which your Preconditions.checkNotNull() has traditionally been known. What I would like to suggest is that programmers often overestimate the degree by ...


20

This is actually a very difficult question to answer and I have found it to be a very controversial subject. As Yannis Rizos pointed out in his answer, having the constraint logic in both the database and the ORM layer would seem to violate DRY, which "can lead to maintenance nightmares, poor factoring, and logical contradictions". However, removing the ...


16

Your guiding principle should be Don’t Repeat Yourself: In software engineering, Don't Repeat Yourself (DRY) is a principle of software development aimed at reducing repetition of information of all kinds, especially useful in multi-tier architectures. The DRY principle is stated as "Every piece of knowledge must have a single, unambiguous, authoritative ...


16

You do need them as the client can decide to allow javascript in their browsers. You also should consider those people who want to break your software. There are plenty of tools out there that can manufacture posts and submit them to your website without having used your front end. Client side validation is nice for the user, but the server should never ...


15

Invalid null pointers can either be caused by programmer error or by runtime error. Runtime errors are something a programmer can't fix, like a malloc failing due to low memory or the network dropping a packet or the user entering something stupid. Programmer errors are caused by a programmer using the function incorrectly. The general rule of thumb I've ...


15

It depends. Deciding where to put validation should be based on the description and strength of the contract implied (or documented) by the method. Validation is a good way to bolster adherence to a specific contract. If for whatever reason the method has a very strict contract, then yes, it is up to you to check before calling. This is an especially ...


14

As this question created some controversy, let me start off this answer with my background: Apart from being exposed to V&V in daily project work, I worked for several years in the software engineering department of my alma mater and am a lecturer for software engineering. While this does not guarantee that anything I say is correct, I hope it at least ...


14

To make sure that it works. Sure, if you only write out some data for your own application to read it may be enough if it just works. If you send a file to somebody else matters may be different. But even within your application you may later choose to switch the parsing library and the new one may complain about errors the old one accepted and ignored like ...


14

What you're talking about here is trust boundaries. Do you trust the boundary between your application and the database? Does the database trust that the data from the application is always pre-validated? That's a decision that has to be made in every application and there are no right and wrong answers. I tend to err on the side of calling too many ...


14

Programming isn't an exact science (at least not yet), so you have a lot of leeway which you should use to apply common sense and do the sensible thing. Every object is responsible for itself There is a concept more fundamental than object-oriented programming, and this is encapsulation. Encapsulation could be paraphrased as “every conceptual unit is ...


14

As a user, I don't expect the whitespace on either side of the equals sign to change the value of the key or the value. See this related question on unix.SE as too how confusing the situation can be. Don't make it harder on your users, trim whitespace from both the key and the value. If leading whitespace has a real use case for either, then let the user ...


14

The other answers are good; I'd like to extend them by making some comments about accessibility modifiers. First, what to do if null is never valid: public and protected methods are those where you do not control the caller. They should throw when passed null. That way you train your callers to never pass you a null, because they would like their program ...


13

There must be some validation before access control. Let's say SO's API has an endpoint "edit answer", then whether the user can edit a particular answer can depend on the answer (below a certain reputation, a user can only edit his own answers). So the "answer ID" parameter being well-formed must be verified before the access control layer comes into play; ...


12

Validation will always be important, but during times of transition from one standard to another it's very difficult to pull off. It's especially hard when the standard isn't even finalized and agreed upon yet. So while validation is important, business is more important and simply won't wait for validation. So there will inevitably be some indefinite ...


12

yes, data can be always manipulated on a client side or in transfer. you can NEVER depend on a client side validation. client side is a hacker computer side, so not safe at all. client side validation is only for a user convenience. also as mentionad by @erik-eidt, there is potential for race condition with client side validation, ie user login name can be ...


11

Kernighan & Plauger, in "Software Tools", wrote that they would check everything, and, for conditions that they believed could in fact never happen, they would abort with an error message "Can't happen". They report being rapidly humbled by the number of times they saw "Can't happen" come out on their terminals. You should ALWAYS check the pointer for ...


11

It's up to you to define the rules for your app. For instance, you may define that: Whitespace before or after the equality sign is ignored, Whitespace inside the key is forbidden, Whitespace inside the value can be used only if the value is enclosed in quotes, so: say-hello = Hello, World! is forbidden, while: say-hello = "Hello, World!" is allowed, ...


10

It depends a lot. But you should decide to do something and document it. The only definitively wrong thing for your code to do is to forget to consider that user input might be outside the expected range, and write code that accidentally has some behaviour. Because then some people will make an incorrect assumption about how your code behaves and it will ...


Only top voted, non community-wiki answers of a minimum length are eligible