4 ms·

> When I'm asked to change my style, I am - quite literally - asked to deny a fundamental Truth of my being. Ugh. Come on. I used to indent with 4 spaces. I l

> When I'm asked to change my style, I am - quite literally - asked to deny a fundamental Truth of my being. Ugh. Come on. I used to indent with 4 spaces. I lead a team where in the early days I added linting and had to decide one rules. Some of these I felt fine about - semicolons, for instance. But others the team had a fairly unanimous feeling about, 2 spaces being one of them. So I set the linter to 2 spaces, and now that's what I use for everything. I like it. If we didn't have linting to standardise this and other rules across the codebase, it'd be a mess. It's one thing to be able to identify who's written a thing, but it should be a subtlety in amongst consistency. Not a glaring stylistic mis-match. https://github.com/prettier/prettier https://github.com/prettier/prettier looks promising, on this topic. Edit: a rebuttal https://news.ycombinator.com/item?id=14921580 https://news.ycombinator.com/item?id=14921580

slacka 9y ago
Yes, just a kid crying about having to follow style guidelines. If manually running his team's tool is really wasting as much time as he claims, they should switch to a tooling that automatically corrects style. I use tabs, but the policy is spaces. When I commit a change, my my tabs are automatically controverted to spaces. Zero time lost and no one fights about tabs vs spaces.
- nulagrithom 9y ago
  Just a thought -- it would be neat to see a project that would allow you to check the code out again with your tabs instead of the committed spaces. More of a style translator than an enforcer.
  - xaedes 9y ago
    It should be relatively easy to set up with git hooks: Take one of the many Git Hooked Autoformaters: For example: https://github.com/michalrus/git-hooks-code-autoformat https://github.com/michalrus/git-hooks-code-autoformat Then add similar hooks for pulling on "post-merge" and "post-rewrite". There is no hook for "pull" per se, but either a merge or commit rewrite (rebase) happens after pull that changes code. So you should be good with those both hooks
- dang 9y ago
  > Yes, just a kid crying about This breaks the HN guidelines against calling names in arguments, so please don't do that. Your comment would be just fine without the first sentence.
- gvb 9y ago
  "tabs are automatically controverted to spaces" I don't know if that was a typo or intentional, but I like it!
choward 9y ago
I agree. You're a software engineer, not an artist.
- klibertp 9y ago
  Actually, you're both. You're an engineer when you hand your code to the computer to execute. But you are an artist when writing code for others to read. It's not a coincidence that a lot of advice for beginning authors (of novels) is quite similar to advice on writing readable code.
emmab 9y ago
I'm happy to have a standard formatter because it saves me time. I write my code ignoring indentation and whitespace, then autoformat it moments later. There's some stuff I have to do myself still, like ordering methods, adding empty lines for readability, and line-breaking string literals and comments.

slacka 9y ago

Yes, just a kid crying about having to follow style guidelines. If manually running his team's tool is really wasting as much time as he claims, they should switch to a tooling that automatically corrects style. I use tabs, but the policy is spaces. When I commit a change, my my tabs are automatically controverted to spaces. Zero time lost and no one fights about tabs vs spaces.

nulagrithom 9y ago
Just a thought -- it would be neat to see a project that would allow you to check the code out again with your tabs instead of the committed spaces. More of a style translator than an enforcer.
- xaedes 9y ago
  It should be relatively easy to set up with git hooks: Take one of the many Git Hooked Autoformaters: For example: https://github.com/michalrus/git-hooks-code-autoformat https://github.com/michalrus/git-hooks-code-autoformat Then add similar hooks for pulling on "post-merge" and "post-rewrite". There is no hook for "pull" per se, but either a merge or commit rewrite (rebase) happens after pull that changes code. So you should be good with those both hooks
dang 9y ago
> Yes, just a kid crying about This breaks the HN guidelines against calling names in arguments, so please don't do that. Your comment would be just fine without the first sentence.
gvb 9y ago
"tabs are automatically controverted to spaces" I don't know if that was a typo or intentional, but I like it!

choward 9y ago

I agree. You're a software engineer, not an artist.

klibertp 9y ago
Actually, you're both. You're an engineer when you hand your code to the computer to execute. But you are an artist when writing code for others to read. It's not a coincidence that a lot of advice for beginning authors (of novels) is quite similar to advice on writing readable code.

emmab 9y ago

I'm happy to have a standard formatter because it saves me time. I write my code ignoring indentation and whitespace, then autoformat it moments later. There's some stuff I have to do myself still, like ordering methods, adding empty lines for readability, and line-breaking string literals and comments.