This week, I'm recycling this really old post from my (mostly dead) blog...partially because I've been "heads down" on a ton of Veritonic stuff this past week and so I'm completely out of time...and partially because I feel like all of this still completely applies (and is worth repeating). So...
Yesterday on Twitter, I came across this tweet/question from Paul Ford
Tabs or spaces?
— Paul Ford (@ftrain)December 27, 2015
Which sparked this response from me:
@ftrain spaces all day and to the moon and back. 1st step in all code take overs projects, replace tabs with spaces (& prefer 2 over 4)
— Kevin Marshall (@falicon)December 27, 2015
And then mostly forgot about it because I thought it was a fairly obvious thing.
Spaces are the clear choice. Tabs are only good for one thing, keeping track of what you owe at the bar.
…but Twitter started alerting me to a number of likes, and so I decided to check out the larger conversation around the poll and was *shocked* to find out some people were actually voting for/defending tabs over spaces.
So clearly it’s not as cut-and-dry obvious as I had thought it was and I guess I should explain/defend my stance a bit more.
Tabs are a form of abstraction
My core argument boils down to the fact that tabs are just a form of abstraction (for spaces)…and I believe abstraction is only good when it clearly simplifies something.
Most developers seem to love abstractions (way too much in my book)…so I guess I shouldn’t be surprised about some people making the case for tabs, but let’s step back and think about it from the larger picture for a minute.
Here’s some hard truths from my personal experience:
1. The arguments that you can configure your editor to handle tabs properly is pure crap.
Yes, you can and should configure *your* dev. environment for what best fits you, but you don’t know what editor will be used to edit/manage your code going forward. So don’t force/assume editor configurations.
Code should be able to stand on it’s own outside of a given editor. You’re writing code to solve a problem, not to give your dev. environment something to do.
Assume your code will be viewed in any number of pure text editors including a basic NOTES program (and should still look right and make sense).
2. Abstraction makes it harder for beginners to understand what’s really going on.
Beginners may not notice tabs (they are often hidden characters; especially depending on the dev. environment someone is using).
Everyone should be writing code that makes it easy for others to stand on your shoulders; otherwise your code (and ultimately all your effort) is going to have a really short shelf life.
It shouldn’t be about showing off how smart or clever you are, but about how easy you make solving the problem for everyone that comes after you.
3. Tab key is non-standard key in many mobile keyboards (and hence a pain).
Those of you that are advocating for the use of a tab key have clearly never had to make a hot fix to a production bit of code via your mobile phone. It’s not an ideal situation, but it can (and does) happen…and when it does, you don’t want to waste brain cycles, minutes, and many curse words on dealing with tabs via your mobile interface. (and remember, like it or not, mobile is the way of the future)
4. If you work in a lot of different languages, and also do a decent amount of data parsing and formatting, you’ll see people use Tabs in all sorts of funky and unique ways.
You’ll spend a decent amount of time tracking down bugs that are directly related to an accidental or mis-placed tab…but you’ll almost never have the same troubles when dealing with spaces (improper spacing generally jumps out quicker and easier to devs. than tabs).
I promise you, this alone will have you cursing the idea of anyone using tabs for anything that they don’t HAVE to.
And while I’m on the soap box, I guess I should call out one more tidbit from the conversation that I can’t just let pass
If you’re a reg. reader/follower of mine, you’ll already know that my personal approach to all code is 1. make it work, 2. make it good, and then 3. make it fast…so you would think I’m all in on this tweet…but I actually think “make it work” on it’s own can be very dangerous. Here’s why:
1. “Make it work” is great for bootstrapping; prototyping; and mvps - especially when working on your own and trying to do something fast…but it’s also selfish and potential maint./scaling nightmare.
There’s a big difference between figuring it out, and releasing it.
“Make it work” as you’re figuring it out…but “do the right thing” when you release it.
Consider the afterlife of your code (and the sanity of those devs. who will follow and/or stand on your shoulders).
It’s often the boring and painstaking ‘work’ part of being a professional developer (and so it’s often skipped or at the very least skimped on)…but often the little things in life that make the biggest differences.
Take the time to do it right, and your code (and reputation) has an insanely higher chance of a long, and healthy, life.
2. Again, a development goal in all software should be to remove or limit abstraction as much as possible (especially abstractions that are just for the sake of abstractions; don’t be clever, be clear.)
Want to learn this the hard way? Build something with even a simple layer or two of abstraction, do NOT document it, and then let it sit for just six weeks without thinking about or touching it.
Now try to jump in and improve or tweak it. How long does it take you? How hard was it to figure out?
Now imagine if you weren’t the orig. dev and didn’t have that initial knowledge (a more real situation) and you can get a feel for how big a problem abstraction actually is.
Yes it’s powerful, and sometimes even required, but it also comes with great responsibility – use it sparingly and wisely.
3. Even if you are just thinking of your future self, it should always be your goal to make code as readable, reliable, and repeatable as possible.
If nothing else, you’ll save yourself a ton of “remember” time…and again you’ll make it crazy easy for others to stand on your shoulders and move on to the next problem/challenge (rather than refactoring and/or fixing your code).
BTW - this also means using blocks when/where possible (even when not required)…but that’s a larger rant I’ll save for another day.
And, also light because of my lack of time this week, just two links of interest to share this go around:
Much like paid search results, small companies and players are priced out very very quickly...everyone I know who has something listed on Amazon feels the "review" pain (and as far as I know they all play "fair")...but I don't think it's a problem most buyers are all that aware of (or care that much about -- I'm often guilty of it as a buyer too, just going with stuff that has a lot of reviews).
Interesting model to dig into - though I feel like the whole ICO and token economy is a bit over it's skis at the moment (I would be more focused on getting tokens to have REAL value before I would worry about ICO, token grants, or anything else).