How to improve your open source code (9) – Types
This post was written during my trip through Iceland and published much later than it was written.
This is a really important topic in programming and I really hope to get this article right. Not only for technical correctness, but also for ease to understand, as explaining types is not that simple if one has never heard of them.
Let's give it a try...
What are types
Well, that's a question which is, in my opinion, not easy to answer. In fact, I thought several days about this question before writing this down, in hope it will become a sufficient answer. Hence, you might find other answers which are easier to understand and maybe more correct as mine, but I'll give it a try nonetheless.
From what I think
Types are a combination of abilities and properties that are combined to express and limit a certain scope of a thing.
For example, A type Car
may have four wheels, two doors and a horn
(its properties) and can drive slow, drive fast and park (its
abilities). That is certainly not a real representation of a car (also
because only a car is a real representation of a car) but because of the
domain this is used in, it is sufficient in the scenario at hand. The
type Car
cannot be multiplied, but another type Number
may have this
ability. Thus, the scope and abilities are also limited in a certain
way.
I hope this description is a good one for you to understand.
Now that we know what types are, we should also learn some other terms around the subject of types. The first thing I want to talk about here is “strong typing” and “weak typing”. The reason for this is: These things do not exist. Yes, you've read this correctly: There is no such thing as “strong typing”. There is only stronger and weaker typing. The Java programming language is not strongly typed, neither is it weakly typed (but it is, of course badly typed... forgive me that joke, pity java programmer).
But what is a stronger typing? That is rather simple to explain, actually. We discussed that types are limitations of things to be able to only do some specific operations and such. These things are enforced by the compiler or interpreter of the programming language, of course. And stronger typing only says that the compiler has more information (implicitly via the definition of the programming language) to enforce these rules, the rules of “the function A is defined for type T, so you cannot call it on U”. Of course there is more to that because of generic typing and so on, but that's basically it.
The next term is “type inference”. Type inference is nothing a programmer experiences explicitely, because it happens implicitly. Type inference is a feature of the compiler and interpreter of the language to guess the type of a variable without the programmer stating the actual type. It's nothing more to that actually.
I mentioned the term “generic types” in one of the former paragraphs
already, so we should have a look there, too. Generic types, or shorter
Generics, are types which are partial, in a way. So for example, one
can define a Bag
of things, whatever things is. This is often (at
least in typed languages – languages where types actually matter for the
compiler or interpreter) specified in the code via “type parameters”
(though this term differs from language to language).
Why more types are better then few
The more types you introduce in your programs (internally or even for
the public API), the more safety you get (speaking in the context of a
stronger typed programming language, but also if you do a lot of
runtime-type-checking in a weaker typed language). That does not mean
that you should introduce a BlueCar
, a BlackCar
and a GreenCar
as
types in your program, but rather a type Color
and a type Car
whereas each Car
has a Color
– even if your domain is cars and not
colors.
Maybe that example lacks a certain expressiveness, so consider this:
Your Car
has wheels. You can set the number of wheels when
constructing the Car
object. But instead of passing an integer here,
which would yield an API where one can pass 17 as valid number for the
number of wheels – or 1337 or possibly even -1. But if you introduce a
type which represents the number of wheels, you get some safety into the
construction of the Car
object – safety checks in your code are not
necessary anymore and thus your code will be shorter, better focused on
what the actual problem is instead of fighting for valid values and of
course, the compiler or interpreter can do the work for you.
Sounds nice, doesn't it? You can get this all with (almost) no cost attached, you just have to write down some more types. If your programming language contains feature like enumerations, you do not even have to make validity checks anymore, as the compiler can execute them.
Next
In the next post we will focus on the coding environment.
tags: #open-source #programming #software #tools #rust