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.
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/). 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.
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.
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.
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.
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.
> 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).
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.
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.
Agreed, but its not the only objective. There is a balance to be struck. Speaking from the perspective of an individual that delivers software as part of a team:
producing readable/understandable code == GOOD
letting your aesthetic preference be disruptive == BAD
As an anecdote I have worked on teams where a certain individual's need for symmetry in the code base has significantly reduced the efficacy of source control and caused issues particularly with automated build/deployment.
When I criticize "readability" its not because I don't believe its important, but rather because its too often used to justify one individual's preference without regard to objective counter criteria and too often embodies "The perfect being the enemy of the good"
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.
Spreadsheets also do things like right-alignment or decimal alignment and mono-spaced integers, not because it adds any meaning beyond the grid, but because if something is off by a few orders of magnitude from the others, it will stand out.
The same can apply to code, and for things like matrix multiplication, alignment can be nice and help with some common classes of error. Say a unit test using a symmetric matrix, you might be able to spot that you fudged something much easier if things are aligned.
I don't normally tediously align everything, but sometimes it makes sense. Especially when your editor can do it for you.
> Spreadsheets also do things like right-alignment or decimal alignment and mono-spaced integers, not because it adds any meaning beyond the grid, but because if something is off by a few orders of magnitude from the others, it will stand out.
This may be a problem, but if I am working with values like this I am typically using a spreadsheet. I imagine this is more of an issue in simulations and/or scientific applications.
For general use code, epecially code being worked on by multiple people this a bear(specifically because of merge conflicts). I typically find the advocate to be the person that has the least team experience.
Is git/mercurial poor version control in your opinion? OP demonstrates exactly why. imagine a block with 25 variable assignments. All variable with 3 letters now you add a variable with 4 letters. You have to edit the 25 preceding lines with a space to accommodate the new letter. Now all diffs from here to eternity spew this out.
Not to mention you've now greatly increased the surface area for merge conflicts. I mean what if someone else added a 5 letter variable?
It won't. Source: does version control for a living.
The big problem with OP's point of view, IMO, is that you change the authorship of the lines when you line things up like that. If it is done from day 1, fine. Otherwise leave other people's code alone.
Why? Because unless you are using a system that makes blame slow (I'm looking at you, git), blame your goto helper for understanding the code's evolution. Our blame is essentially instant and I use it to debug problem reports while I'm on the phone with the customer all the time.
I'm all for good style guides and obeying them. But rewriting other people's code for you shiny new style hides a lot of useful history.
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.
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.
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".
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"
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.
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.
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.
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.
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)
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/
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 :)
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.
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?
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.
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:
> 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...) 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.
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?
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
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.
(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)
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.
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.
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.
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.