Skip to content

When Static Types Mask Code Smells

Just knowing something should be a string or integer or object which conforms to XYZ interface doesn't necessarily tell you anything about what the code actually does or why.

By Jared White

In a Reddit thread, someone replied to a comment I wrote about some of the downsides of TypeScript and static types. They said:

Typescript doesn’t prevent all code smell. You can still write bad typed code. That is not the point of typescript.

Let me explain.

When you don’t have the benefits of static types, there’s a pressure to write and document your code in such a way that clarity is maximized. For example, here’s a JavaScript function which requires a string argument:

function trimMe(str) {
  return str.trim()
}

If you wrote this in TypeScript and you were being lazy, you could easily write this:

function trimMe(x: string) {
  return x.trim()
}

Static typing aside…what the hell is x?!

Obviously it’s still pretty clear when the function is tiny, but extrapolate that to much larger functions/methods/classes and across hundreds of files in a larger codebase.

Just knowing something should be a string or integer or object which conforms to XYZ interface doesn’t necessarily tell you anything about what the code actually does or why. Yet people routinely make the mistake of thinking that because they’ve added static types, they don’t need to go that extra mile of refactoring and documenting code to use better patterns and reduce code smells.


Listen, I’m not unequivocally advocating against static typing. I write TypeScript on a daily basis—as well as vanilla JavaScript and Ruby. I’ve “seen it all” as it were, and the thing is I’ve seen some pretty ugly code get passed off as acceptable because hey, it has static types. 😃👍 The mere presence of static types provides a false sense of quality which can really mask broader code smells if you aren’t careful.

There are patterns of producing code where I wouldn’t hesitate to pick the dynamically-typed solution over a statically-typed solution. Simply having static types does not automatically mean your code is better. Conversely, writing a dynamically-typed solution doesn’t automatically mean your code is simpler and easier to read—although sometimes, that’s indeed the case.

We as an industry need to stop thinking there’s a magic bullet that will magically make all code better. Static typing was once considered the way you must do things—until great dynamically-typed languages came along and challenged that. Now we see statically-typed languages challenging back. Wonderful! Every programmer and every project is different, with unique needs. We should celebrate a diversity of approaches and techniques—not expect the industry at large to fall in line with a single perspective.

Want to join a fabulous community of web developers learning how to use “vanilla” web specs like HTTP, HTML, CSS, JavaScript, & Web Components—plus no-nonsense libraries & tools which promote developer happiness and avoid vendor lock-in?

Join The Spicy Web Discord

It’s entirely free to get started. And we’ll soon be launching paid courses to take you even deeper down the rabbit hole, so stay tuned! Vanilla has never tasted so hot.