Why I vertically align my code
shkspr.mobi
shkspr.mobi
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.
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 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 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).
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.
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?
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.
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.
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.
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"
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.
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.
My half-fix: make functional changes in one commit, formatting changes in another, with a simple comment, "formatting".
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"
int robert_age = 32;
int annalouise_age = 25;
int bob_age = 250;
int dorothy_age = 56;
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.
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.
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.
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.
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)
Also, if you line up variables vertically, you should do the same with dictionary assignments, which is also a bad idea IMO.
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/
is it more common to align the values left or right with decimal places?
eg
var foo = 1000;
var bar = 10;
var foo = 1000;
var longerName = 10;That said, I like the alignment of your first example. It depends heavily on the context of those variable, naturally.
Variable organisation should therefore make horizontal reading easierat the cost of vertical reading.
var totalBi11 = apply_tax(initia1Bi11, taxRate);
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;
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.
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"
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.
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.
Having to reread code when trying to accomplish something unrelated seems like a terrible way to seek out bugs.
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.
(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)
https://google-styleguide.googlecode.com/svn/trunk/javaguide...
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...
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.