Validator class for PHP
Sanitize Functions

First of all, note that your class does two very different things:


It checks if data is valid, returning either true or false (name, email).
It changes the data so that it is valid (sanitize).


Combining both of these functionalities in the same class can get confusing quickly. 

construct

Why does the constructor do sanitation? You already have basicSanitize, shouldn't that be responsible? And where is the result actually checked?

basicSanitize

The name alone already suggests that this isn't a great function. It's so generic, this function could be doing anything. 

Let's look at what it is doing (adapted from my answer here, as these kinds of functions are quite often combined, even though they shouldn't be):


trim: removes whitespace from beginning and end of string. This might be useful in some situations, and doesn't hurt in too many situations. It doesn't really affect security.
stripslashes: as the name suggests, it removes slashes. This is only useful if magic quotes is on (which is the functionality that adds slashes), so you should check that first, as otherwise you may corrupt your data. If magic quotes is on (it shouldn't be), using stripslashes is recommended, as otherwise you will have corrupted data.
htmlspecialchars again, this might corrupt your data (as in, you are not saving your original data in the database, but changed data). It is proper defense against XSS in most (but not all) situations (see here for exceptions, and use ENT_QUOTES), but it really should not happen before inserting data into the database, for two reasons: 1. corrupted data 2. This approach makes it easy to introduce XSS vulnerabilities. XSS is a vulnerability that is introduced when echoing data, so that is when it should be prevented. Otherwise, it will be hard to remember which data is secure and which is not. 


To summarize: Your approach changes input data before it is inserted into the database, which could impact usability. This doesn't even add that much security, and is certainly not considered a best practice approach to security.

name

This functions doesn't really have anything to do with names. I'm glad that you are not too restrictive, but really, this is nothing more than a length check, so it might as well be called checkLength($data, $min, $max).

email

This is fine. FILTER_VALIDATE_EMAIL doesn't follow any email specs, but as it's PHPs inbuilt filter, it seems ok to use it.

Style / Coding Standards

I'm glad that you asked about this, as there are a couple of issues:


Your indentation is off, making your code difficult to read. 
use curly brackets for all statements, even one-line statements. 
Your spacing is off.
Your function level comments could be PHPDoc comments.


Use any IDE to fix most of these issues automatically.

Structure

Your class has state, but doesn't really need it, as your private fields are never used across functions. So they are just making your class unnecessarily complex.

You can just make your functions static. For example, your email function could just as well look like this:

public function email($data) {
    if (!filter_var($email, FILTER_VALIDATE_EMAIL)) {
         return "Invalid email format"; 
    }
    return true;
}


And your name function:

public function name($data) {
    if(strlen($data) &lt; 3) {
        return "Name too short.";
    } else if(strlen($data) &gt; 100) {
        return "Name too big.";
    } 
    return true;
}


API

Your class is very awkward to use. I imagine it works something like this:

$validate = new Validate($_GET); // this seems to make sense, but actually will not do anything
$validatedName = $validate-&gt;name($_GET['name']);
if (!$validatedName) {
    // handle $validatedName, which contains an error message
} else {
    // everything is fine
}


You'll notice that this doesn't actually work!

The reason for this is that strings as well as true evaluate to true with weak comparison. So instead, I'll need $validatedName !== true. And I will need to remember to use strict comparison each time, as I will otherwise have a - possibly quite serious - bug in my code. 

The main problem is that you are sending error messages via the same mean as your return value, which just complicates things. 

There are three different solutions that come to mind:


get rid of the error message and just return true or false. For many filters this will make perfect sense (if the email filter failed, it's because the input isn't an email, no need to explain).
store the error message in a field, which can later be accessed if needed.
throw an exception containing the error message on failure.