Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

You are very cautious with me in not taking any offense; thank you (I won’t)! For me the aligning and the subsequent empty space which is created between the two columns allows very fast skimming in the values of -both- columns. I don’t have any isse in tracking horizontally. Any spreadsheet uses the same technique (aided by the cell lines).

I use this style also in expressions: often when coding graphics you have similar operations or variables and ordering it in “column fashion” allows quick skimming and error spotting.

Another (real) example:

  const neighbors =
      get(x - 1, y - 1, w, h, prev) +
      get(x,     y - 1, w, h, prev) +
      get(x + 1, y - 1, w, h, prev) +
      get(x - 1, y,     w, h, prev) +
      get(x + 1, y,     w, h, prev) +
      get(x - 1, y + 1, w, h, prev) +
      get(x,     y + 1, w, h, prev) +
      get(x + 1, y + 1, w, h, prev)


Yes, that is a great example of something that falls flat in a proportional font or without using column alignment.

My only suggestion is to be more generous with whitespace inside the parentheses:

  const neighbors =
      get( x - 1, y - 1, w, h, prev ) +
      get( x,     y - 1, w, h, prev ) +
      get( x + 1, y - 1, w, h, prev ) +
      get( x - 1, y,     w, h, prev ) +
      get( x + 1, y,     w, h, prev ) +
      get( x - 1, y + 1, w, h, prev ) +
      get( x,     y + 1, w, h, prev ) +
      get( x + 1, y + 1, w, h, prev )
I don't quite understand why, but most modern coding styles prohibit ever putting a space inside the parens. I think the common philosophy is to follow the same conventions you would when writing English prose. But we're not writing prose, we're writing code! To me it is more readable if we allow a little breathing room inside the parens.


I adopted this style for a while (I mostly code individual and personal projects so I’m not obliged to follow style-guides) but reverted back…

This looks better in monochrome text but usually the editor colors allow a fast distinction of the parentheses, variables and literals so the extra space is not needed for me.


As a digression, this is exactly the same issue that I have with autoformatters. For example, clang-format under default settings turns your example into:

    const neighbors = get(x - 1, y - 1, w, h, prev) + get(x, y - 1, w, h, prev) +
                      get(x + 1, y - 1, w, h, prev) + get(x - 1, y, w, h, prev) +
                      get(x + 1, y, w, h, prev) + get(x - 1, y + 1, w, h, prev) +
                      get(x, y + 1, w, h, prev) + get(x + 1, y + 1, w, h, prev)
In the past, I've resorted to things like adding no-op `+ 0` for alignment and empty comments to force it to preserve line breaks while still allowing it to autoformat the rest:

    const neighbors = get(x - 1, y - 1, w, h, prev) + //
                      get(x + 0, y - 1, w, h, prev) + //
                      get(x + 1, y - 1, w, h, prev) + //
                      get(x - 1, y + 0, w, h, prev) + //
                      get(x + 1, y + 0, w, h, prev) + //
                      get(x - 1, y + 1, w, h, prev) + //
                      get(x + 0, y + 1, w, h, prev) + //
                      get(x + 1, y + 1, w, h, prev)
I really wish that autoformatters had the smarts to understand that if more than X% of the non-whitespace columns within a block repeat the same character from top to bottom, then the lines are probably intentionally aligned that way and that it should try very hard to preserve that alignment. That would eliminate my one real objection to autoformatters. (Bonus points for detecting parallel structure in the code and exposing it through alignment in the first place, but that's a much harder generalization of the problem. I'd settle for just leaving that to me and then not destroying it.)




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: