Type safety basically means using strongly-typed data to protect against nasty bugs caused by type errors. A “strong type” is a programming construct that imposes certain rules or restrictions on specific data and how the data can be used. A “type error” is a bug that only appears at runtime (as opposed to compile time), and can have a considerably undesirable impact on data – often it only appears when you discover that something has gone terribly wrong. So, we should always strive to write type-safe code.

Here is an example. The following method call would not be considered type safe:

public void Promote( int EmployeeId, int JobId ) {}  // NOT type safe

Say you wanted to promote the employee with ID 42 into the job with ID 1492. With this method, you can simply do this:

int employeeId = myEmployee.Id;</p><p>int jobId = myJob.Id; 
Promote( employeeId, JobId ); // Dangerous

But what would happen if you did this instead?

Promote( jobId, employeeId ); // Big mistake

First of all, the compiler will not complain here because it’s perfectly valid code. But when you run it, you’ll be promoting that smelly guy in the mail room (employee 1492) to vice president of sales (job 42) rather than promoting employee 42 into job 1492! This type of problem can be completely avoided and can even result in more readable code by implementing type safety. So a much better way to implement the method would be

Promote( Employee employee, Job job );  // Type safe

If you tried to call this code with accidentally mixed up arguments, you’ll get a compiler error – it will not compile and it will not run. This is a good thing because you don’t want bad code to run – you don’t even want it to compile if at all possible.

Promote( myJob, myEmployee ); // WILL NOT COMPILE; WILL NOT RUN

“Type safety” can apply to many different types. For example, if you know you need an integer in your method, then you should not take it in as a string. In fact, if you know you need an integer that represents a year in recent history, then you should not take it in as simply an integer. This ensures predictable results – and if you make a mistake you’ll see it at compile time and not after the damage is done. Here’s an example:

given… public void AddNewEmployee( string name, Job job, DateTime startDate ) { }

AddNewEmployee( "John Smith", "minion", “Next Monday” );
// COMPILE ERROR "Next Monday" is clearly invalid but without type
// we wouldn’t catch the error until runtime. And "minion" may be a job,
// but it's ambiguous as a string.

AddNewEmployee( "John Smith", myJob, new DateTime(1969, 7, 20) ); 
// Should probably throw a RUNTIME ERROR BEFORE execution
// because the date, although famous, is probably not the start date.
// Catch it before the damage is done.

AddNewEmployee( "John Smith", myJob, DateTime.Now  ); 
// Valid and executable 

So, anytime you find yourself writing method signatures or properties that appear to be IDs or other non-safe types, you should try to make them type safe instead. This is especially true for frameworks.