7 ms·

Maintain consistent styles for developers working across various editors

72 points by pmarin 3y ago

bloopernova 3y ago
Part of a good software team's toolbox. Others: https://direnv.net/ https://direnv.net/ -- when you cd to a directory, do things like set variables. https://asdf-vm.com/ https://asdf-vm.com/ -- manage and use specific versions of software. Can work with direnv too! https://pre-commit.com/ https://pre-commit.com/ -- git hooks that I personally found easier to manage than Husky. https://github.com/qoomon/git-conventional-commits https://github.com/qoomon/git-conventional-commits -- enforce standard commit messages. Works with pre-commit!
- bavent 3y ago
  I used asdf for a long time and recently switched over to rtx (https://github.com/jdxcode/rtx https://github.com/jdxcode/rtx) and so far it's been a better experience for me. I must have screwed up something years ago in my dotfiles, but when I setup asdf two or so years ago, I kept running into odd issues - the wrong version of ruby being used for running rubocop/rspec, vim being unable to autofix styling, misc other tools not working as expected when maintaining several versions of them. I installed rtx as kind of a hail Mary and it's been much more smooth so far.
  - e1g 3y ago
    Same, I went from volta -> asdf -> rtx, and find rtx to be the most seamless and well-thought-out option for me.
  - SOLAR_FIELDS 3y ago
    I just spent an hour or so today fighting with asdf Python installs. I’ll check out rtx.
- mherrmann 3y ago
  I'd like to offer https://github.com/jamesob/desk https://github.com/jamesob/desk as an alternative to direnv. It's useful for also jumping to the project directory and doing other things like opening an editor.
  - hamandcheese 3y ago
    What advantages does desk have over direnv?
- kevincox 3y ago
  I have to say I love editorconfig, I feel that once you start running code and managing tools it starts to get too much for me. At that point just spin up a VM or container so that the environment is yours. I loathe pre-commit hooks. I often times just want to save work in progress or show someone what I have right now and they slow down my work or worse fail and lose my commit message and cause me to have to figure out how to disable them to continue. If you want to run checks for formatting or similar that is much better done in CI. I can get a reminder without breaking any dev workflows. Of course make fixing formatting a single command, and maybe an optional hook for those that prefer it. But when projects try to auto-install hooks it drives me crazy.
  - andybak 3y ago
    A compromise is to only enforce pre-commit rules when merging to main or some other important branch. Be as sloppy as you want on your own branches and make stuff proper when you're ready.
    - ucm_edge 3y ago
      For us we did the main only pre commit thing and also a CI check that any MR marked as ready for review has to pass linting. So you can go wild in your own branches and draft MRs but anything you want someone else to review has to pass.
  - ghosty141 3y ago
    Imo the pre-receive or update hook should be used on the server. For trunk based development I‘d also only check for (e.g) formatting on the main branch.
  - throw_a_grenade 3y ago
    git commit -n|--no-verify I have it in shell history, so it's somethig like "^R ver".
    - kevincox 3y ago
      By the time I realize I should have done that I have already been inconvinced. Also remember to copy .git/COMMIT_EDITMSG before you run it so that you don't loose your message.
- silverwind 3y ago
  > https://direnv.net/ https://direnv.net/ -- when you cd to a directory, do things like set variables. Just use dotenv instead. https://asdf-vm.com/ https://asdf-vm.com/ -- manage and use specific versions of software. Can work with direnv too! May be useful in some cases, but adds a global dependency on asdf itself. > https://pre-commit.com/ https://pre-commit.com/ -- git hooks that I personally found easier to manage than Husky. Git hooks are disturbing and slow down and/or break advanced git interactions. > https://github.com/qoomon/git-conventional-commits https://github.com/qoomon/git-conventional-commits -- enforce standard commit messages. Works with pre-commit! Only if you want to be so pedantic about them. I find it mostly a waste of time to enforce commit message style.
- artdigital 3y ago
  Good tools, but I disagree with the last one, which feels more like an outlier. The feat, docs, whatever style is highly opinionated, and I have yet to encounter a need for something like this in a professional setting
tombh 3y ago
What notable languages don't have an opinionated auto-formatter? Like Python/Black, Rust/rustfmt, JS/prettier, etc.
- theawless 3y ago
  Java for sure. I don't think Google style is good enough to be called the default.
  - The_Colonel 3y ago
    Somehow it doesn't seem to be such a big problem in Java land. I think there's some common baseline shared by basically everyone - I don't remember ever seeing Java classes which were not indented with 4 spaces for example.
    - xigoi 3y ago
      Auto-formatting is also used for enforcing a line width limit while keeping the code readable, which is hard and tedious to do manually.
    - marginalia_nu 3y ago
      Yeah, this dates back pretty far: https://www.oracle.com/technetwork/java/codeconventions-150003.pdf https://www.oracle.com/technetwork/java/codeconventions-1500... While minor variations exist, virtually all Java code follows these conventions pretty closely. Although I'll note it seems to get a bit more chaotic with regards to indenting newer constructions like streams and lambdas.
      - SOLAR_FIELDS 3y ago
        People like to pooh pooh Java in the circles I hang out in, but I’m always quick to point out stuff like this, things that are just basically mostly solved in Java land and no one really wastes time on anymore because some pretty good decisions were made 20-25 years ago. How to handle a lot of aspects of dependencies is another classic example.
erik_seaberg 3y ago
I care whether experts can understand each others’ reviewed work, not whether they would use exactly the same amount of whitespace. Don’t reformat code you aren’t rewriting, and definitely not with a tool that doesn’t understand what a developer was communicating when he laid it out that way.
- Mike_12345 3y ago
  I would say everything in the codebase should be auto formatted to a consistent style. This reduces whitespace noise in pull requests. No room for egotistical developers to take ownership of files in a shared codebase and waste time on petty formatting arguments. It keeps everything professional and tidy. When someone commits changes to an existing file, they auto format before committing. If existing parts of the file already contain weird non standard formatting this creates distracting whitespace noise in the pull request that could have been prevented. It's a waste of time to not use standard formatting.
  - erik_seaberg 3y ago
    Layout is semantic, just as names and comments are. I don't want a tool to blindly stomp any of these when it lacks understanding how they benefit readers. The answer to dirty diffs is to not make them. Every change should be intentional, and a reviewer should agree that it's important. "Reformat this block I haphazardly edited" is fine, but don't make the change bigger for no reason.
    - sumedh 3y ago
      > I don't want a tool to blindly stomp any of these when it lacks understanding how they benefit readers Some dev will have 1 newline after a method ends, another dev will have two newlines, some might have 3 etc. Should you as a code reviewer be wasting time looking for such issues and putting comments tell the other to fix such issues?
      - erik_seaberg 3y ago
zeedude 3y ago
Here we are in the current year and we still i/o source as raw form text. Personally, I’ve always hoped for standardized AST formats with comprehensive tooling, including source control. Many more problems vanish than are created with source as AST. For instance, this discussion.

72 points by pmarin 3y ago

Part of a good software team's toolbox. Others: https://direnv.net/ https://direnv.net/ -- when you cd to a directory, do things like set variables. https://asdf-vm.com/ https://asdf-vm.com/ -- manage and use specific versions of software. Can work with direnv too! https://pre-commit.com/ https://pre-commit.com/ -- git hooks that I personally found easier to manage than Husky. https://github.com/qoomon/git-conventional-commits https://github.com/qoomon/git-conventional-commits -- enforce standard commit messages. Works with pre-commit!

bavent 3y ago
I used asdf for a long time and recently switched over to rtx (https://github.com/jdxcode/rtx https://github.com/jdxcode/rtx) and so far it's been a better experience for me. I must have screwed up something years ago in my dotfiles, but when I setup asdf two or so years ago, I kept running into odd issues - the wrong version of ruby being used for running rubocop/rspec, vim being unable to autofix styling, misc other tools not working as expected when maintaining several versions of them. I installed rtx as kind of a hail Mary and it's been much more smooth so far.
- e1g 3y ago
  Same, I went from volta -> asdf -> rtx, and find rtx to be the most seamless and well-thought-out option for me.
- SOLAR_FIELDS 3y ago
  I just spent an hour or so today fighting with asdf Python installs. I’ll check out rtx.
mherrmann 3y ago
I'd like to offer https://github.com/jamesob/desk https://github.com/jamesob/desk as an alternative to direnv. It's useful for also jumping to the project directory and doing other things like opening an editor.
- hamandcheese 3y ago
  What advantages does desk have over direnv?
kevincox 3y ago
I have to say I love editorconfig, I feel that once you start running code and managing tools it starts to get too much for me. At that point just spin up a VM or container so that the environment is yours. I loathe pre-commit hooks. I often times just want to save work in progress or show someone what I have right now and they slow down my work or worse fail and lose my commit message and cause me to have to figure out how to disable them to continue. If you want to run checks for formatting or similar that is much better done in CI. I can get a reminder without breaking any dev workflows. Of course make fixing formatting a single command, and maybe an optional hook for those that prefer it. But when projects try to auto-install hooks it drives me crazy.
- andybak 3y ago
  A compromise is to only enforce pre-commit rules when merging to main or some other important branch. Be as sloppy as you want on your own branches and make stuff proper when you're ready.
  - ucm_edge 3y ago
    For us we did the main only pre commit thing and also a CI check that any MR marked as ready for review has to pass linting. So you can go wild in your own branches and draft MRs but anything you want someone else to review has to pass.
- ghosty141 3y ago
  Imo the pre-receive or update hook should be used on the server. For trunk based development I‘d also only check for (e.g) formatting on the main branch.
- throw_a_grenade 3y ago
  git commit -n|--no-verify I have it in shell history, so it's somethig like "^R ver".
  - kevincox 3y ago
    By the time I realize I should have done that I have already been inconvinced. Also remember to copy .git/COMMIT_EDITMSG before you run it so that you don't loose your message.
silverwind 3y ago
> https://direnv.net/ https://direnv.net/ -- when you cd to a directory, do things like set variables. Just use dotenv instead. https://asdf-vm.com/ https://asdf-vm.com/ -- manage and use specific versions of software. Can work with direnv too! May be useful in some cases, but adds a global dependency on asdf itself. > https://pre-commit.com/ https://pre-commit.com/ -- git hooks that I personally found easier to manage than Husky. Git hooks are disturbing and slow down and/or break advanced git interactions. > https://github.com/qoomon/git-conventional-commits https://github.com/qoomon/git-conventional-commits -- enforce standard commit messages. Works with pre-commit! Only if you want to be so pedantic about them. I find it mostly a waste of time to enforce commit message style.
artdigital 3y ago
Good tools, but I disagree with the last one, which feels more like an outlier. The feat, docs, whatever style is highly opinionated, and I have yet to encounter a need for something like this in a professional setting

tombh 3y ago

What notable languages don't have an opinionated auto-formatter? Like Python/Black, Rust/rustfmt, JS/prettier, etc.

theawless 3y ago
Java for sure. I don't think Google style is good enough to be called the default.
- The_Colonel 3y ago
  Somehow it doesn't seem to be such a big problem in Java land. I think there's some common baseline shared by basically everyone - I don't remember ever seeing Java classes which were not indented with 4 spaces for example.
  - xigoi 3y ago
    Auto-formatting is also used for enforcing a line width limit while keeping the code readable, which is hard and tedious to do manually.
  - marginalia_nu 3y ago
    Yeah, this dates back pretty far: https://www.oracle.com/technetwork/java/codeconventions-150003.pdf https://www.oracle.com/technetwork/java/codeconventions-1500... While minor variations exist, virtually all Java code follows these conventions pretty closely. Although I'll note it seems to get a bit more chaotic with regards to indenting newer constructions like streams and lambdas.
    - SOLAR_FIELDS 3y ago
      People like to pooh pooh Java in the circles I hang out in, but I’m always quick to point out stuff like this, things that are just basically mostly solved in Java land and no one really wastes time on anymore because some pretty good decisions were made 20-25 years ago. How to handle a lot of aspects of dependencies is another classic example.

erik_seaberg 3y ago

I care whether experts can understand each others’ reviewed work, not whether they would use exactly the same amount of whitespace. Don’t reformat code you aren’t rewriting, and definitely not with a tool that doesn’t understand what a developer was communicating when he laid it out that way.

Mike_12345 3y ago
I would say everything in the codebase should be auto formatted to a consistent style. This reduces whitespace noise in pull requests. No room for egotistical developers to take ownership of files in a shared codebase and waste time on petty formatting arguments. It keeps everything professional and tidy. When someone commits changes to an existing file, they auto format before committing. If existing parts of the file already contain weird non standard formatting this creates distracting whitespace noise in the pull request that could have been prevented. It's a waste of time to not use standard formatting.
- erik_seaberg 3y ago
  Layout is semantic, just as names and comments are. I don't want a tool to blindly stomp any of these when it lacks understanding how they benefit readers. The answer to dirty diffs is to not make them. Every change should be intentional, and a reviewer should agree that it's important. "Reformat this block I haphazardly edited" is fine, but don't make the change bigger for no reason.
  - sumedh 3y ago
    > I don't want a tool to blindly stomp any of these when it lacks understanding how they benefit readers Some dev will have 1 newline after a method ends, another dev will have two newlines, some might have 3 etc. Should you as a code reviewer be wasting time looking for such issues and putting comments tell the other to fix such issues?
    - erik_seaberg 3y ago

zeedude 3y ago

Here we are in the current year and we still i/o source as raw form text. Personally, I’ve always hoped for standardized AST formats with comprehensive tooling, including source control. Many more problems vanish than are created with source as AST. For instance, this discussion.