Comment by nsfyn55 | Hacker News Reader

Comment by nsfyn55 | Hacker News Reader

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.

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.

>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"

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.

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?

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.

Reply on news.ycombinator.com