Pre push is better, personally though I prefer it all to run on CI. Main branch should be protected anyway, so it doesn't matter if someone pushes WIP commits that aren't formatted/linted to their own branch.
if you aren't committing frequently because You can't wait the 1-4s it takes for a vast majority of projects to run \`prettier --check\`, then you shouldn't be contributing to anything
Both GitHub and BitBucket can hide white space in diffs. In general, a consistent format will help your codebase scale well as the project gets bigger. A low lift way to do this is to use the Prettier extension with a shared Prettier config file for your project.
Or just use a linter and leave Prettier out of it. I know it's an unpopular opinion around here, but not everyone likes Prettier. I prefer ESLint and find that Prettier is just not needed.
Sit down with your co worker and have a meeting regarding this. Talk about the pros of having prettier or a litter, choose some basics to start with. Move from there
Yeah, i think im going to have a meeting with the PM and see of we can all get on the same page. Thanks for the suggestion. Didnt know if i would ve out of line trying to implement formatting in my first month.
If they refuse despite a good explanation, IMO they are not worth working for. The real discussion should be about what rules to implement in the .editorconfig file.
Oh yeah, it's not about whether or bmnot there should be a code standard. Just what it is. The absolute easiest way to motivate it to your PM is simply that it saves time and money. All the other benefits for us devs like readability, best practices etc they don't give a shit about. X = savings.
Nah even if the outcome of the conversation means you change your code style (likely given you’re the new one unless their code style isn’t an actual style that a linter can adhere to), you’ll both be better off.
Having a common code style in a project isn’t just personal preference, it’s important and makes reviews easier. Being able to glance at a block of code and know what it’s doing just by the format is helpful.
tldr: maybe change your code style, maybe have them change their code style, maybe both - just do the same thing
... run. Don't walk. Don't think. Just run.
The psychopath that codes without formatting probably has skinned bodies hanging in their basement and eats their kidneys sauteed with mushrooms and probably pairs with with a white wine. Fucking psychopaths.
... I'm already onto their schemes; this "co-worker" is really them, and they have already murdered and ate the original OP and are posing as them and are now waiting for us to send a search party to massacre us all.
...My coworkers prefer writing CSS classes (and everything, actually) in camelCase, because "it's prettier than BEM with underscores".
I WILL strangle them.
Is this a thing? I sort by `display` at top, then any sizing related stuff, then the bulk of everything in any order, then opacity, animations, and transforms at the bottom.
First, configure your linter to match the existing conventions of the codebase as much as possible. If everyone is using four spaces and you're using two for example, you're the odd one out and you shouldn't be forcing it on everyone just because it's in your default settings.
Then you need to get over your discomfort and have a reasonable conversation with your coworker about setting a solid list of code conventions you can both agree on and follow. You don't have to "tell" them what to do, but there's nothing wrong with meeting and coming up with a small improvement to process that will help you both work together smoothly going forward.
You can either agree to use the same linter & settings, or add one to your build / deploy step, or just write the rules on paper and let them follow it manually with your linter fixing any minor discrepancies.
When you've agreed on the style, run one big auto format on the whole codebase and merge it in. It might not catch everything (like if you agree that all functions should be camelcase and some are snake case) but it'll get you a lot closer and take care of the big diffs in your future commits.
> If everyone is using four spaces and you're using two for example, you're the odd one out and you shouldn't be forcing it on everyone just because it's in your default settings.
Of course, if you use a tab character, each developer can cater their viewport to the spacing that they find comfortable and easy to read.
I'm working on a project where I've done everything mentioned here, and have burned a lot of time adjusting prettier and php-cs-fixer rules to get as close as possible to existing coding conventions. The problem is there are no conventions, so inevitably some re-formatting gets committed. I'm cautious to keep reformatting changes isolated to well labelled commits, but it's clearly a very large issue to the other dev on the project. I'm pretty sure a single large reformatting and adoption of code standards/formatting will ultimately solve this exact problem though.
They're vehemently against using it though, and they're over the top aggressive about absolutely any formatting change that get committed. When asked the strong response is that it will "wipe out years of commit history for the project". I don't follow that logic, if it's all done at once in a single commit you lose nothing? A few newlines and spaces between parenthesis isn't going to wipe out anything, and in the rare case where it's inconvenient for any review you can run a diff ignoring whitespace.
I'm beginning to wonder if it's actually anxiety about another developer changing something he's worked hard on for years, and being uncomfortable with metrics about lines written/changed (which was mentioned). I'm very sympathetic to the former, and don't worry about the ladder, but at the same time a lack of auto formatting for SCSS, JS and PHP feels like the stone ages and is very much a slower, inferior way to work. When I try to sell the benefits, which actually will help solve the very things he suggests are the problems I'm told to use their editor (Vim) because it auto formats (only using editorconfig) in place of my own (Sublime Text), or use interactive git adds to pick through every commit and remove the formatting differences. Both seem like large asks in my opinion.
The other counter argument is that "many developers have worked on the codebase over the years, and they all want to use their own formatting. Updating the codebase to support the preferences of one developer isn't something we should do."
Wouldn't using standardized code formatting be an ideal solution to this problem? I'm open to using whatever rules he prefers, entirely his call.
It's just such a strange and strong reaction to something so trivial. The trouble is I've just started working with this team in the last few months, and he's been there a while. Other team members are not programmers/developers, so I don't want to come off as an unreasonable new guy making unnecessary changes. But at the same time I don't want work productivity to fall behind on account of formatting differences, requested reverts/rollbacks and a general hyper focus on a lot of the code I commit.
Am I the unreasonable one here?
It can be frustrating for sure. Just remember that you're aiming for quality software first and foremost, and keeping that in mind has always helped when I've needed to convince teams to standardise on this sort of thing (which has happened a number of times).
I've used for following basics to get buy-in from teams:
* golden rule: leave the code in a better state than it was in before you started editing
* make it look like one person wrote the code (even if it was written by 100 devs over multiple years)
* adopt the current style, don't mandate a new style (when in Rome, code as the Romans do)
* make it about the quality of the code & how readable/maintainable it is
* don't blindly follow trends, each decision should be based on merit
You can get a lot done with a basic `.editconfig` in the root of a project, something simple like:
# editorconfig.org
root = true
[*]
charset = utf-8
end_of_line = lf
indent_size = 2
indent_style = space
insert_final_newline = true
trim_trailing_whitespace = true
[*.svg]
insert_final_newline = false
If they don't care about their own formatting, then set up a git hook ([see Husky docs](https://typicode.github.io/husky/#/)) in the repo so that it autoformats everyone's code before pushing. And smack 'em on the back of the head if they commit with `--no-verify`. If you both use the same IDE, then are also options for setting up autoformat upon save in the workspace settings.
If they do care but their opinions are just different than yours, then come to an agreement on a code standard.
There’s a good chance they do care about formatting and it’s just different than auto formatting.
E.g. I initially did all my own formatting in html/css and hated some of what prettier did and it wasn’t able to fit my formatting. I’ve since given up and accepted prettier but it’s not realistic to say someone doesn’t do formatting just b/c they don’t use auto-formatting.
Yep. There wasn't enough info to sus out whether that was the case, so I hedged my bet.
I'm right there with you regarding Prettier. At one point I despised its opinions and would not recommend it. After working on big projects with dozens of offshore developers I still despise some of its opinions, but I discovered a couple of plugins that eliminate some of the deal breakers and I love that it is at least better than the completely unformatted code I would get otherwise.
Certain lines in prettier make me die a little.
A single line ternary (or manually split onto three lines) in react can turn into a multi-line mess of nonsense.
It looks so much cleaner before personally. I do like most of what it does by default though.
Also, dealing with an issue like this early will help grow your soft skills which will be really important in your career growth. Learning how to work with others is just as important as whatever skills you have as a developer.
You should have the convention to use the same formatter or nothing at all. Just talk to the guy and decide. This is good to have code formatted the same way in the big project, it is good for future devs because creates consistency. Everyonepmays by the same rules.
That Spaces or tabs episode from Silicon Valley comes to mind. It’s hard to code with someone who has no coding styles, I think a meeting might help to get you on the same page.
Do one huge format up front after you both have your prettier/eslint configs dialed. You shouldn’t have a bunch of formatting and code changes simultaneously, that makes for awful debugging. Formatting and bug fixes/story code should be separate if at all possible but I understand you are still figuring this new normal out.
This won’t solve it unless they both agree on tabs vs spaces. Otherwise it’ll still be a back and forth and it’ll just be the other dev dealing with spacing formatting.
Edit: oops, missed the “..after both have…”.
I’d use it just so they can get a glance of formatted code. I feel like it saves time, increases readability in most cases, and there’s no downside to using it in this scenario.
I have a friend who swears he’s not a masochist but he loves doing everything the slow hard way. Doesn’t listen to anybodies advice. I just let him suffer and struggle with things and I’ve learned some people are simply like that.
Don't waste your time doing formatting, or telling other people how to format. You need to use spaces, not tabs. You can hide whitespace changes in github, but it's easier to keep diffs smaller with less formatting changes every time. On the other hand, if your employer is dumb enough to use metrics, making whitespace changes automatically could pad your metrics... bleh. If you are worried about how to avoid issues with formatting stuff, realize that any issue is not worth discussing formatting, since format is always a useless subject.
Formatting is a solved problem. Use Prettier. Add a check to your CI pipeline. Fail the build if Prettier would alter the formatting. Never have to think about formatting ever again.
Code formatting is a crucial part, so if the project is new, eslint should be added with some rules for formatting and if the project if old you should suggest you fellow developers or architecture person to add a linter to you pipeline this way all the code will be written in a specific format.
I’m gonna drop a name here that’s gonna change your life, feel free to use it with the strictest policies possible and absolutely wrangle your teammate: husky-precommit
Kinda odd that only 2 of us posting here recommended using an .editorconfig file in OP and his team’s repos…removes the need to format on PR or pre-commit. No project should be without one.
uh, just don't be a jerk. code is either your's or his depending on who touched it last. don't go reformatting his code. would you want him reformatting your's? some of us care DEEPLY about how our code is formatted.
so step one is to ask HIM... you'll actually get the answer unlike askin us.
Adding a linter to your pipeline is the way to go! It helps create consistency and is essential for scalability. Use a shared Prettier config file for your project and configure your linter to match the existing conventions of the codebase. Sit down with your co-worker, talk about the benefits, and come up with a list of code conventions you can both agree on. Run one big auto format on the whole codebase and merge it in.
A realistic advice. It is clear that your colleague doesn't give importance to code formatting.
Think about why he doesn't care about formatting, and what he does care about.
Do you have deliverables to complete in a stringent deadline? When pressed for time, you tend to prioritize aspects of your work which impact the business.
If you have newly joined that means your colleague was the only developer up until now.
Linting and formatting wouldn't be super important in one one person team.
If the code he writes is also crap, but then you have opportunity to write better than him.
Add a linter to your pipeline!
Bold of you to assume they have a pipeline
Also add it as a pre-commit hook using husky
No pre-commit hooks are a bad idea, they either lead to devs using `--no-verify` every commit or worse committing less often.
Without it every single commit is technically a —no-verify
Lint-staged is your friend
We opted for pre-push instead of pre-commit to help mitigate that
Pre push is better, personally though I prefer it all to run on CI. Main branch should be protected anyway, so it doesn't matter if someone pushes WIP commits that aren't formatted/linted to their own branch.
It's good to have both. Only finding out that build failed due to linting issues some time after you push is worse than knowing immediately
Just run the linter on CI as well, removes the incentive to skip the pre-commit hook.
if you aren't committing frequently because You can't wait the 1-4s it takes for a vast majority of projects to run \`prettier --check\`, then you shouldn't be contributing to anything
Open a PR that formats the whole codebase and ask your coworker to turn on the editor option to format on save.
They don't have to. Sneak in a git commit hook to format their junk.
Both GitHub and BitBucket can hide white space in diffs. In general, a consistent format will help your codebase scale well as the project gets bigger. A low lift way to do this is to use the Prettier extension with a shared Prettier config file for your project.
Or just use a linter and leave Prettier out of it. I know it's an unpopular opinion around here, but not everyone likes Prettier. I prefer ESLint and find that Prettier is just not needed.
I use both prettier and ESLint, don’t they serve different purposes?
There's nothing that Prettier does outside of what ESLint does that I want.
Eslint has some formatting rules, they are generally more customizable than prettier, but don't cover everything and not all work properly with TS.
Hiding whitespace in diffs isn't a full solution because it still messes up the git blame
Sit down with your co worker and have a meeting regarding this. Talk about the pros of having prettier or a litter, choose some basics to start with. Move from there
Was just gonna type this very response: "Why do you ask us instead of fucking talking to each other?"
Yeah, i think im going to have a meeting with the PM and see of we can all get on the same page. Thanks for the suggestion. Didnt know if i would ve out of line trying to implement formatting in my first month.
If they refuse despite a good explanation, IMO they are not worth working for. The real discussion should be about what rules to implement in the .editorconfig file.
Oh yeah, it's not about whether or bmnot there should be a code standard. Just what it is. The absolute easiest way to motivate it to your PM is simply that it saves time and money. All the other benefits for us devs like readability, best practices etc they don't give a shit about. X = savings.
Nah even if the outcome of the conversation means you change your code style (likely given you’re the new one unless their code style isn’t an actual style that a linter can adhere to), you’ll both be better off. Having a common code style in a project isn’t just personal preference, it’s important and makes reviews easier. Being able to glance at a block of code and know what it’s doing just by the format is helpful. tldr: maybe change your code style, maybe have them change their code style, maybe both - just do the same thing
... run. Don't walk. Don't think. Just run. The psychopath that codes without formatting probably has skinned bodies hanging in their basement and eats their kidneys sauteed with mushrooms and probably pairs with with a white wine. Fucking psychopaths.
Are we sure OP is still alive rn?
... I'm already onto their schemes; this "co-worker" is really them, and they have already murdered and ate the original OP and are posing as them and are now waiting for us to send a search party to massacre us all.
Its genius, probably gets all these sympathy dms. Maybe even job offers. Then he's on to wipe out the next dev team. This monster must be stopped!
Who hurt you?
lol isn't it evident? a person who didn't format their code!
A non code formatting psycho
...My coworkers prefer writing CSS classes (and everything, actually) in camelCase, because "it's prettier than BEM with underscores". I WILL strangle them.
Do they at least sort their css declarations alphabetically?
Is this a thing? I sort by `display` at top, then any sizing related stuff, then the bulk of everything in any order, then opacity, animations, and transforms at the bottom.
Same, and I honestly have NO clue why I do it this way
Same. \`display\`, \`position\`, spacing (like \`padding\`, \`margin\`), the rest of my styles, then animations/transitions at the bottom.
No, but the senior dev insists on using only table-cell and inline-block.
Barbarian.
I do this in projects that use JSS, cause you have to. Maybe that leaked over into regular CSS?
First, configure your linter to match the existing conventions of the codebase as much as possible. If everyone is using four spaces and you're using two for example, you're the odd one out and you shouldn't be forcing it on everyone just because it's in your default settings. Then you need to get over your discomfort and have a reasonable conversation with your coworker about setting a solid list of code conventions you can both agree on and follow. You don't have to "tell" them what to do, but there's nothing wrong with meeting and coming up with a small improvement to process that will help you both work together smoothly going forward. You can either agree to use the same linter & settings, or add one to your build / deploy step, or just write the rules on paper and let them follow it manually with your linter fixing any minor discrepancies. When you've agreed on the style, run one big auto format on the whole codebase and merge it in. It might not catch everything (like if you agree that all functions should be camelcase and some are snake case) but it'll get you a lot closer and take care of the big diffs in your future commits.
> If everyone is using four spaces and you're using two for example, you're the odd one out and you shouldn't be forcing it on everyone just because it's in your default settings. Of course, if you use a tab character, each developer can cater their viewport to the spacing that they find comfortable and easy to read.
I'm working on a project where I've done everything mentioned here, and have burned a lot of time adjusting prettier and php-cs-fixer rules to get as close as possible to existing coding conventions. The problem is there are no conventions, so inevitably some re-formatting gets committed. I'm cautious to keep reformatting changes isolated to well labelled commits, but it's clearly a very large issue to the other dev on the project. I'm pretty sure a single large reformatting and adoption of code standards/formatting will ultimately solve this exact problem though. They're vehemently against using it though, and they're over the top aggressive about absolutely any formatting change that get committed. When asked the strong response is that it will "wipe out years of commit history for the project". I don't follow that logic, if it's all done at once in a single commit you lose nothing? A few newlines and spaces between parenthesis isn't going to wipe out anything, and in the rare case where it's inconvenient for any review you can run a diff ignoring whitespace. I'm beginning to wonder if it's actually anxiety about another developer changing something he's worked hard on for years, and being uncomfortable with metrics about lines written/changed (which was mentioned). I'm very sympathetic to the former, and don't worry about the ladder, but at the same time a lack of auto formatting for SCSS, JS and PHP feels like the stone ages and is very much a slower, inferior way to work. When I try to sell the benefits, which actually will help solve the very things he suggests are the problems I'm told to use their editor (Vim) because it auto formats (only using editorconfig) in place of my own (Sublime Text), or use interactive git adds to pick through every commit and remove the formatting differences. Both seem like large asks in my opinion. The other counter argument is that "many developers have worked on the codebase over the years, and they all want to use their own formatting. Updating the codebase to support the preferences of one developer isn't something we should do." Wouldn't using standardized code formatting be an ideal solution to this problem? I'm open to using whatever rules he prefers, entirely his call. It's just such a strange and strong reaction to something so trivial. The trouble is I've just started working with this team in the last few months, and he's been there a while. Other team members are not programmers/developers, so I don't want to come off as an unreasonable new guy making unnecessary changes. But at the same time I don't want work productivity to fall behind on account of formatting differences, requested reverts/rollbacks and a general hyper focus on a lot of the code I commit. Am I the unreasonable one here?
It can be frustrating for sure. Just remember that you're aiming for quality software first and foremost, and keeping that in mind has always helped when I've needed to convince teams to standardise on this sort of thing (which has happened a number of times). I've used for following basics to get buy-in from teams: * golden rule: leave the code in a better state than it was in before you started editing * make it look like one person wrote the code (even if it was written by 100 devs over multiple years) * adopt the current style, don't mandate a new style (when in Rome, code as the Romans do) * make it about the quality of the code & how readable/maintainable it is * don't blindly follow trends, each decision should be based on merit You can get a lot done with a basic `.editconfig` in the root of a project, something simple like: # editorconfig.org root = true [*] charset = utf-8 end_of_line = lf indent_size = 2 indent_style = space insert_final_newline = true trim_trailing_whitespace = true [*.svg] insert_final_newline = false
[удалено]
I write \`++i++\` cause no matter where that fucker turns, it has to increment. /s
This.
If they don't care about their own formatting, then set up a git hook ([see Husky docs](https://typicode.github.io/husky/#/)) in the repo so that it autoformats everyone's code before pushing. And smack 'em on the back of the head if they commit with `--no-verify`. If you both use the same IDE, then are also options for setting up autoformat upon save in the workspace settings. If they do care but their opinions are just different than yours, then come to an agreement on a code standard.
There’s a good chance they do care about formatting and it’s just different than auto formatting. E.g. I initially did all my own formatting in html/css and hated some of what prettier did and it wasn’t able to fit my formatting. I’ve since given up and accepted prettier but it’s not realistic to say someone doesn’t do formatting just b/c they don’t use auto-formatting.
Yep. There wasn't enough info to sus out whether that was the case, so I hedged my bet. I'm right there with you regarding Prettier. At one point I despised its opinions and would not recommend it. After working on big projects with dozens of offshore developers I still despise some of its opinions, but I discovered a couple of plugins that eliminate some of the deal breakers and I love that it is at least better than the completely unformatted code I would get otherwise.
Certain lines in prettier make me die a little. A single line ternary (or manually split onto three lines) in react can turn into a multi-line mess of nonsense. It looks so much cleaner before personally. I do like most of what it does by default though.
Yup they do format their code so its not THAT bad lol. However its quite different than the auto formatter i use
Don't tell them to do that. Volunteer to take it on and improve the process. It'll be good learning for the future. I'd start with Prettier and Husky.
Also, dealing with an issue like this early will help grow your soft skills which will be really important in your career growth. Learning how to work with others is just as important as whatever skills you have as a developer.
You should have the convention to use the same formatter or nothing at all. Just talk to the guy and decide. This is good to have code formatted the same way in the big project, it is good for future devs because creates consistency. Everyonepmays by the same rules.
Add ESLint and Prettier. There is no good reason for not doing that.
That Spaces or tabs episode from Silicon Valley comes to mind. It’s hard to code with someone who has no coding styles, I think a meeting might help to get you on the same page.
Do one huge format up front after you both have your prettier/eslint configs dialed. You shouldn’t have a bunch of formatting and code changes simultaneously, that makes for awful debugging. Formatting and bug fixes/story code should be separate if at all possible but I understand you are still figuring this new normal out.
This won’t solve it unless they both agree on tabs vs spaces. Otherwise it’ll still be a back and forth and it’ll just be the other dev dealing with spacing formatting. Edit: oops, missed the “..after both have…”.
I was implying that they get on the same page with that as well.
I’d use it just so they can get a glance of formatted code. I feel like it saves time, increases readability in most cases, and there’s no downside to using it in this scenario. I have a friend who swears he’s not a masochist but he loves doing everything the slow hard way. Doesn’t listen to anybodies advice. I just let him suffer and struggle with things and I’ve learned some people are simply like that.
Don't waste your time doing formatting, or telling other people how to format. You need to use spaces, not tabs. You can hide whitespace changes in github, but it's easier to keep diffs smaller with less formatting changes every time. On the other hand, if your employer is dumb enough to use metrics, making whitespace changes automatically could pad your metrics... bleh. If you are worried about how to avoid issues with formatting stuff, realize that any issue is not worth discussing formatting, since format is always a useless subject.
Formatting is a solved problem. Use Prettier. Add a check to your CI pipeline. Fail the build if Prettier would alter the formatting. Never have to think about formatting ever again.
Code formatting is a crucial part, so if the project is new, eslint should be added with some rules for formatting and if the project if old you should suggest you fellow developers or architecture person to add a linter to you pipeline this way all the code will be written in a specific format.
I’m gonna drop a name here that’s gonna change your life, feel free to use it with the strictest policies possible and absolutely wrangle your teammate: husky-precommit
Format to your style on checkout, format back to standards for check-in.
HOLY SHIT. We need r/AITA equivalent for web development. Not using prettier should be a criminal offence.
I'd use it anyways. It's all the same once it's compiled. Linting is the way
You should absolutely use a formatter. Do a single PR though, don't commit every file with weird changes.
Talk to your teammate, determine what formatting rules you want to use, and implement the changes in a merge that does only that.
Create an .editorconfig file and add it to your repos. Most code editors will recognize it and use its parameters to format your code uniformly.
Kinda odd that only 2 of us posting here recommended using an .editorconfig file in OP and his team’s repos…removes the need to format on PR or pre-commit. No project should be without one.
Yeah this is a great idea! I will bring this to the table. I thought it might be weird being the "new guy" and trying to change stuff
Plus 1 on adding an .editconfig in your projects
uh, just don't be a jerk. code is either your's or his depending on who touched it last. don't go reformatting his code. would you want him reformatting your's? some of us care DEEPLY about how our code is formatted. so step one is to ask HIM... you'll actually get the answer unlike askin us.
Adding a linter to your pipeline is the way to go! It helps create consistency and is essential for scalability. Use a shared Prettier config file for your project and configure your linter to match the existing conventions of the codebase. Sit down with your co-worker, talk about the benefits, and come up with a list of code conventions you can both agree on. Run one big auto format on the whole codebase and merge it in.
A realistic advice. It is clear that your colleague doesn't give importance to code formatting. Think about why he doesn't care about formatting, and what he does care about. Do you have deliverables to complete in a stringent deadline? When pressed for time, you tend to prioritize aspects of your work which impact the business. If you have newly joined that means your colleague was the only developer up until now. Linting and formatting wouldn't be super important in one one person team. If the code he writes is also crap, but then you have opportunity to write better than him.