My Code Might Be Terrible

by Stephen Fluin

2017-12-31

My Code Might Be Terrible
Sometimes I write bad code.
Okay, let's be honest, I always write bad code. I want to tell you about some of the terrible decisions I make, why I know they are wrong, and why I still do them.

  1. I would like to use tabs but I use spaces

Let me start off defending myself by saying that in any codebase I work in, I ALWAYS adhere to the standards and practices of that codebase. Choosing things like tabs vs spaces is in many ways a religious war, and the top priority should be moving the focus past these minor concerns and towards focusing on actual functionality.
When developing day to day, I use spaces. If pressed on the reason why, it would probably be because I've watched Silicon Valley showing the prejudice against tab/space diversity, and I've read posts from Stack Overflow that say developers make more when they use spaces and I've seen reports from GitHub that there is more code that uses spaces than tabs.
But, I don't just use spaces, I use 4 spaces! I find that the extra spacing compared to 2 emphasizes the separation between the various levels that code operates in. Especially when using languages like JavaScript, seeing which calls are asynchronous or the context of a call is extremely helpful in understanding what the program is trying to do.
When combined with a good line limit (around 120 for me), I find that 4 spaces means that I also don't nest my code as deeply as I might have with 2 spaces, increasing overall code quality.

But what about tabs?

Did you know that there's a special character that can be used by developers to semantically indicate the number of levels of depth for a piece of code? It's called \t or the tab character. I love the tab character because it theoretically gives editors the ability to interpret the character in different ways, such as showing a visual spacing equivalent to 2 or 4 spaces (or anything else) as the consumer of code gets to choose.
I know it messes up things like "perfectly formatted blocks of visual information", but in general I think most of us agree that you shouldn't have those, and theoretically you could use spaces.
I think if there was broader acceptance and if more IDEs used tabs as a default, I'd probably use tabs more.
Did you know? Did you know that most developers who want spaces in their code still use the tab key on their keyboard to get them? Ludicrous!

  1. I Often Don't Build Automated Tests

Automated Test in the form of Unit Test and End to End or Integration Test are critical to building a codebase that is maintainable and can survive and adapt over time.
Most of the code I write is small enough to be built and maintained by a single person, or designed to be short lived, so it doesn't have tests. Tests are hugely valuable, but the types of projects I build get more value from innovation and for being able to quickly (and dangerously) refactor than the value created by tests.
It could also be that I was never required to write tests early in my career, and so I'm just bad at it.

  1. I start with Bash scripts and end with ts-node scripts

I never know how long the devops / server management code I write is going to live, but server code always lives longer than you think it will.
This often results in my bash scripts going through a super predictable path.
  1. First, write a 3 line bash script
  2. Then, write 30 more lines of bash
  3. Then, rewrite the script into JavaScript for node
  4. Finally, rewrite the script into TypeScript with ts-node

Theoretically I could skip this cycle and just write TypeScript from day one, but that would require me to whip up a tsconfig.json file and look up the format, and install extra tools on the server when "all I want to do it one thing".