Pegasus Gate

This is a statement that has been in my Twitter bio for a while now and over the years it has seen some minor variations, with the latest trying to be a little less inflammatory adding "kinda" and "if you think about it" - every now and then someone will ask and it seems to be something people do actually think about, and then still miss the point. Lets longform this thing in the true style of my rant driven development blog.

Let's start with the overview of the age-old flamewar on tabs v spaces. The surface arguments are generally "but mah alignment" (spaces people) and "but my character counts" (tabs people). 

Spaces people will tend to argue around working in terminals, knowing that when they linefit for 80 characters they can trust it will always fit on the terminal. Reason this is bad: working in terminals outside of an emergency is bad. That is an opinion that I hold to be self-evident. Another reason is "well that is just how it is before I got here" because instead of trying to make things better, it is yielded to the dude who got there first and planted their flag.

Tabs people will tend to also argue pointless things like, "well I don't have to hit spacespacespacespace" which nobody does anyway as spaces people are so anti-pattern that the editor will be set: 1 Tab = 4 Spaces. If I had my way, people who use spaces would be legally required to remove their Tab key. Another common argument is file size, moot in modern days, as well as parsing speed, also moot. 

All of these poorly paraphrased arguments above are bad. The real reason Tabs are superior to spaces is accessibility.

But how in the hell could something as simple as an ident be an Accessibility problem? And I am serious, it is a PROBLEM. Not everyone is as good at reading. Not everyone has the same visual acuity. Not everyone is as good at discerning logical blocks. I'm going to show you some code from that one most popular UUID library for PHP using different tab settings - not to flame it, but to show you code that I did not purposely craft to only look good my way.

Tabs allow the user to customize their editor to view the code with more structure to fit their needs. For example, consider the terrible practice of the fancy-ass Javascript devs who only indent using 2 spaces. 

[From stage left, sarcastically] First off what is wrong with you? Second, why do you hate everyone else and yourself?

Joking aside... this shit is literally impossible to read. It looks more like the indents are errors than intentional - and often, they are! It makes it so hard to see even for those intentionally doing it that messups often get committed without notice. Even in that screenshot above where I tried to make it clean, I messed it up there is an error in the tabbing on the closing brace of the catch block. I'm not just saying that I seriously tried to make it a flawless example, I only noticed after pasting my clipboard to the blog photo uploader.

Another thing to keep in mind most people don't seem to have all whitespace characters displayed like I do. Without these whitespace indicators my eyes cannot find any resting points to start reading the logical sub-blocks. It is literally required for me to turn these on to read code by people using spaces to grok their block intentions. Check that out with the helper guides disabled.

To my eyes there is no structure at all anymore. Just floating blobs of fuck. One might think, "this is fine, PHP's standard is 4 spaces". Other than PHP and JS often go hand in hand. But yeah, lets look at 4 spaces next.

Is this better than 2-spaces? 100% (technically, 200% tee hee). But why am I still not satisfied? First with spaces it is still really easy to get things misaligned. Just takes one errant space somewhere. But genuinely the actual reason is, this is still just too hard to read.

It really comes down to I need MORE SPACE... NOT MORE SPACES. If you look closely at this blog you may even notice that this text you are reading right now, I have increased the distance between each character as well as between each line just at little bit. More to the point though lets convert this code to straight tabs changing nothing else.

Two things happened here. First, nothing happened. It looks exactly the same to the 4-space person. That IntegerObject line is still crossing the 80 character margin just as it was when it was spaces, meaning it is just as broken as it was. The second thing that happened is the whitespace indicators. Rather than a cluster of spaces that must be parsed by the brain in multiples of 4 by people who might have gone to public school in the United States, people such as myself, it is now extremely clear where the logical sub-blocks are located and how they are related to their parents. Thusly: the helper indicators have leveled up their helpfulness.

But still I just need more space. This might seem stupid... but for day-to-day work I use a Tab width of 6. Only two more? How could that make any difference? Not everyone is as good at reading. Not everyone has the same visual acuity. Not everyone is as good at discerning logical blocks. 

It makes a world of difference to people that need it.

Finally at this point, on first first sight, from any distance from the screen, I can easily discern the logical sub-blocks with or without the helper indicators. Now both the eye AND mind have it very clear that the return new IntegerObject is a child operation of the try block. I finally see the intent of this code. And all I did was set my tab width to 6, a personal need that affects anyone else zero. You can keep yours set to 4 and continue on with life as if nothing has changed. Switching to tabs you lose nothing[1]... yet we lose everything when spaces are used.

[1] technically you lose filesize and parsing time. har har har.

And that is really that. I am not angry you are using spaces. I am angry that you know it helps people and continue to be malicious about it. "WHOA BOB, HOLD THE FUCK ON, I didn't actually know I was being mean!" No no, I believe you. This has been a life-long struggle and it often feels like after you've told everyone this 20 times and yet they still treat you like they hate you, that... just everyone hates you. All I ask is you look back to the shitty style guide from 1972 and think about it... why are we doing this? Because someone a long time ago said it was the best? And they couldn't have been wrong? It's not like humans have never done anything like write racist/sexist/ablest laws before.

Think about the people around you. If you're an open source library, the people around you span the entire globe! At the very least if you still decide to hang onto the spaces, be understanding about why us tabbers be tabbing.

I could make this code even better though. Like I said, I need space. If you've ever sat through any of my rants at the usergroup, or gone through any of my modern code you've seen this. I REALLY need space to the point I've developed an entire style guide around it, and this seems like a good place as any to describe why I do the things you may have seen me doing. It is all related to the accessibility factor. Here's how I would have formatted this code:

1) public function on its own line: the reasoning behind this is it turns the method keywords into a headline. This is a public function. And that is it. Additionally, with the name of the method on the following line, we've regained `public function` amount of characters back before hitting our right margin in the editor. Eye focus is still near the left margin to continue reading the method name below.

2) return type on its own line: PHP's syntax kind of sucks compared to real C. Again, this gives us back some line space before that right margin and also brings us to a really quick summary of what we see as we scroll without the left-right eye jumping. With a flick of the scroll wheel we have a pretty solid bearing on where in this class we are.

3) empty line between the opening of the method body and the logical content within. This makes our function header realllllly feel like a function header, with the function body really feeling like a body.

4) excess lines between control structures like try/catch. This amps up the clarity about where the code we are expecting exceptions ends, and where our attempts to catch them begin. I do the same things with if/else.

5) explicit return, all the way down there. It is not a hard rule, but I prefer to write functions that are structured such that they only contain a single return keyword. It is very clearly down there, giving the function a closing footer. An exception to this would be if the code was not using exceptions so much, but rather short-circuiting returns with false conditions.

I genuinely believe that code can be an expression in an artistic form. The visual aesthetics can play a huge role in conveying what your code is trying to do, and how it is trying to do it. By not spending the extra moment on formatting, you are losing a huge chunk of the tools at your disposal to convey meaning and intent. You also might just be making it excessively hard to read for anyone who isn't just like you.