Take 40% off Street Coder by entering fcckapanoglu into the discount code box at checkout at manning.com.

Types

Programmers take data types for granted. Some even argue that programmers are faster in dynamically typed languages like JavaScript or Python because they don’t have to deal with intricate details like deciding the type of each variable.

Yes, specifying types for every variable, parameter, and member in the code is a chore, but you need to adopt a holistic approach to being faster. Being fast isn’t solely about writing code but maintaining it too. There could be few cases where you may not need to care about maintenance because you learned that you got fired and you couldn’t care less, but that isn’t going to be the case all the time (hopefully). Apart from that, software development is a marathon, not a sprint.

Failing early is one of the best practices in development. Data types are one of the earliest defenses against development friction in coding. Types let you fail early and fix your mistakes before they become a burden. Aside from the obvious benefit of not confusing a string with an integer accidentally, you can make types work for you in other ways.

Being strong on the type

I’m sure most programming languages have types. Even the simplest programming languages like BASIC had types: strings and integers; some of its dialects even had real numbers. Types were invented to make our lives easier. Types are free checks for correctness, and understanding the underlying type system can help tremendously to make you a productive programmer.

How programming languages implement types is strongly correlated with whether they’re interpreted or compiled:

• Interpreted programming languages like Python or JavaScript let you to run code in a text file immediately without a need for a compilation step. Because of their immediate nature, variables tend to have flexible types: you can assign a string to a previously integer variable, you can even add strings and numbers together. These are usually called dynamically typed languages because of how they implement types. You can write code much faster in interpreted languages because you don’t need to declare types.
• Compiled programming languages tend to be stricter. How strict they are depend on how much pain the language designer wants to inflict upon you. For example, Rust language can be considered the German-engineering of programming languages, extremely strict, perfectionist, and therefore error-free. C language can also be considered German-engineering but like Volkswagen: it lets you to break the rules and pay the price later. Both languages are statically typed, once a variable is declared its type can’t change, but Rust is called strongly typed like C# but C is considered weakly typed.

Strongly and weakly typed means how relaxed a language is in terms of assigning different types of variables to each other. C is more relaxed in that sense; you can assign a pointer to an integer or vice versa without issues, but C# is stricter; pointers/references and integers are incompatible types.

Strict programming languages can be frustrating. They can even make you question life and why we exist in the universe when it comes to languages like Rust. Declaring types and converting them explicitly when needed may look like a lot of bureaucracy. You don’t need to declare types of every variable, argument, and member in JavaScript for example. If many programming languages can work without explicit and strict types, why do we burden ourselves with them?

The answer is simple: types can help us write code which is safer, faster, and easier to maintain. We can reclaim the time we lost when we declare types of variables, annotating our classes with the time we gained by having to debug fewer bugs, and having to solve fewer issues with performance. Apart from obvious benefits of types, there are some subtle benefits too. Let’s go over them.

Proof of validity

Proof of validity is one of the less-known benefits of having predefined types. Suppose that you’re developing a microblogging platform which only allows certain amount of characters in every post, and you’re not judged for being too lazy to write something longer than a sentence. In this hypothetical microblogging platform, you can mention other users in a post with “@” prefix and mention other posts with “#” prefix followed by the post’s identifier. You can even retrieve a post by typing its identifier in the search box. If you type in a username with “@” prefix in the search box, that user’s profile is shown.

User input brings a new set of problems with validation. What happens if user provides letters after “#” prefix? What if they input a longer number than allowed? It might seem like those scenarios work themselves out, but usually your app crashes because somewhere in the code path, something that doesn’t expect an invalid input throws an exception. It’s the worst possible experience for the user: they don’t know what has gone wrong and they don’t even know what to do next. It can even become a security problem if you display that given input without sanitizing it.

Data validation doesn’t provide a proof of validity throughout the code. You can validate the input in client, but somebody, a third-party app for example, can send a request without validation. You can validate at the code that handles web requests, but another app of yours, such as your API code, can call your service code without necessary validation. Similarly, your database code can receive requests from multiple sources, like the service layer and a maintenance task, and you need to make sure that you are inserting the right records in the database.

Figure 1. Unvalidated data sources and places where you need to validate data repetitively

That might eventually make you validate the input at multiple places around the code and you need to make sure that you are consistent in validation too. You don’t want to end up with a post with an identifier of “-1”, or a user profile named “’ OR 1=1–” (which is a basic SQL injection attack).

Types can carry over proof of validity. Instead of passing an integer for blog post identifiers or strings for usernames, you can have classes or structs that validate their input on construction which makes them impossible to contain an invalid value. It’s simple, yet powerful. Any function that receives a post identifier as a parameter asks for a PostId class instead of an integer. This allows you to carry over proof of validity after the first validation in the constructor. If it’s an integer, it needs to be validated, if it’s a PostId, it has already been validated; there’s no need to check its contents, because there’s no way to create it without validation, as you can see in the following snippet. The only way to construct a PostId in the code snippet is to call its constructor, which validates its value and throws an exception if it fails. That means it’s impossible to have an invalid PostId instance:

 
 public class PostId
 {
     public int Value { get; private set; }    #A
     public PostId(int id) {   #B
         if (id <= 0)  {
             throw new ArgumentOutOfRangeException(nameof(id));
         }
         Value = id;
     }
 }
  

#A Our value is impossible to be changed by external code.

#B Constructor is the only way to create this object.

When you decide to go that path, it’s not as easy as the example I’ve shown though. For example, comparing two different PostId classes with the same value wouldn’t work as you expected, as by default, comparison only compares references, not the contents of the classes. You need to add whole scaffolding around it to make it work without issues. Here’s a quick checklist:

• You need to at least implement an override for Equals method as some framework functions and some libraries can depend on it to compare two instances of your class.
• If you plan on comparing values yourself using equality operators (“==” and “!=”) you have to implement their operator overloads in the class.
• If you plan to use it in a Dictionary<K,V> as a key, you need to override GetHashCode method.
• String formatting functions such as String.Format uses ToString method to get a string representation of the class suitable for printing.

A PostId class with all necessary plumbing to make sure it works in all equality scenarios is shown in listing 1. We overrode ToString() and our class becomes compatible with string formatting and easier to inspect its value when we debug. We overrode GetHashCode() and it returns Value directly because the value itself can fit perfectly into an int. We overrode Equals() method and equality checks in collections of this class work correctly in case we need unique values, or we’d like to search against this value. We finally overrode “==” and “!=” operators and we can directly compare to PostId values without accessing its value.

 
 public class PostId
 {
     public int Value { get; private set; }
     public PostId(int id) {
         if (id <= 0) {
             throw new ArgumentOutOfRangeException(nameof(id));
         }
         Value = id;
     }
     public override string ToString() => Value.ToString();    #A
     public override int GetHashCode() => Value;    #A
     public override bool Equals(object obj) {    #A
         return obj is PostId other && other.Value == Value;
     }
     public static bool operator ==(PostId a, PostId b) {    #B
         return a.Equals(b);
     }
     public static bool operator !=(PostId a, PostId b) {    #B
         return !a.Equals(b);
     }
 }
  

#A System.Object overrides, using arrow syntax notation

#B Overloading code for equality operators

 
 public int Sum(int a, int b) {
     return a + b;
 }
  

 
 public int Sum(int a, int b) => a + b;
  

It’s not usually needed but in case your class needs to be in a container which is sorted or compared, you have to implement these two additional features too:

1. You need to provide ordering by implementing IComparable<T> because equality itself isn’t sufficient to determine the order. We didn’t use it in the listing 1 because identifiers aren’t ranked.
2. If you plan on comparing values using less than or greater than operators, you need to implement related operator overloads (“<”, “>”, “<=”, “>=”) for them too.

This can look like a lot of work when you can pass an integer around, but it pays off in large projects, like when working in a team. You’ll see more of the benefits in following sections.

You don’t always need to create new types in order to use a validation context. You can use inheritance to create base types which contain certain primitive types with common rules. For example, you can have a generic identifier type that can be adapted to other classes. You can rename PostId class in listing 1 to DbId and derive all types from it.

Whenever you need a new type like PostId, UserId, or TopicId you can inherit it from DbId and extend as needed. Here we can have fully functional varieties of same type of identifier to be able to distinguish them better from other types. You can also add more code in the classes to specialize them in their own way:

 
 public class PostId: DbId {    #A
     public PostId(int id): base(id) { }
 }
 public class TopicId: DbId {    #A
     public TopicId(int id) : base(id) { }
 }
 public class UserId: DbId {    #A
     public UserId(int id): base(id) { }
 }
  

#A We use inheritance to create new flavors of the same type.

Having separate types for your design elements makes it easier to semantically categorize different uses of our DbId type if you’re using them together and frequently. It also protects you from passing incorrect type of identifier to a function.

Custom data types are powerful as they can explain your design better than primitive types, can help you avoiding repetitive validation therefore bugs. They can be worth the hassle to implement. Moreover, the framework you’re using might already be providing the types you need.

Don’t framework hard, framework smart

.NET, like many other frameworks, comes with a set of useful abstractions for certain data types which are usually unknown or ignored. Custom text-based values like URLs, IP addresses, file names, or even dates are stored as strings. We’ll look at some of those ready-made types and how we can use them

Some of you may already know about .NET-based classes regarding those data types, but might still prefer to use a string, because it’s simpler to handle. The issue with strings is that they lack proof of validation; your functions don’t know if given string is already validated, causing either inadvertent failures or unnecessary re-validation code, slowing you down. Using a ready-made class for a specific data type is a better choice in those cases.

When only tool you have’s a hammer, every problem looks like a nail. The same applies to strings. Strings are great generalized storage for content, and they are easy to parse, split, merge, or play around. They’re tempting, but this confidence in the strings makes you inclined to re-invent the wheel occasionally. When you start handling things with a string, you tend to do everything with string processing functions although that can be entirely unnecessary.

Consider this example: you’re tasked to write a lookup service for a URL shortening company called Supercalifragilisticexpialidocious which is in financial trouble for unknown reasons, and you’re Obi-wan, their only hope. Their service works like this:

• User provides a long URL such as:
• https://llanfair.com/pwllgw/yngyll/gogerych/wyrndrobwll/llan/tysilio/gogo/goch.html
• The service creates a short code for the URL and creates a new short URL such as: https://su.pa/mK61
• Whenever user navigates to the shortened URL from their web browser, they get redirected to the address in the long URL they provided.

The function you need to implement must extract the short code from a shortened URL. A string-based approach looks like this:

 
 public string GetShortCode(string url)
 {
     const string urlValidationPattern =
         @"^https?://([\w-]+.)+[\w-]+(/[\w- ./?%&=])?$";    #A
     if (!Regex.IsMatch(url, urlValidationPattern)) {               
         return null; // not a valid URL
     }
     // take the part after the last slash
     string[] parts = url.Split('/');
     string lastPart = parts[^1];    #B
     return lastPart;
 }
  

#A This is an alien language called a regular expression. It’s used in string parsing and occult invocation rituals.

#B This is a new syntax introduced in C# 8 which refers to the second-to-last item in a range.

This code might look okay at first, but it contains bugs already, based on our hypothetical specification. The validation pattern for URL is incomplete, it allows invalid URLs. It doesn’t take the possibility of multiple slashes in the URL path into account. It unnecessarily creates an array of strings to get the final portion of URL.

More importantly, the logic isn’t apparent from the code. A better code might use the Uri class from .NET framework and look like the example below:

 
 public string GetShortCode(Uri url)    #A
 {
     string path = url.AbsolutePath;    #B
     if (path.Contains('/')) {
         return null;    #C
     }
     return path;
 }
  

#A It’s clear what we’re expecting.

#B Look ma, no regular expressions!

This time, we don’t deal with string parsing at all. All of that has been handled already by the time our function gets called. Our code is more descriptive, it’s easier to write, only because we wrote Uri instead of string. Because validation happens earlier in the code, it becomes easier to debug too. The best debugging is not having to debug in the first place.

In addition to primitive data types like int, string, float,.NET provides many other useful data types available to use in our code.

IPAddress is a better alternative to string for storing IP addresses. Not only because it has validation in it, but because it also supports IPv6 which is in use today, unbelievable, I know. The class also has shortcut members for defining a local address:

 
 var testAddress = IPAddress.Loopback;
  

This way, you avoid writing 127.0.0.1 whenever you need a loopback address, you become faster. In case you make a mistake with the IP address, you catch it earlier than you would with a string.

Another such type is TimeSpan. It represents a duration as the name implies. Durations are used almost everywhere in a software project, like when talking about caching or expiration mechanics. We tend to define durations as compile time constants. The worst possible way is this:

 
 const int cacheExpiration = 5; // minutes
  

It’s not immediately clear that the unit of cache expiration is in minutes. It’s impossible to know the unit without looking at the source code. It’s a better idea to incorporate it in the name at least, and your colleague, or even yourself in the future, know its type without looking at the source code:

 
 public const int cacheExpirationMinutes = 5;
  

It’s better this way but when you need to use the same duration for a different function that receives a different unit, you’ll have to convert it, like:

 
 cache.Add(key, value, cacheExpirationMinutes * 60);
  

This is extra work. You have to remember to do this. It’s prone to errors too. You can mistype 60 and have a wrong value in the end and maybe spend days debugging it or try to optimize performance needlessly because of such a simple miscalculation.

TimeSpan is amazing in that sense. No reason exists for you to represent any duration anything other than in TimeSpan, even when the function you’re calling doesn’t accept TimeSpan as a parameter.

 
 public static readonly TimeSpan cacheExpiration = TimeSpan.FromMinutes(5);
  

Look at that beauty! You already know it’s a duration and its unit where it’s declared. What’s better is that you don’t have to know its unit anywhere else. For any function that receives a TimeSpan, you pass it along. If a function receives a specific unit, say, minutes, as an integer, you can call it like this instead:

 
 cache.Add(key, value, cacheExpiration.TotalMinutes);
  

And it gets converted to minutes. Brilliant.

Many more types are useful in a similar sense like DateTimeOffset, which represents a specific date and time like DateTime but along with the time zone information, and you don’t lose data when suddenly your computer’s or server’s time zone information changes. In fact, you should always try to use DateTimeOffset over DateTime as it’s also convertible to/from DateTime easily. You can even use arithmetic operators with TimeSpan and DateTimeOffset, thanks to operator overloading:

 
 var now = DateTimeOffset.Now;
 var birthDate =
     new DateTimeOffset(1976, 12, 21, 02, 00, 00,
         TimeSpan.FromHours(2));
 TimeSpan timePassed = now - birthDate;
 Console.WriteLine($"It’s been {timePassed.TotalSeconds} seconds since I was born!");
  

.NET is like that gold pile that Uncle Scrooge jumps and swims in. It’s full of great utilities that make our lives easier. Learning about them might seem wasteful or boring, but it’s much faster than trying to use strings or to come up with your own makeshift implementations.

Types over typos

Writing code comments can be a chore. Even without the code comments, your code doesn’t have to lack descriptiveness. Types can help you to explain your code.

Consider you encounter this snippet in the vast dungeons of your project’s code base:

 
 public int Move(int from, int to) {
     // ... quite a code here
     return 0;
 }
  

What’s this function doing? What’s it moving? What kind of parameters is it taking? What kind of result is it returning? These are all vague without types. You can try to understand the code or try to look up the encompassing class, but they all take time. Your experience could be much better had the naming were better:

 
 public int MoveContents(int fromTopicId, int toTopicId) {
     // ... quite a code here
     return 0;
 }
  

It’s much better now, but you still have no way to know what kind of result it’s returning. Is it an error code, is it number of items moved, or is it the new topic identifier resulting from conflicts in the move operation? How can you convey this without relying on code comments? With types. Consider this code snippet instead:

 
 public MoveResult MoveContents(int fromTopicId, int toTopicId) {
     // ... still quite a code here
     return MoveResult.Success;
 }
  

It’s slightly clearer. I mean it doesn’t add much because we already knew that the int was the result of the move function, but there’s a difference: we now can explore what’s in MoveResult type to see what it’s doing by pressing F12 on Visual Studio for PC.

 
 public enum MoveResult
 {
     Success,
     Unauthorized,
     AlreadyMoved
 }
  

We’ve got a much better idea now. Not only does it improve the understanding of the method’s API but it also improves the code in the function too as instead of some constants or worse, hardcoded integer values, you see a clear MoveResult.Success. Unlike constants in a class, enums constrain the possible values that can be passed around and they come with own type name to have a better chance of describing the intent.

Because the function receives integers as parameters, it needs to incorporate some validation because it’s a publicly facing API. You can tell that it might even be needed in internal or private code because how validation got pervasive. This looks better if there’s a validation logic in the original code:

 
 public MoveResult MoveContents(TopicId from, TopicId to) {
     // ... still quite a code here
     return MoveResult.Success;
 }
  

As you can see, types can work for you by moving code to their relevant place, and making it easier to understand. Because the compiler checks if you wrote a type’s name correctly, they prevent you from having typos too.

That’s all for this article.

If you want to learn more about the book, you can check it out on our browser-based liveBook platform here.