Why I vertically align my code(shkspr.mobi)
shkspr.mobi
Why I vertically align my code
https://shkspr.mobi/blog/2014/11/why-i-vertically-align-my-code-and-you-should-too/
28 comments
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.
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.
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.
I'm hooked on clang-format, personally.
https://mediacru.sh/1TeMS-nN5G_y
https://mediacru.sh/1TeMS-nN5G_y
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.
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 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).
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.
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.
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.
>Readability is a very worthy objective.
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"
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"
Books don't have syntax highlighting. Why does adding a bunch of whitespace to a line make it faster to read than syntax highlighting?
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.
That was my point – syntax highlighting is suited for code. whitespace for readability is more suited for books.
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.
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.
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.
If the version control you're using "loses its mind" due to vertical code alignment, you really need to use better version control.
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?
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?
You can tell the diff to ignore spacing with an option. It still ends up messing up stuff like git-blame and other stuff and isn't always worth it.
I don't believe this will save you from the merge conflicts.
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.
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.
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.
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".
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"
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:
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.
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.
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.
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.
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.
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)
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)
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
This is one thing that has always bothered me about the PEP style guide.
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.
Also, if you line up variables vertically, you should do the same with dictionary assignments, which is also a bad idea IMO.
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/
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.
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.
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
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;(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.
That said, I like the alignment of your first example. It depends heavily on the context of those variable, naturally.
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.
Variable organisation should therefore make horizontal reading easierat the cost of vertical reading.
This behaviour promotes scanning instead of reading. If you make assumptions that:
I also think if you have four temporary local variables:
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.
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.
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:
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"
> 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.
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.
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.
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.
Having to reread code when trying to accomplish something unrelated seems like a terrible way to seek out bugs.
Shouldn't it apply to everything, not just code?
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.
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.
The term "vertical align" confused me at first, as I assumed it meant the same thing that CSS does.
I do this too, but I don't try and enforce it on anybody. I really enjoy working alone.
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)
(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)
[deleted]
I wonder if there is Sublime Text plugin for this behaviour.
Code doesn't usually have numbers in it anyway.
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...
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.
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.
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.