
Why I vertically align my code - edent
https://shkspr.mobi/blog/2014/11/why-i-vertically-align-my-code-and-you-should-too/
======
mb_72
I've been programming for a couple of decades commercially, and for three
decades overall, and I've found that whether you use or don't use a particular
code 'style' matters little for readability and maintenance purposes compared
to how well the source is architected and the system designed as a whole. The
eye and brain can 'deal' with a lot of different spacing and alignment
automatically; OTOH, working out how the code holds together, what data is
changed and when, etc, takes real processing power. I'm not worried about
expending tiny amounts of thought and processing energy, only lots of it.

In the general case, find a coding layout style that seems reasonable and go
with it; if you are working with others this will probably mean looking at the
established code base and extracting the important style elements. Time is
short; spend it on more important decisions about software structure rather
than deciding what bow tie it's wearing that particular day.

------
Animats
This should be handled by a code formatter, such as "go fmt". Go aligns
structure definitions that way. For C and C++, there's "artistic style"
([http://astyle.sourceforge.net/](http://astyle.sourceforge.net/)). For
maintenance purposes, it's useful to have all the modules aligned the same
way. Yes, somebody will whine about it being different than "their style".
Pick one and go with it for the whole project.

~~~
ArtB
Formatting -IMHO- depends on context. I have one convention I generally use
which is chaining methods together on one line, but when chaining together
builder method call I make one line per call. That means the semantics not the
syntactics of the code determine my formatting. For this reason I abhor auto
formatting code unless it is currently like an unrecoverable mess (ie NO
thoguht put into it, not just "not my style"). Honestly, put your curlies
wherever you like them, then don't effect readability as much as lacking
comments or convoluted flow.

~~~
Roboprog
Thank you - go fmt sucks. I hate K&R parameter layout, and I hate long lines
that scroll off to the right of the screen.

~~~
melling
Yes, but it's nice to save my code and have it formatted "the official way".
It gets old debating over which standard to use. Who cares what you like. Just
pick a standard for every language and get used to it. It's really not that
hard.

------
baddox
The appeal to needing better tooling is reasonable, but why should the results
of the tooling be hard-coded into the text file? I don't have a great answer,
but basically anything you want to do with the presentation of source code can
be done anywhere in the stack. Your editor could non-destructively display a
series of variable assignments with vertically aligned values like the author
prefers. And of course, on the author's side of the argument, git can show
diffs ignoring whitespace.

It seems like the best solution is for everyone on a project to agree to some
canonical representation to be hard-coded in the source files and versioned.
What that canonical representation actually is isn't super relevant, although
I would prefer something easy to read in plain uformatted mono space, for
places like GitHub where developers probably don't have presentational tooling
in place. What's important is that the canonical representation is agreed
upon. It could even be enforced by shared git hooks. Then each developer can
use their client side tooling to display the code in any presentation they
please.

------
hardwaresofton
I find that vertical aligning is great if all the lines (variable names) are
of similar length. If one is way longer than the others, then it actually gets
harder for your eyes to trace from one (short) variable name to it's value
(that is relatively far away because of the outlier), when the shorter ones
are all next to each other.

I don't think the solution to this problem is adding spaces to the files, I
think it's an IDE/text environment problem.

If you use a configurable text editor (you should be), then just download or
write whatever plugin will subtly highlight the line you're on.

~~~
akbar501
> I find that vertical aligning is great if all the lines (variable names) are
> of similar length.

I agree that when a few variable names are very long that it can actually make
readability worse.

I vertically aligned for about a year to see if it helped my code quality. In
the end, I found that reading a value right next to a variable was easier.

The other think I did was to vertically align related variables/values, and
put a blank line between unrelated vars so they had their own alignment.

In the end, I did not find any improvement in my code (just my personal
experience).

------
nsfyn55
Ah "readability" the favored haven of those with no clear objective criteria.

There is one clear justification OP can provide for this style element.
HE/SHE/THEY THINKS IT LOOKS PRETTIER! Just say so, call a spade a spade. If OP
is honest with themselves then they can seek help for their terrible editing
choices. Otherwise you just end up with the the tired cycle below.

1\. Trot out your aesthetic preference.

2\. Speciously connect it with something that has merit(e.g. lining up numeric
values in spreadsheet, which BTW has value because those numbers are in an nXn
space delimited grid where position implies meaning.)

3\. Use the 2 steps above to make a pitch for forcing everyone to use your
tool du jour or to shove this as a style guide element down your dev
team/projects/friend/significant other's throat.

From my experience this silly style element serves one purpose making that one
person with OCD feel better. For everyone else its a headache. It causes
source control to lose its mind, it makes block editing trickier, all while
simultaneously providing no tangible benefit.

~~~
drderidder
Readability is a very worthy objective. And alignment has been used since
before Gutenberg in text layout. Almost all code uses vertical alignment to
some degree, whether its indentation, aligning braces or what have you.
Aligning variable assignments in a grid is a natural extension particularly
where those variables are interdependent (ie. changing one value is likely to
require altering another in tandem) or where the variables are part of a
formula where quick scanning of the values aids comprehension.

So it has its uses. Personally, I use it where it makes sense, organizing
blocks of related variables together, and changing the alignment occasionally
as needed to accommodate longer variable names. It's not OCD at all, and I for
one find that developers who care about how their code looks end up producing
better, more successful projects. Well laid out and highly readable code is,
to me at least, one of the hallmarks of a truly skilled programmer.

~~~
robotkilla
Books don't have syntax highlighting. Why does adding a bunch of whitespace to
a line make it faster to read than syntax highlighting?

~~~
drderidder
Because syntax highlighting serves a completely separate purpose. Books that
contain collections of related data points frequently _do_ use a tabular
presentation. Syntax highlighting provides visual cues for the role that a
particular keyword plays in the language syntax.

~~~
robotkilla
That was my point – syntax highlighting is suited for code. whitespace for
readability is more suited for books.

------
shabble
Has anyone tried to store/diff/share code as ASTs, and allow each individual
user to apply formatting rules?

I guess (apart from the tooling effort involved) the problem would be that all
rules have some exceptions, which you'd need to track somewhere as metadata,
and that might scale with number of users.

I suppose it might also cause problems in pair programming / 'hey come look at
this' reviews if you have radically different formats for the same code, but
really, the only person who should care about your indenting style is you.

~~~
jloughry
_Has anyone tried to store /diff/share code as ASTs..._

This is such an interesting idea I had to respond. To point out that it could
go well beyond formatting, to variable and function names as well. With an
AST-aware editor, I could even have multiple "views" on the same code; e.g., a
crunched version with abbreviated names for a high-level view, personally
styled library calls, curried functions, all sorts of things.

It wouldn't require too much bookkeeping to track that sort of information
per-programmer. I think it's a fascinating idea. I haven't looked into the
implementation of syntax highlighting in current editors; I wonder if the
infrastructure is already part-way there.

------
scelerat
I like to format my code in ways that make it more readable, too. Vertical
alignment is one way. I'm familiar with the arguments against it, but it
always seems to come down to the limitations of source control tools.

My half-fix: make functional changes in one commit, formatting changes in
another, with a simple comment, "formatting".

~~~
nsfyn55
Firstly, this doesn't solve any problems. It actually adds another a
fragmented history.

Secondly, this is not a limitation of source control tools its a limitation of
formal logic.

Vertical alignment's benefits are absolutely minimal. What is the ROI? How
many bugs can be traced to "Lack of vertical alignment"? How many programmers
have uttered the phrase "That vertical alignment really saved my bacon on that
one"? Answer NONE! Its entirely aesthetic. I agree it looks nicer, but a Geo
Metro modded to look like a Ferrari isn't any faster because it "looks faster"

------
ufmace
I'm going to take issue with the given trivial example. So you've got this:

    
    
        int robert_age     = 32;
        int annalouise_age = 25;
        int bob_age        = 250;
        int dorothy_age    = 56;
    

And it's supposed to be easier to tell that bob_age is out of place because
all of the numbers are in a column. Technically, that's so, but I don't think
this is a good way to set things up in any modern programming language.

If you're defining as separate variables four different things, all of the
same type but all typed as individual variables of a basic type, then you
already have a problem, long before you decide how to align them. If they're
that similar that you can easily notice that kind of inconsistency, then those
numbers ought to be in some kind of data structure - an array, or they should
all be objects or something holding the name and the age. Exactly how to set
that up varies by the language and the problem domain, but I can't think of
any language where there isn't a better way to do it than that

Meanwhile, things that actually should be separate integer definitions like
that don't have any direct connection to each other, and so you can't
trivially tell that something is wrong by looking at a column of numbers.

------
Stratoscope
There's a point in the article where the author calls me and others "poor
condemned souls" who "argue for the eugenic purity of proportional fonts".

Obviously, I've never said such a thing, and at first I took some offense even
though it was just a bit of hyperbole.

I wrote a fairly harsh reply here and I'm taking the opportunity to edit it to
be a bit calmer.

Although I prefer proportional fonts, I've always been respectful of those who
prefer monospaced fonts. I recognize that most programmers use monospaced
fonts and I have no quarrel with that.

In fact, one of the explicit goals of my indentation and whitespace style is
to be equally readable in monospaced _and_ proportional fonts.

Life is full of tradeoffs, and here one of them becomes apparent. If you use
column aligned code, you give up readability in proportional fonts, and also,
as several others pointed out in these comments, you give up ease of editing
and diffing. And while the alignment makes vertical scanning easy, it makes
horizontal visual scanning more difficult.

Column alignment has a strong appeal nonetheless. I used column aligned styles
exclusively for probably 20 years or more. After all, my second language was
assembler! But about 15 years ago I experimented with using indentation only
without alignment, and I quickly found that the advantages of giving up
alignment outweighed its advantages for me and the people I worked with.

I've noticed that hardly any of the developers I work with today use column
alignment in their code, and they all use monospaced fonts. Now I'm curious to
ask them if they just never used alignment, or if they used to use it and
stopped as I did.

~~~
edent
As you can see from the article, I'm using dramatic hyperbole to demonstrate
that fanatical devotion to _either_ side is ridiculous. While I prefer
alignment, I have neither the inclination nor the power to force my personal
preferences on anyone.

I'm happy to remove the link to your comment, if you would like. I've no wish
to cause you distress.

I don't particularly care whether one uses proportional or monospace. Mind
you, I'm sure we can all agree that anyone using Comic Sans should report to a
re-education camp.

~~~
Stratoscope
Ha! Yes, perhaps we agree more than we realize, at least on _something_. :-)

Sorry I overreacted. Tell you what, leave the link and the hyperbole, no
offense taken. And I'm going to take the opportunity to edit my comment above
to be a bit less over the top in the response.

------
c3RlcGhlbnI_
If you have effective syntax highlighting the benefit in his trivial example
disappears. In cases like that you can quickly scan up a line of numbers
because they appear very different from the identifiers and it does not matter
if they are lined up.

Though such a solution has exactly the same edge case as vertical alignment:
when the identifier lengths are very different things get hard to read. In
which case it seems much more useful to be able to easily match identifier
with value, rather than be able to scan values.

This is just me taking issue with the trivial example though. Even though it
seems to be impossible to get a whole team to set up their formatters the
right way, vertical formatting is pretty much a must for tabular data like 2D
arrays.

(On a different note I am pretty sure that the kernel style guide is one of
the most controversial in widespread use. It works because it is very strictly
enforced. Not a good place to draw examples from)

------
robotkilla
This runs contrary to the final bullet point under Pet Peves in the style
guide for python.

[https://www.python.org/dev/peps/pep-0008#pet-
peeves](https://www.python.org/dev/peps/pep-0008#pet-peeves)

~~~
scelerat
This is one thing that has always bothered me about the PEP style guide.

~~~
robotkilla
From an OCD viewpoint, I agree. But with proper syntax highlighting you can
easily parse through variables and their assignments visually.

Also, if you line up variables vertically, you should do the same with
dictionary assignments, which is also a bad idea IMO.

------
userbinator
_I can easily see that everything there is an integer without having to slide
my eyes around._

Doesn't this contradict his point that:

 _Reading code isn 't much different from reading prose._

since we're already used to reading both horizontally and vertically? I'm not
saying that we should get rid of indentation and just write all code like
prose - in particular, nested structures are clearer with indentation to
denote the nesting level - but I definitely don't consider a series of
variable declarations and values to be columnar data that requires vertical
alignment.

 _If our tools make understanding those ideas more difficult, it 's the tools
which need to change - not us._

On the other hand, the use of more advanced tools, particularly by beginners,
tends to encourage a dependence on them and a more superficial "understanding"
of the code (I'll argue that the understanding has been shifted to
understanding the tool, and not what it works with.) Many of the most concise
and elegant solutions I've come up with were the result of deep thinking and
the use of pencil and paper, or a whiteboard, instead of an IDE or even a text
editor. I am reminded of this article which has the same opposing view:
[http://www.linusakesson.net/programming/syntaxhighlighting/](http://www.linusakesson.net/programming/syntaxhighlighting/)

------
jasonkostempski
I guess the argument makes sense if the data you're aligning is actually
tabular in nature, like a spreadsheet but in my experience, that's quite rare.
Even then wouldn't right aligned numbers look more natural? Aligning might
more often imply a relationship between data that isn't really there. I
personally don't think its worth the effort. If you do like it, make sure to
use spaces instead of tabs :)

------
army
I have a coworker who sometimes vertically aligns code. It's frustrating
having to edit his code because I have to choose between just making my
changes and ruining his vertical alignment, or having to spend time realigning
things. It's not a part of our coding standard.

~~~
kwhitefoot
Do you mean that it is contrary to your coding standard or merely not
required. If it is contrary to the standard then he should stop doing it.

------
glxybstr
The author kinda contradicts himself by saying you should vertically align
your code, but then says use proportional fonts if you find them more
readable. (Not to mention, proportional fonts don't allow you to vertically
align things well)

is it more common to align the values left or right with decimal places?

eg

    
    
      var foo =  1000;
      var bar =    10;
    

vs

    
    
      var foo        = 1000;
      var longerName = 10;

~~~
edent
(Author here) You're right, it _is_ contradictory. We'll never reach a perfect
blend of universal readability an personal preference.

That said, I like the alignment of your first example. It depends heavily on
the context of those variable, naturally.

------
AndrewDucker
I very rarely need to compare variable values to each other in a vertical
list. I frequently need to read what the values of individual variables are.

Variable organisation should therefore make horizontal reading easierat the
cost of vertical reading.

------
geocar
This behaviour promotes scanning instead of reading. If you make assumptions
that:

    
    
        var totalBi11 = apply_tax(initia1Bi11, taxRate);
    

actually does what it says, you might miss something obvious.

I also think if you have four temporary local variables:

    
    
        int robert_age     = 32;
        int annalouise_age = 25;
        int bob_age        = 250;
        int dorothy_age    = 56;
    

then you're missing a trick for a better data structure.

If you never _have_ a bunch of local variables, then you'll never need
vertical alignment. I think it would be a lot easier to have a discussion
about this with a less contrived example.

~~~
wsidell
Why are you arguing against clear code that tells what you are doing? Imagine
if you used a library with a function called sortAlphabetically that didn't
sort items alphabetically, it wouldn't make sense.

Regarding the alignment, there will be situations where there will be multiple
similar lines of code that would benefit from being blocked together with
vertical alignment. Not only in the case of temporary local variables. Imagine
a situation where a bunch of constants for an API are defined as such:

    
    
      #define kURLAPIBase      @"http://google.com"
    
      #define kURLAPIGetUser   @"/getUser"
    
      #define kURLAPIGetPosts  @"/getPosts"
    

There are numerous possible situations where things like this can occur. You
seem to be arguing for the sake of argument here.

~~~
geocar
> Imagine if you used a library with a function called sortAlphabetically that
> didn't sort items alphabetically, it wouldn't make sense.

And imagine if it used
[binarySearch]([http://googleresearch.blogspot.co.uk/2006/06/extra-extra-
rea...](http://googleresearch.blogspot.co.uk/2006/06/extra-extra-read-all-
about-it-nearly.html)) as part of it's implementation? Then
`sortAlphabetically` would be broken, and people might waste a lot of energy
looking _everywhere else_ instead of just looking at the data and _reading the
code_.

> Imagine a situation where a bunch of constants for an API are defined as
> such:

Are really all of those definitions helpful?

If I want to search for `/getUser` in a program, I might do `grep -r getUser
.` and then learn that I need to _repeat that_ with `grep -r kURLAPIGetUser .`
-- was that really better?

If `/getUser` is being used in more than one place, then maybe we should talk
about that problem of duplicating effort. If it isn't, then the define is
absolutely worthless.

~~~
Dylan16807
This is such a subtle problem that countless people implementing binary
searches didn't think about it, yet you think reading an unlabeled blob of
code will make people notice?

~~~
geocar
Yes, I think if programmers do not actually read code, they will not notice
the bugs in it.

Considering the binary search more deeply,
[http://comjnl.oxfordjournals.org/content/26/2/154.full.pdf](http://comjnl.oxfordjournals.org/content/26/2/154.full.pdf)
is useful; De Angelos search (family 4) was a successful search, but it
contains this bug. Implementations based on families 1 and 2 but perhaps
trying to be less clever would not.

~~~
Dylan16807
That's not what I asked. Do you think they _will_ find the bugs just because
of rereading a standard algorithm?

Having to reread code when trying to accomplish something unrelated seems like
a terrible way to seek out bugs.

------
zzzcpan
Shouldn't it apply to everything, not just code?

------
jdhawk
would a "pre-commit" whitespace condenser + "checkout" configurable code
formatter be the best of both worlds?

Write it how you want it - commit a whitespace condensed version, have a
formatter re-space it based on you're personal preferences/template?

I guess it would work for non-indent critical languages.

------
sarciszewski
The term "vertical align" confused me at first, as I assumed it meant the same
thing that CSS does.

------
FigBug
I do this too, but I don't try and enforce it on anybody. I really enjoy
working alone.

------
oneeyedpigeon
Why you shouldn't: commit noise.

(NB I'm just giving one reason against, I'm not really advocating against this
practise overall. I do it myself, to some extent, but I tend to find it pretty
hard to be consistent, which is quite a personal failing! There always seem to
be far too many edge cases)

------
albertoleal
I wonder if there is Sublime Text plugin for this behaviour.

~~~
iisbum
[http://wbond.net/sublime_packages/alignment](http://wbond.net/sublime_packages/alignment)

------
ajuc
Code doesn't usually have numbers in it anyway.

------
namarkiv
M-x align-regexp

~~~
jasonm23
Now consider the poor souls who use Notepad++ ... ;)

------
DonHopkins
The correct term is "horizontal alignment", not "vertical alignment". It's
impossible to vertically align code unless you're using a two-dimensional
visual programming language.

[https://google-
styleguide.googlecode.com/svn/trunk/javaguide...](https://google-
styleguide.googlecode.com/svn/trunk/javaguide.html#s4.6.3-horizontal-
alignment)

Google Java Style

4.6.3 Horizontal alignment: never required

Terminology Note: Horizontal alignment is the practice of adding a variable
number of additional spaces in your code with the goal of making certain
tokens appear directly below certain other tokens on previous lines.

This practice is permitted, but is never required by Google Style. It is not
even required to maintain horizontal alignment in places where it was already
used.

Here is an example without alignment, then using alignment:

private int x; // this is fine private Color color; // this too

private int x; // permitted, but future edits private Color color; // may
leave it unaligned

Tip: Alignment can aid readability, but it creates problems for future
maintenance. Consider a future change that needs to touch just one line. This
change may leave the formerly-pleasing formatting mangled, and that is
allowed. More often it prompts the coder (perhaps you) to adjust whitespace on
nearby lines as well, possibly triggering a cascading series of reformattings.
That one-line change now has a "blast radius." This can at worst result in
pointless busywork, but at best it still corrupts version history information,
slows down reviewers and exacerbates merge conflicts.

[https://developer.mozilla.org/en-US/docs/Web/CSS/vertical-
al...](https://developer.mozilla.org/en-US/docs/Web/CSS/vertical-align)

The vertical-align CSS property specifies the vertical alignment of an inline
or table-cell box.

Values (for inline elements)

Most of the values vertically align the element relative to its parent
element:

baseline: Aligns the baseline of the element with the baseline of its parent.
The baseline of some replaced elements, like <textarea> is not specified by
the HTML specification, meaning that their behavior with this keyword may
change from one browser to the other.

sub: Aligns the baseline of the element with the subscript-baseline of its
parent.

super: Aligns the baseline of the element with the superscript-baseline of its
parent.

text-top: Aligns the top of the element with the top of the parent element's
font.

text-bottom: Aligns the bottom of the element with the bottom of the parent
element's font.

middle: Aligns the middle of the element with the middle of lowercase letters
in the parent.

<length>: Aligns the baseline of the element at the given length above the
baseline of its parent.

<percentage>: Like <length> values, with the percentage being a percent of the
line-height property. (Negative values are allowed for <length> and
<percentage>.)

The following two values vertically align the element relative to the entire
line rather than relative to its parent:

top: Align the top of the element and its descendants with the top of the
entire line.

bottom: Align the bottom of the element and its descendants with the bottom of
the entire line. For elements that do not have a baseline, the bottom margin
edge is used instead.

