5 ms·

> For example, it cured the bad habit I had of lining too many things up in columns I don't like this style either, but it's a style not a "bad habit."

Stratoscope 9y ago
> I don't like this style either, but it's a style not a "bad habit." Point well taken. But this was just a personal observation. If other people use column alignment, it would certainly be presumptuous of me to call it a "bad habit"! For me, though, it was just that. I had no real reason for it other than having always done that way, and it was really starting to get in the way. So I was glad to be done with it.
marcosdumay 9y ago
It's a decision with a lot of downsides. Each one not very significative, like polluting diffs, that add into a mild nuisance.
Avshalom 9y ago
nah, it's a bad habit. It means constant readjustment and unnecessarily bloated diffs every time you change a function or variable name. or the lovely foo := a; bar := b; then a day later foo := a; bar := b; foobar := cd; which also points to the problem that it lends itself to premature constant readjustment because a day later you have to move every thing again because as it turns out you really needed foobarlist as well. and each time you end up with a diff reporting that foo and bar (and then foobar) have changed too. It's making busy work for yourself and ruining the usefulness of code review tools. ALSO alignment vs indentation is the whole reason we have to have the spaces vs tabs argument.
- Stratoscope 9y ago
  > alignment vs indentation is the whole reason we have to have the spaces vs tabs argument. Indeed, that is one of the things I like about the indentation-only style. Unlike column alignment, you can use either spaces or tabs for indentation and the formatting still comes out fine.
- problems 9y ago
  One interesting talk I watched recently: https://channel9.msdn.com/Events/GoingNative/2013/The-Care-and-Feeding-of-C-s-Dragons https://channel9.msdn.com/Events/GoingNative/2013/The-Care-a... In it, they make a really good argument that humans simply shouldn't be doing this type of formatting work. Let the computers do it, clang-format can get it right every time in a fraction of the time a human can. Pick whatever style you want, let the computers deal with it. I quite like this, now I just write a big long single line, hit a button and have it fixed for me. It's not a bad habit if it looks better and doesn't involve any time investment.
  - arantius 9y ago
    I've seen plenty of suboptimal code in review, commented about what I consider a better/more readable version to be, and gotten the response "this is what the clang formatter produces". Boo to automatic formatting. It produces the worst lowest-common-denomninator version of code.
- Arnavion 9y ago
  >It means constant readjustment and unnecessarily bloated diffs every time you change a function or variable name. Your variable example is the thing that peeves me most about golang, since gofmt insists on aligning consecutive variable names and types in that columnar fashion.
  - Stratoscope 9y ago
    What's really puzzling about that gofmt decision is that Rob Pike and other Go core team members are known to code in proportional fonts! https://news.ycombinator.com/item?id=10416364 https://news.ycombinator.com/item?id=10416364
- 21 9y ago
  The diff could be smarter and notice that you just inserted some white space. Many GUI apps actually do that but unfortunately not your typical diff or git which insist in dealing with full lines only.
  - harrisi 9y ago
    I'm sure many know, but for those who don't, `diff` (and `git diff`) accept -w and -b to ignore all white space and changes in the amount of white space, respectively. I find these very handy. Somewhat related, if you're looking at a diff on GitHub and want to ignore whitespace, you can just tack on `?w=1` to the URL (https://github.com/blog/967-github-secrets https://github.com/blog/967-github-secrets).
    - ghusbands 9y ago
      Though you still end up committing whitespace changes that can then cause unexpected conflicts, later.
    - mtm 9y ago
      For github I crafted together this little bookmarklet to ignore whitespace on diffs (use it daily for our code reviews): javascript:(function()%7Bopen(location.href+'?w=1');%7D)();void(0);
- kpil 9y ago
  Here is a thought. Maybe no formatting characters should be allowed to be saved embedded in source code, and instead presentation filters should handle everything related to formatting, documentation, etc. It might work..
  - hobo_mark 9y ago
    Git supports custom "clean/smudge" filters on push and pull exactly for this sort of things. Unfortunately neither github not gitlab consider them so your online diffs would look like a mess of you did that.
  - CapacitorSet 9y ago
    It looks interesting, but then one would have to define a normalization for the AST - either something like an XML printout of the AST, or a standard formatting for source code (perhaps whitespace-only minification?). It would also pose an issue when presenting code in "dumb" media (eg. a txt file).
- shagie 9y ago
  Alas, if only tabs realized columns could occur in locations other than 8 or 4 space tab stops. http://nickgravgaard.com/elastic-tabstops/ http://nickgravgaard.com/elastic-tabstops/
- deleted 9y ago
  [deleted]
- tenken 9y ago
  It's a non problem. Use a code formatter prior to code commit. If needed allow your editor to have a task to reformat a code file on Open to apply formatting you desire vs the teams or project guidelines.

Stratoscope 9y ago

> I don't like this style either, but it's a style not a "bad habit." Point well taken. But this was just a personal observation. If other people use column alignment, it would certainly be presumptuous of me to call it a "bad habit"! For me, though, it was just that. I had no real reason for it other than having always done that way, and it was really starting to get in the way. So I was glad to be done with it.

marcosdumay 9y ago

It's a decision with a lot of downsides. Each one not very significative, like polluting diffs, that add into a mild nuisance.

Avshalom 9y ago

nah, it's a bad habit. It means constant readjustment and unnecessarily bloated diffs every time you change a function or variable name. or the lovely foo := a; bar := b; then a day later foo := a; bar := b; foobar := cd; which also points to the problem that it lends itself to premature constant readjustment because a day later you have to move every thing again because as it turns out you really needed foobarlist as well. and each time you end up with a diff reporting that foo and bar (and then foobar) have changed too. It's making busy work for yourself and ruining the usefulness of code review tools. ALSO alignment vs indentation is the whole reason we have to have the spaces vs tabs argument.

Stratoscope 9y ago
> alignment vs indentation is the whole reason we have to have the spaces vs tabs argument. Indeed, that is one of the things I like about the indentation-only style. Unlike column alignment, you can use either spaces or tabs for indentation and the formatting still comes out fine.
problems 9y ago
One interesting talk I watched recently: https://channel9.msdn.com/Events/GoingNative/2013/The-Care-and-Feeding-of-C-s-Dragons https://channel9.msdn.com/Events/GoingNative/2013/The-Care-a... In it, they make a really good argument that humans simply shouldn't be doing this type of formatting work. Let the computers do it, clang-format can get it right every time in a fraction of the time a human can. Pick whatever style you want, let the computers deal with it. I quite like this, now I just write a big long single line, hit a button and have it fixed for me. It's not a bad habit if it looks better and doesn't involve any time investment.
- arantius 9y ago
  I've seen plenty of suboptimal code in review, commented about what I consider a better/more readable version to be, and gotten the response "this is what the clang formatter produces". Boo to automatic formatting. It produces the worst lowest-common-denomninator version of code.
Arnavion 9y ago
>It means constant readjustment and unnecessarily bloated diffs every time you change a function or variable name. Your variable example is the thing that peeves me most about golang, since gofmt insists on aligning consecutive variable names and types in that columnar fashion.
- Stratoscope 9y ago
  What's really puzzling about that gofmt decision is that Rob Pike and other Go core team members are known to code in proportional fonts! https://news.ycombinator.com/item?id=10416364 https://news.ycombinator.com/item?id=10416364
21 9y ago
The diff could be smarter and notice that you just inserted some white space. Many GUI apps actually do that but unfortunately not your typical diff or git which insist in dealing with full lines only.
- harrisi 9y ago
  I'm sure many know, but for those who don't, `diff` (and `git diff`) accept -w and -b to ignore all white space and changes in the amount of white space, respectively. I find these very handy. Somewhat related, if you're looking at a diff on GitHub and want to ignore whitespace, you can just tack on `?w=1` to the URL (https://github.com/blog/967-github-secrets https://github.com/blog/967-github-secrets).
  - ghusbands 9y ago
    Though you still end up committing whitespace changes that can then cause unexpected conflicts, later.
  - mtm 9y ago
    For github I crafted together this little bookmarklet to ignore whitespace on diffs (use it daily for our code reviews): javascript:(function()%7Bopen(location.href+'?w=1');%7D)();void(0);
kpil 9y ago
Here is a thought. Maybe no formatting characters should be allowed to be saved embedded in source code, and instead presentation filters should handle everything related to formatting, documentation, etc. It might work..
- hobo_mark 9y ago
  Git supports custom "clean/smudge" filters on push and pull exactly for this sort of things. Unfortunately neither github not gitlab consider them so your online diffs would look like a mess of you did that.
- CapacitorSet 9y ago
  It looks interesting, but then one would have to define a normalization for the AST - either something like an XML printout of the AST, or a standard formatting for source code (perhaps whitespace-only minification?). It would also pose an issue when presenting code in "dumb" media (eg. a txt file).
shagie 9y ago
Alas, if only tabs realized columns could occur in locations other than 8 or 4 space tab stops. http://nickgravgaard.com/elastic-tabstops/ http://nickgravgaard.com/elastic-tabstops/
deleted 9y ago
[deleted]
tenken 9y ago
It's a non problem. Use a code formatter prior to code commit. If needed allow your editor to have a task to reformat a code file on Open to apply formatting you desire vs the teams or project guidelines.