Hacker News Reader

Comment by g1236627 | Hacker News Reader

I agree with everything except abbreviations, but to be honest, I think my worst habit it just trying to use words with the same number of characters for different variables so they align well with monospace font.

e.g.

    int num = 42;
    int acc = 0;

instead of;

    int n = 42;
    int acc = 0;

and it gets worse when things get complicated;

    vector<int> dist;  // stands for distances
    vector<int> excs;  // stands for excesses

Does anyone else have this problem?

View on HN

I solve that problem by programming in a proportional font, which removes the temptation. (I know some people program in a monospaced font for various reasons, but in my opinion, anything that needs a monospaced font is a bad idea in the long run anyway.)

    int n   = 42;
    int acc = 0;

Fixed

Edit: Install http://wbond.net/sublime_packages/alignment and add this key binding `{ "keys": ["ctrl+shift+a"], "command": "alignment" }`.

Which, when you add a third variable "stuff", will require you to go back and add a space for both n and acc, pollutting both the diffs themselves (making reviews harder) and the git-blame (making pinpointing bugs harder).

There is a plugin in sublime text that I just select the lines and hit ctrl+shift+a and alignes everything in one hit.

The way you realign your variables is inconsequential to the pain it causes your teammates (and potentially yourself) come time to look at the diff.

And yes, I know about git diff -w, but 1. not all tools built around git support it and 2. not everybody uses git.

That there is a plug-in that makes it easy does not make it right. If you're working just by yourself you can do whatever you want but teamwork takes a slightly different attitude when it comes to reformatting. It's all too easy to get into a whitespace war with someone else (and you'll both look so productive!). A good team member will change what is needed and will separate cosmetic changes and functional changes by placing them in different commits and will apply the style guide while doing so.

Tracking bugs through changesets is hard enough, no need to make it harder on purpose.

    git diff -w

Yes, git diff -w is possible but it is not (unfortunately) the default (though I can see good reasons why it isn't).

Also, note that you can do the same in github:

Append ?w=1 to the url for the diff viewer and you'll get the whitespace ignored version.

Is there a git blame -w?

Yes.

That's actually right against the style guideline of many projects which tell you explicitly not to do this but to simply put the = sign and value right after the variable name and be done with it. Lining them up serves no purpose and does not in fact make the code easier to read.

To be honest it actually makes code cleaner and therefore easier to read. It's like design have you heard about grid? this is the same thing. Your eyes have to flow the lines. If not everything seems a mess.

Ask your revision control system what it thinks about that and your teammates when you submit a 500 line diff for review when a 10 liner would suffice. That's only marginally better than someone checking in a diff when their editor converted tabs to spaces or vv.

Whitespace edits are the code equivalence of wikipedia formatting changes to increase the number of articles you've worked on without actually contributing anything.

Also, if you think that is easier to read you are actually setting yourself up by being deceived by formatting because you'll be skipping bits based on assuming you know what they say. Those are hard lessons to learn but the best way to understand a new piece of code that you're reading is not to read it like a book but like a machine, with a pencil and a notepad tracing the values of the variables as you execute the code in your head (or on the paper if it gets complex). You don't need to run the whole program that way, just the sections that you feel are hard to understand.

I vote for harder to read (and write), except when the variables are so tightly coupled that they should probably be in an array or other structure anyway.

But ideally this is something that should be decided by each developer's personal editor config, like tab widths for indentation.

> To be honest it actually makes code cleaner and therefore easier to read.

It does not logically follow from the code being "cleaner" that it is easier to read. Having to scan across a field of whitespace to get to the number makes it harder to read and easier to make mistakes. Having the indentation of the number be unrelated to the length of the variable name adds another aspect that makes it harder to read and easier to make mistakes.

It's also harder to edit, which makes you do fewer edits that make the code materially better.

It depends on context. For example, here is a function from a project I'm working on:

    parseModifier : String -> Outcome Modifier
    parseModifier s = case s of
      "shift"   -> Ok Shift
      "ctrl"    -> Ok Ctrl
      "alt"     -> Ok Alt
      "meta"    -> Ok Meta
      "command" -> Ok Meta
      "windows" -> Ok Meta
      x         -> Err <| "Unknown modifier: " ++ x

I find it easier to read as is rather than if I dropped the alignment:

    parseModifier : String -> Outcome Modifier
    parseModifier s = case s of
      "shift" -> Ok Shift
      "ctrl" -> Ok Ctrl
      "alt" -> Ok Alt
      "meta" -> Ok Meta
      "command" -> Ok Meta
      "windows" -> Ok Meta
      x -> Err <| "Unknown modifier: " ++ x

As developers we spend more time reading code than editing it. Optimizing for readability seems like a better goal than optimizing for edit speed. Besides, most editors have functionality to align code. When I am looking over a file, the second example looks like a jumble of words to me, while the aligned version seems easier to parse (ha).

I agree that unaligned switches/pattern matches are bad (and in fact, there is an utility for OCaml which will nicely indent your pattern matches).

O'RLY? Does your style guide suggest lining up comments? Why? Does your email app separate things into columns? Do you think it would be more readable if it didn't? How about your bank statement, spreadsheets?

And in fact if there are great differences in the length of the names it makes it harder to read as scanning across and maintaining the correct line becomes more difficult.

You will find, if you spend the effort to look, that different people process information completely differently.

To someone who views this as a table, the above is so much more readable that it doesn't even bear thinking about. To someone who reads code the way a computer parses it (as I do), the added space can completely throw them for a loop. What the hell are you doing with n? Oh, if I look far enough, there is an assignment there.

Very likely you will see what I've written and find it incomprehensible because you have never looked at an expression the way I do. What's worse is that there isn't just 2 ways to look at it. Coding style purists usually don't realize that they are simply fooling themselves into thinking that their way of looking at something is optimal for everyone.

As someone else mentioned, the day when we can express how we want our code formatted and our editors will instantly format it that way (for everyone) can't come soon enough. But until then, it would be best to simply realize that there is no "best" way and that you should go with what the majority of the team likes, no matter what you personal preference is.

I'm curious, would you prefer your favorite music player list things like this

    Madonna, Rain, 3:45
    Lady Gaga, Bad Romance, 4:17
    U2, In God's Country, 3:57
    LCD Soundsystem, I Can Change, 6:31

    Madonna          Rain              3:45
    Lady Gaga        Bad Romance       4:17
    U2               In God's Country  3:57
    LCD Soundsystem  I Can Change      6:31

I'm not questioning that you find columnized code hard to read I'm just wondering would that apply to all forms of info? Your email list with time, name, subject. Your bank statement with data, biller, amount?

If not any idea why tables work for you sometimes and not others?

Tables require sequences of structurally isomorphic operations. Columnized code can work very well for matrix calculations, for example.

But most code that has structural isomorphism should be replaced by a loop or a function composition; repeated structural isomorphism is a redundancy that can be eliminated.

Aligning the initialization of a bunch of unrelated variables is a bit of a mixed case. Sequences of initialization are much more common in older languages, like C, that don't permit delaying the declaration. I don't have a strong opinion either way. If the data being initialized is structural, a tabular format should definitely be used, if it isn't fighting the tool (some IDEs etc. autoformat, or lint complains on unnecessary whitespace). If data is not structural and the variables aren't strongly related to one another, I don't see a good argument in favour of alignment, particularly when variable names can have wildly different lengths, e.g.:

    source                            = 10;
    timeout                           = 20;
    wait_count                        = 30;
    ch                                = 0;
    accumulator                       = 40;
    access_denied_retry_callback_list = [];

I find this substantially harder to read (see name to value and vice versa) than non-tabulated initialization.

    source = 10;
    timeout = 20;
    wait_count = 30;
    ch = 0;
    accumulator = 40;
    access_denied_retry_callback_list = [];

To be fair, the readability problem can be solved like this:

    source      = 10;
    timeout     = 20;
    wait_count  = 30;
    ch          = 0;
    accumulator = 40;
    
    access_denied_retry_callback_list = [];

(Still, it's not tabular data, so it has no business being a table.)

I'm not the parent, but as someone who also doesn't prefer aligning variable initialisers I can say the reason is that declaring variables and initialising them is not something I see as being tabular --- they're just a sequence of statements, and I wouldn't align them just like I wouldn't do this with a series of function calls:

    foo        (5, 7);
    barbar        (j);
    do_stuff(6, 1, 7);

or this with flow control statements:

    if   (x == y) {
      ...
    }
    for  (...) {
      ...
    }
    while(...) {
      ...
    }

Things like array initialisers, however, I do align.

    int n[16] = {
      15, 17, 22, 38,203,155,  7, 10,
     255, 11, 44,  1,  0,  0,  5,227
    };

To someone who reads code the way a computer parses it (as I do), the added space can completely throw them for a loop.

Actually, if you were really reading "the way a computer parses it", you'd ignore whitespace completely.

> Actually, if you were really reading "the way a computer parses it", you'd ignore whitespace completely.

I write a lot of coffeescript ;-)

Joking aside, on my current project we elide the parentheses when making function calls with arguments. So:

    myfunc(foo)

    myfunc (foo) ->

is an important difference when I'm reading the code. If you write:

    myfunc       (foo) ->

it means the same thing, but it completely throws me for a loop because I have to look ahead too far. So you are right, I don't look at it the way the interpreter does. I'm inferior and can only handle a grammar with a single look ahead ;-)

That's actual tabular data though. The variables `n` and `acc` are not the same type of thing; they don't belong in the same table. (Unless you were making a table called "local variables", but that is already obvious or redundant.)

I think both practices are pathological. The GP is restricting all variable names to an arbitrary length that will likely obscure meaning. The parent is arbitrarily determining line length based on whichever variable is longer; he may also be mixing in the GP's arbitrary var length rule in order to get a visually pleasing line in the local context.

Prose is obviously different, but it's probably worth considering that the only consideration for the length of a paragraph is the rules of paragraph writing, and not at all the physical length of words and sentences.

And then there's refactoring and renaming, and what that does to your artfully placed characters.

Figure out your placement and spacing rules (or better, use a canned set of rules), use them, and think about other things.

The point is less about aesthetics for their own sake and more about readability; the LHS and RHS end up being readable as if they were columns, which leaves less work for the brains of coworkers or future selves to perform when trying to mentally parse it.

In the past I've wanted a tool like that, but now I've come around to the idea that I want an editor that will display the code the way I'm used to however it's formatted. Lining up the equals signs would be a good candidate for an display formatting plugin. One the other hand when I've raised that idea with programmer friends of mine you can see the hair stand up on the back of their necks. People seem to really hate the idea that the editor might show you seaMonkey(do) instead of sea_monkey(do)

The way I think of abbreviations is this: if you would use the abbreviation when describing the code in plain English to another developer, then they are fine. Otherwise, don't abbreviate. Trying to make everything the same number of letters has very little utility, especially if you are giving up readability. Your also bound to run into naming collisions. Is rec record or receive? Is acc accumulate or accessor? Even if you can't touch type, there are a ton of editor with autocompletion.

The whole point of coding style is that someone else will have to read and maintain your code. If you step away from your code for even a month, it's almost like reading someone else's code when you come back to it. If you're writing code that will never be seen again, and simply has to work once, you don't need any style whatsoever. But that's not very common.

I think the biggest motivator is having to debug/port someone else's code full of magic numbers, short variables, long functions, global variables, and no comments.

> my worst habit it just trying to use words with the same number of characters for different variables so they align

Yes, you have worse problems than ambiguous abbreviations :) That doesn't make the abbreviations okay, though.

I try to use full word, except for loop variable.

Not every shorten the same word the same way, not even yourself next year.

I try to pick words with different lengths. They're more visually distinguishable.

And try to pick words that are lexicographically distant from each other to minimize the chance of single letter typos changing the meaning of the code.

Of course it's a tiny matter of terminology, but you probably mean Hamming distant, not lexicographically distant. `zaaaaa` is lexicographically farther from `aaaaaa` than is `bbbbbb`, but Hamming closer.

Reply on news.ycombinator.com