5 ms·

Something that's kind of tricky for me and my team is that we disagree on things like indentation and spacing in/around brackets and parens. The disagreement is

Something that's kind of tricky for me and my team is that we disagree on things like indentation and spacing in/around brackets and parens. The disagreement isn't just a "I think it should be done this way..." but "I actually understand code better when it's written this way..." If we were to implement prettier, and chose to use 2-space indents, for a simple example, how would a 4-space developer fare when they pulled down the Prettified code? Would they just set up their own config locally based on their own standards?

draw_down 9y ago
You just have to settle on a style as a team and stick to it as a team. I'd say it doesn't make a ton of sense to have individual coding standards among a team.
rattray 9y ago
That doesn't sound like a good idea (after all, there can only be one codebase in source control) but I believe it actually would be possible – and in fact, prettier would be a vital component to making it happen. If you have a pair of particularly persnickety peers, you could theoretically: 1) run prettier with the company-wide config as a precommit hook (https://github.com/prettier/prettier#pre-commit-hook-for-changed-files https://github.com/prettier/prettier#pre-commit-hook-for-cha...) 2) instruct your colleagues to have their editor run prettier with their own preferences on save. This way, your colleagues can simply open a file locally and save it to see things their way – and the code will be back to company-normal when they commit. They'll still have to see that unbearable bracket-spacing during code review, of course. Prettier doesn't have many configuration options (intentionally!) so they'd probably opt to use prettier-eslint or similar, which allows more configuration (at the cost of speed). Hopefully, after trying this, they would come to the conclusion that life is better just using the defaults, two-space-indents be damned. Bikesheds are great places for compromise.
tobr 9y ago
I suppose Prettier should make it possible for a developer to reformat the code the way they prefer when they pull it, work on it, then format it back to what the rest of the team has agreed on before they push. Unless it was completely automated it sounds like a pretty terrible way to work, though. How are you doing it today?
alnitak 9y ago
Your comment made me wonder, could tools like prettier be the first step towards developer-customized code styles? See it as views. Code could be stored in a minified (spaces and new lines are not necessarily saved), and then every developer in the team can view the code in any style he chooses. His code would then be committed using the underlying "minified" format, so that the next developer can pick up that code and view it in his own code style. Does that even make sense? What could be the gotchas of such a thing?
ChicagoBoy11 9y ago
Like rattray mentioned, this is something that I think would be totally doable in Prettier (whether or not it would be wise is a separate issue). I sort of deal with something like that even just personally. On my work machine I have nice screen real estate, but when I'm on the go on my 11" air I have prettier set up with a more generous character limit so I can see more on screen. If you combined this set up with something like the pre-commit hooks that OITT have suggested, I could then be looking at my own code slightly differently in two machines but the end result would be the same!

draw_down 9y ago

You just have to settle on a style as a team and stick to it as a team. I'd say it doesn't make a ton of sense to have individual coding standards among a team.

rattray 9y ago

That doesn't sound like a good idea (after all, there can only be one codebase in source control) but I believe it actually would be possible – and in fact, prettier would be a vital component to making it happen. If you have a pair of particularly persnickety peers, you could theoretically: 1) run prettier with the company-wide config as a precommit hook (https://github.com/prettier/prettier#pre-commit-hook-for-changed-files https://github.com/prettier/prettier#pre-commit-hook-for-cha...) 2) instruct your colleagues to have their editor run prettier with their own preferences on save. This way, your colleagues can simply open a file locally and save it to see things their way – and the code will be back to company-normal when they commit. They'll still have to see that unbearable bracket-spacing during code review, of course. Prettier doesn't have many configuration options (intentionally!) so they'd probably opt to use prettier-eslint or similar, which allows more configuration (at the cost of speed). Hopefully, after trying this, they would come to the conclusion that life is better just using the defaults, two-space-indents be damned. Bikesheds are great places for compromise.

tobr 9y ago

I suppose Prettier should make it possible for a developer to reformat the code the way they prefer when they pull it, work on it, then format it back to what the rest of the team has agreed on before they push. Unless it was completely automated it sounds like a pretty terrible way to work, though. How are you doing it today?

alnitak 9y ago

Your comment made me wonder, could tools like prettier be the first step towards developer-customized code styles? See it as views. Code could be stored in a minified (spaces and new lines are not necessarily saved), and then every developer in the team can view the code in any style he chooses. His code would then be committed using the underlying "minified" format, so that the next developer can pick up that code and view it in his own code style. Does that even make sense? What could be the gotchas of such a thing?

ChicagoBoy11 9y ago

Like rattray mentioned, this is something that I think would be totally doable in Prettier (whether or not it would be wise is a separate issue). I sort of deal with something like that even just personally. On my work machine I have nice screen real estate, but when I'm on the go on my 11" air I have prettier set up with a more generous character limit so I can see more on screen. If you combined this set up with something like the pre-commit hooks that OITT have suggested, I could then be looking at my own code slightly differently in two machines but the end result would be the same!