Skip to main content

My Views on Code Indentation

I have read many, many articles about the whole tab vs. space indentation thing. Personally, I don't necessarily agree with most of them. They will require the coder to use a specific indentation size and stick with it, even forcing that on other coders.

First off, let me outline my method for indenting code. Then I will explain the reasons and advantages/disadvantages.

When I indent code, I will use tabs, but only at the beginning of a line. To align something in the rest of the line, I will use spaces. If a line spills to the next line(s), I will indent that line two tabs further.


Why tabs? First off, they're compact in the file (1 byte each). This is really insignificant with current disk sizes, but still. If you indent in spaces, then your file will be larger (unless you indent with one space).
Another advantage of tabs is that a tab is a tab. It doesn't specify by how many spaces the code is indented, but rather by how many tabs it is indented. That means if a coder likes 2-space indentation, they can set up their editor to display tabs as two spaces. Or 4 spaces, or even the crazy (?) Microsoft 8 space method. With tabs, you are not forcing your indentation style on other coders. Two different coders can view the same exact (byte-by-byte) file with 2, 3, 4, 8 (whatever, go nuts) spaces per tab.
One more advantage: the Tab key. Why would pressing a tab key insert spaces? There's a space bar for that. It makes logical sense that a Tab key would insert a tab.
One last advantage is that it's easier to delete the indentation. If your Tab key automatically inserts 4 spaces, then you need to hit Backspace 4 times to get rid of one press of the Tab key! At least for me, that's pretty inconvenient.

If something inside of the line needs to be aligned to make code more readable, spaces should be used instead. The reason? If it needs to be lined up, you need to specify exactly how many spaces are needed. That way, two editors with different tab sizes will still properly align the code inside of the line.
This isn't about forcing your indentation size on other coders, it's about making your code readable, which means your code has to be aligned exactly, regardless of how many spaces are specified as one tab.

Multi-line Lines
One logical line can occupy multiple physical (not in the literal sense) lines in the file. When that happens, the rest of the physical lines after the first should be indented two extra tabs in. Why? It's easy to see that that line is a continuation of the previous one. If it was one extra tab, it could get confused with a block of code that gets indented one tab in. Obviously if it was no extra tabs, it wouldn't be set apart in any way and you'd be stuck wondering how someone could miss so many semicolons! More than two doesn't make sense, as anything past two extra tabs will just shorten your available horizontal space without adding any more clarity to the code.
Some people I've seen like to indent their code up to a parenthesis or some other significant mark. With tabs, of course, that's not possible because of the varying tab sizes. What about spaces after the initial indentation with tabs? Wouldn't it be the same as aligning with spaces? That is a good point, and can be done when the significant marker is not very far in the line, but what happens when that parenthesis or whatever marker is far into the line? You end up limiting your horizontal space at the expense of making your code a little more organized. From here, it's a cost-benefit analysis. How much horizontal space would you be willing to give up for a certain amount of organization? In the end, I've found that indenting with two extra tabs gives enough clarity to the code without sacrificing a lot of horizontal space.

Sometimes, I feel that spending more time on this issue is just a waste, but I feel that there should be a single indentation style that coders can agree upon to make all their lives easier. Can you imagine if someones editor automatically replaced all the tabs in a file with spaces? In a revision control system, it would look like every single line changed!
That said, I'm sure that my method isn't the Holy Grail of indentation. Like all methods, it can be refined and worked on until most people agree with it.

Anyway, that was my two-cents about code indentation. Do you agree or disagree with it? Anything you would change? I would really like to hear some feedback about this.


Popular posts from this blog

Linux on XPS 15 9550/9560 with TB16 Dock [Update:3/29]

Finally got a laptop to replace my fat tower at work - Dell XPS 15 9560. I was allowed to choose which one I wanted and chose the XPS for its Linux support since Dell ships developer edition XPS's running Ubuntu so I figured Linux support would be better than other manufacturers. At first they got me the model with the 4K screen but my monitors are 2K and multi-dpi support in Linux is virtually non-existent and even hi-dpi support on its own is pretty terrible. So I got it exchanged for the model with the regular 1080p screen (which happened to also be the updated 9560 model), which works much better. I'm very glad to report that pretty much everything works, including the TB16 desktop dock, with just a bit of settings tweaking. This post is to help anybody considering getting this setup or looking for help getting things working. For now, I am running Kubuntu 16.04 with KDE Neon installed.

List of things I explicitly tested and work:
WiFi, BluetoothThunderbolt charging from T…

Drawing Dashed Lines on an HTML5 Canvas

The canvas element in HTML is great, but has one strange shortcoming: it cannot draw dashed lines (natively). However, dashed lines seem like a pretty common thing to draw, which only highlights the problem.

Looking around, I've noticed several solutions to this problem. Some use trig, and others use their own libraries that must be imported. So in the end, I decided to create my own method.

This code will add the function to all canvas elements, both those already on the page, and any that are dynamically added later.

Here is the code:
CanvasRenderingContext2D.prototype.dashedLine = function(x1, y1, x2, y2, dashLen) { if (dashLen == undefined) dashLen = 2; this.beginPath(); this.moveTo(x1, y1); var dX = x2 - x1; var dY = y2 - y1; var dashes = Math.floor(Math.sqrt(dX * dX + dY * dY) / dashLen); var dashX = dX / dashes; var dashY = dY / dashes; var q = 0; while (q++ < dashes) { x1 += dashX; y1 += dashY; this[q …

Listening for Window Resize events with Prototype

Recently, I came across an issue I had with full-screen (more specifically, full-viewport) canvas drawing. It all worked fine, except that the canvas dimensions must be specified in pixels, as opposed to percentages. This means you can't just set the canvas' width and height to "100%" and be done with it...

The dimensions were automatically set when the page loaded, but if the user resized the browser window after that, the canvas would stay the same size, and would be either too big or too small. Thus, the canvas must be resized every time the browser window is resized.

Prototype makes all of this easy. All that's necessary is to attach a listener to the onresize event of the window object, and then use document.viewport.getDimensions() to determine the new width and height.

Here's some sample code:

Event.observe(window, "resize", function() { var width = document.viewport.getWidth(); var height = document.viewport.getHeight(); var dims …