4 ms·

It's not that "style" doesn't matter, it's that you hit quickly diminishing returns after the bare basics of a formatter and maybe naming conventions. And most

by zachmu 3y ago

It's not that "style" doesn't matter, it's that you hit quickly diminishing returns after the bare basics of a formatter and maybe naming conventions. And most people who are enthusiastic about "style" push it way, way past this point of diminishing returns. At the end of the day, I don't really care how you write your code as long as I can read and understand it, which comes 90% down to 1) did you choose clear names, 2) do you have clean abstractions / interfaces. If you did that, write your code however you want. And in fact, it's antisocial to demand that other devs (junior or otherwise) adapt to your own personal idiosyncrasies. Just as in writing prose, different authors have different, clearly intelligible "voices" that distinguish them. Stamping out someone else's voice just to match your own preferences kills the joy of programming for them, you should only do so in the direst of circumstances.

em-bee 3y ago
exactly this. last week in a codereview i got asked to clean up indentation of some html structures that i had added. my response was: i duplicated an existing structure and made mine look exactly the same. i agree that proper indentation would be nice. but if i did that, my structures would look different from the original. i could clean up the original too, but then the diff would be harder to read because it would contain unrelated changes. copying the original unclean structure in this case is best for readability, because consistency is more important than any particular style. if anyone cares about the style, they can submit a style cleanup separately.
- mock-possum 3y ago
  My feelings about that stuff have shifted over time - these days I figure fuck it let the linger worry about the formatting. As long as everyone on the team is using the same config, things like indentation prettt much take care of themselves.
- q7xvh97o2pDhNrh 3y ago
  > my response was: i duplicated an existing structure and made mine look exactly the same. i agree that proper indentation would be nice. but if i did that, my structures would look different from the original. i could clean up the original too, but then the diff would be harder to read because it would contain unrelated changes. The idealist part of me wants to say: Clean up the original code, submit that as the first diff, then rebase your additions on top as a separate diff. The pragmatist part of me recognized long ago that a lot of software engineering now is like what you describe. The days of elegant, carefully-maintained codebases where someone sweated over every semicolon are long gone.
  - em-bee 3y ago
    in a pull request all commits get merged into one when you review the PR, so it would have to be two separate pull requests to be reviews separately, which is what i suggested. when working by myself without PRs then i would do almost exactly as you describe. i would probably put the cleanup after the code change though mainly because i want to focus on solving the problem first, and worry about cleanup later. but i can see the benefit of doing the cleanup first.
  - Avshalom 3y ago
    > carefully-maintained codebases where someone sweated over every semicolon this is not a thing that has ever existed. what on earth are you talking about.
    - dartos 3y ago
      I’ve been writing software for 20 years and I’ve never seen anything like that either.
- shrubble 3y ago
  A guy I know at $currentjob would have agreed to the criticism, then created at least 2x Jira tickets to clean up the original and then the structure you mention.
brabel 3y ago
> And in fact, it's antisocial to demand that other devs (junior or otherwise) adapt to your own personal idiosyncrasies. Most people see it as the exact opposite of this: it's you who are trying to impose your own personal idiosyncrasies on the project if you don't just adopt the project's style (which is hopefully automated so all you need to do is press a shortcut once you're done, or run a command before comitting) and insist on doing your own thing.
- zachmu 3y ago
  Style which can reliably be achieved by running a script is not really what I'm talking about. I like Go's auto formatting. People go way, way beyond that.
deleted 3y ago
[deleted]

by zachmu 3y ago

em-bee 3y ago

exactly this. last week in a codereview i got asked to clean up indentation of some html structures that i had added. my response was: i duplicated an existing structure and made mine look exactly the same. i agree that proper indentation would be nice. but if i did that, my structures would look different from the original. i could clean up the original too, but then the diff would be harder to read because it would contain unrelated changes. copying the original unclean structure in this case is best for readability, because consistency is more important than any particular style. if anyone cares about the style, they can submit a style cleanup separately.

mock-possum 3y ago
My feelings about that stuff have shifted over time - these days I figure fuck it let the linger worry about the formatting. As long as everyone on the team is using the same config, things like indentation prettt much take care of themselves.
q7xvh97o2pDhNrh 3y ago
> my response was: i duplicated an existing structure and made mine look exactly the same. i agree that proper indentation would be nice. but if i did that, my structures would look different from the original. i could clean up the original too, but then the diff would be harder to read because it would contain unrelated changes. The idealist part of me wants to say: Clean up the original code, submit that as the first diff, then rebase your additions on top as a separate diff. The pragmatist part of me recognized long ago that a lot of software engineering now is like what you describe. The days of elegant, carefully-maintained codebases where someone sweated over every semicolon are long gone.
- em-bee 3y ago
  in a pull request all commits get merged into one when you review the PR, so it would have to be two separate pull requests to be reviews separately, which is what i suggested. when working by myself without PRs then i would do almost exactly as you describe. i would probably put the cleanup after the code change though mainly because i want to focus on solving the problem first, and worry about cleanup later. but i can see the benefit of doing the cleanup first.
- Avshalom 3y ago
  > carefully-maintained codebases where someone sweated over every semicolon this is not a thing that has ever existed. what on earth are you talking about.
  - dartos 3y ago
    I’ve been writing software for 20 years and I’ve never seen anything like that either.
shrubble 3y ago
A guy I know at $currentjob would have agreed to the criticism, then created at least 2x Jira tickets to clean up the original and then the structure you mention.

brabel 3y ago

> And in fact, it's antisocial to demand that other devs (junior or otherwise) adapt to your own personal idiosyncrasies. Most people see it as the exact opposite of this: it's you who are trying to impose your own personal idiosyncrasies on the project if you don't just adopt the project's style (which is hopefully automated so all you need to do is press a shortcut once you're done, or run a command before comitting) and insist on doing your own thing.

zachmu 3y ago
Style which can reliably be achieved by running a script is not really what I'm talking about. I like Go's auto formatting. People go way, way beyond that.

deleted 3y ago

[deleted]