4 ms·

completely agree with you. and i religiously autoformat my code before i read the code and just before i save the file. However it still amazes me how the majo

completely agree with you. and i religiously autoformat my code before i read the code and just before i save the file. However it still amazes me how the majority of developers i work with either have no opinion on the topic or worse think this is a bad idea. some the reasons I've heard was it makes alot of changes to a file causing alot of diffs with previous version making it harder to figure was was actually changed, or they don't like they way its formatted .

problems 9y ago
I've been following this practice for a while, but never really thought much of mentioning it until I watched an interesting talk the other day: 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 mention an autoformatter as one of the best tools they gave their developers in terms of productivity gain and it really got me thinking about how this should be versus how it is in practice. There are some really bad autoformatters and some really good ones - find one that works and is configurable to match your standard and I think it really does result in a good productivity improvement.
- jdc0589 9y ago
  completely agree, I'm also the (original) author of https://github.com/jdc0589/JsFormat https://github.com/jdc0589/JsFormat though, so I'm probably just more sensitive to formatting stuff in general.
rdiddly 9y ago
Yep if you're going to convert from tabs to spaces or vice versa, please do a check-in/commit consisting only of that change before making any substantive code changes.
- tracker1 9y ago
  Was going to say the same... nothing wrong with a commit including only format changes... for that matter, add it as a task to the project, commit, run it, commit, then proceed to edit. If you have commit hooks setup, add it as a precommit hook/task. As long as it's relatively transparent for everyone to be able to use.
patrickdavey 9y ago
Doesn't that mean you make tools like git blame a whole lot less useful? I'm all for formatting my own code correctly, but I'm not going to nuke git history for a few spaces.
- problems 9y ago
  Blame is for me at least a fairly infrequently used operation and there's really not much else it breaks unless there are other active branches at the time. I don't find blame information that valuable and would argue that most uses are in fact counterproductive (it's in the name - blame). You'd only have to do it once, all changes past that point would be good assuming you set it up in your IDE automatically or in your precommit. So if for some reason you needed to go back a long ways and blame something you could always check out back past that initial styling fix and see it.

problems 9y ago

I've been following this practice for a while, but never really thought much of mentioning it until I watched an interesting talk the other day: 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 mention an autoformatter as one of the best tools they gave their developers in terms of productivity gain and it really got me thinking about how this should be versus how it is in practice. There are some really bad autoformatters and some really good ones - find one that works and is configurable to match your standard and I think it really does result in a good productivity improvement.

jdc0589 9y ago
completely agree, I'm also the (original) author of https://github.com/jdc0589/JsFormat https://github.com/jdc0589/JsFormat though, so I'm probably just more sensitive to formatting stuff in general.

rdiddly 9y ago

Yep if you're going to convert from tabs to spaces or vice versa, please do a check-in/commit consisting only of that change before making any substantive code changes.

tracker1 9y ago
Was going to say the same... nothing wrong with a commit including only format changes... for that matter, add it as a task to the project, commit, run it, commit, then proceed to edit. If you have commit hooks setup, add it as a precommit hook/task. As long as it's relatively transparent for everyone to be able to use.

patrickdavey 9y ago

Doesn't that mean you make tools like git blame a whole lot less useful? I'm all for formatting my own code correctly, but I'm not going to nuke git history for a few spaces.

problems 9y ago
Blame is for me at least a fairly infrequently used operation and there's really not much else it breaks unless there are other active branches at the time. I don't find blame information that valuable and would argue that most uses are in fact counterproductive (it's in the name - blame). You'd only have to do it once, all changes past that point would be good assuming you set it up in your IDE automatically or in your precommit. So if for some reason you needed to go back a long ways and blame something you could always check out back past that initial styling fix and see it.