5 ms·

Linting and code style guidelines. Easy to introduce, but makes a big positive difference.

colinbartlett 8y ago
In that vein, I invariably have one massive commit on every project to remove trailing whitespace first. That way when my well-behaved editor removes them with each commit, it's not littering up the diff.
- dmichulke 8y ago
  Frankly, I saw this in a few projects and it feels like the responsible is one of those people that can't actually code but wants to convince management of their impact with their huge commit stats. I also hate whitespace but it's just a symptom (the other developers' editors / git config probably don't show the trailing whitespace). Given this, it's a mere symptomatic remedy, the problem will reappear, and the only person benefiting from this is you. I'd hate to pay you for that.
  - klibertp 8y ago
    For what? 30 seconds of writing a sed command in the shell? I can donate that kind of time to the project for free, really.
  - steve_adams_86 8y ago
    I think the process would include having the team become aware of the situation and improving their editor configuration to stop littering whitespace everywhere. Otherwise I agree, that seems like a waste of time to do in isolation. I'd probably address it more completely if so many files are going to be touched, and whitespace is only one symptom of bad formatting connections. Perhaps everyone should employ the same formatter on save, for example. There is far more value in that. Getting rid of only superfluous whitespace is a bit of a time sink for what you get in return (as much as it drives me nuts).
- systemtest 8y ago
  My opinion is that every team member should have the same editor with the same settings. The settings should be easily accessible from Confluence or a similar knowledge base.
  - iopuy 8y ago
    Agreed, it should be part of the standard technical on-boarding process. Once someone is familiar with what the editor is buying them in terms of productivity they are free to search for their own should they choose. A pet peeve of mine is joining a new team and asking what the editor of choice is to be told "really it is up to you."
  - PurplePanda 8y ago
    what's the point of that? it takes a while to learn how to use your text editor well, and everyone is probably good at a different one. but they all pretty well have the ability to produce the same result, so why bother forcing one? it's better to (have a tool that can) specify what the end result should look like and let people work the way that they are good at.
    - cimmanom 8y ago
      Agreed. Plus now many editors obey the same .editorconfig files; and for those that don't, .editorconfig can be used as a reference for developers to configure their own working environment. I can understand wanting to standardize in a company with a 1000-person engineering org, where maybe it's harder to enforce that everyone uses the same conventions if there's no standardization in tools; but in a team of a few dozen, you should only be hiring people you trust anyway, and communicating with them about why small things like this are important.
    - systemtest 8y ago
      In my team everyone uses IntelliJ Ultimate with the same settings.xml file. We all have the same automatic tasks that happen on each commit: reformat code, optimize imports, check TODOs, perform SonarLint analysis. This has greatly reduced frustrated merge-requests filled with unimportant details such as code formatting and newlines. It has also greatly improved the code quality because it will warn you that you left a TODO in the code or that a certain method could also be private before you commit the code into the repo. Nobody has a problem with this, although in the Java world every corporate developer uses IntelliJ anyway. A couple of legacy project teams are still on Eclipse.
- cvvv 8y ago
  Change the settings in your editor? These sort of commits change the history in favor of the OCD-whitespace person, make "git-blame" a pain and generally look as if someone is trying to increase his line count.
Cthulhu_ 8y ago
I did this at my current / new assignment, turned out eslint was running but it was skipping tests, and it ran over the dist folder (e.g. minified code), annnd it didn't run with the --cache flag. Brought the runtime down from ??? (didn't wait for it to finish) to 30s to 2-3s, and it made thousands of minor inconsistency fixes. It was appreciated, thankfully, :p.

In that vein, I invariably have one massive commit on every project to remove trailing whitespace first. That way when my well-behaved editor removes them with each commit, it's not littering up the diff.

dmichulke 8y ago
Frankly, I saw this in a few projects and it feels like the responsible is one of those people that can't actually code but wants to convince management of their impact with their huge commit stats. I also hate whitespace but it's just a symptom (the other developers' editors / git config probably don't show the trailing whitespace). Given this, it's a mere symptomatic remedy, the problem will reappear, and the only person benefiting from this is you. I'd hate to pay you for that.
- klibertp 8y ago
  For what? 30 seconds of writing a sed command in the shell? I can donate that kind of time to the project for free, really.
- steve_adams_86 8y ago
  I think the process would include having the team become aware of the situation and improving their editor configuration to stop littering whitespace everywhere. Otherwise I agree, that seems like a waste of time to do in isolation. I'd probably address it more completely if so many files are going to be touched, and whitespace is only one symptom of bad formatting connections. Perhaps everyone should employ the same formatter on save, for example. There is far more value in that. Getting rid of only superfluous whitespace is a bit of a time sink for what you get in return (as much as it drives me nuts).
systemtest 8y ago
My opinion is that every team member should have the same editor with the same settings. The settings should be easily accessible from Confluence or a similar knowledge base.
- iopuy 8y ago
  Agreed, it should be part of the standard technical on-boarding process. Once someone is familiar with what the editor is buying them in terms of productivity they are free to search for their own should they choose. A pet peeve of mine is joining a new team and asking what the editor of choice is to be told "really it is up to you."
- PurplePanda 8y ago
  what's the point of that? it takes a while to learn how to use your text editor well, and everyone is probably good at a different one. but they all pretty well have the ability to produce the same result, so why bother forcing one? it's better to (have a tool that can) specify what the end result should look like and let people work the way that they are good at.
  - cimmanom 8y ago
    Agreed. Plus now many editors obey the same .editorconfig files; and for those that don't, .editorconfig can be used as a reference for developers to configure their own working environment. I can understand wanting to standardize in a company with a 1000-person engineering org, where maybe it's harder to enforce that everyone uses the same conventions if there's no standardization in tools; but in a team of a few dozen, you should only be hiring people you trust anyway, and communicating with them about why small things like this are important.
  - systemtest 8y ago
    In my team everyone uses IntelliJ Ultimate with the same settings.xml file. We all have the same automatic tasks that happen on each commit: reformat code, optimize imports, check TODOs, perform SonarLint analysis. This has greatly reduced frustrated merge-requests filled with unimportant details such as code formatting and newlines. It has also greatly improved the code quality because it will warn you that you left a TODO in the code or that a certain method could also be private before you commit the code into the repo. Nobody has a problem with this, although in the Java world every corporate developer uses IntelliJ anyway. A couple of legacy project teams are still on Eclipse.
cvvv 8y ago
Change the settings in your editor? These sort of commits change the history in favor of the OCD-whitespace person, make "git-blame" a pain and generally look as if someone is trying to increase his line count.

Cthulhu_ 8y ago

I did this at my current / new assignment, turned out eslint was running but it was skipping tests, and it ran over the dist folder (e.g. minified code), annnd it didn't run with the --cache flag. Brought the runtime down from ??? (didn't wait for it to finish) to 30s to 2-3s, and it made thousands of minor inconsistency fixes. It was appreciated, thankfully, :p.