I strongly believe that code formatting does not hold any information and that because of it, compilers should reject non-normalized code, saying “run a formatter first”. We have the tooling for most of the languages to make this absolutely painless, remove all head scratching of “what the hell is up with this code style” and just focus of the semantics. I believe that you should be allowed to produce code abominations like this code sample and have it auto-formatted into the code style that everyone can easily interpret.
The auto-formatting story is half baked I think. As far as I know most language have a formatter that goes only one way, which is an improvement over having no formatter at all.
What we’re missing is good tools to go from the standard format to a personalized format. For example, I was working on JavaScript recently and the team was using prettier with 2 space indentation. I found that somewhat hard to work with because of some minor vision issues, it was becoming a bit of an accessibility issue for me, but I was already viewed as a bit of a troublemaker at the company and pushing everyone to change their style wasn’t going to help me any.
I tried to find a tool that would reformat the code for me without altering the repository but couldn’t find an easy solution.
So we have formatters that go from “everyone’s personal style” to a standard style. But our tools for going the other direction, from standard style to “my personal style” are lacking. (Hoping to be proved wrong on this point.)
Your situation is why tabs are the clearly superior solution. Anyone on the team can just set their tab-width in their editor to whatever they want, and everything is consistent for everyone.
You could just have your own local prettier rules which will format things how you want while you work on them, then use something like lint-staged to run the standard prettier rules for your org on commit. That way you work how you wish, and the project gets the files how they wish.
I strongly believe that code formatting does not hold any information and that because of it, compilers should reject non-normalized code, saying “run a formatter first”. We have the tooling for most of the languages to make this absolutely painless, remove all head scratching of “what the hell is up with this code style” and just focus of the semantics. I believe that you should be allowed to produce code abominations like this code sample and have it auto-formatted into the code style that everyone can easily interpret.
Yeah, I like that new languages like Go and to a lesser extent Rust have formatters bundled.
The auto-formatting story is half baked I think. As far as I know most language have a formatter that goes only one way, which is an improvement over having no formatter at all.
What we’re missing is good tools to go from the standard format to a personalized format. For example, I was working on JavaScript recently and the team was using prettier with 2 space indentation. I found that somewhat hard to work with because of some minor vision issues, it was becoming a bit of an accessibility issue for me, but I was already viewed as a bit of a troublemaker at the company and pushing everyone to change their style wasn’t going to help me any.
I tried to find a tool that would reformat the code for me without altering the repository but couldn’t find an easy solution.
So we have formatters that go from “everyone’s personal style” to a standard style. But our tools for going the other direction, from standard style to “my personal style” are lacking. (Hoping to be proved wrong on this point.)
Your situation is why tabs are the clearly superior solution. Anyone on the team can just set their tab-width in their editor to whatever they want, and everything is consistent for everyone.
Unless you’re using them to align things. Then it matters. (Like comments)
You could just have your own local prettier rules which will format things how you want while you work on them, then use something like lint-staged to run the standard prettier rules for your org on commit. That way you work how you wish, and the project gets the files how they wish.
I don’t think it should be forced
But I do think it should be more popularized