If your whole team uses the same IDE, what’s wrong with commiting things like run configurations and code styles? I agree in general, but a wholesale ban on it is very cargo culty to me. There can be legitimate times to do it.
Absolutely nothing wrong. Their whole argument is that it delivers no guarantees about the things set in these files, but setting these presets is more about convenience than enforcing an equal development environment.
Whoever needs to enforce things like formatting and linting at the project level should be using a CI step.
Sure, fail the entire build because of a formatting problem. Hey, wouldn’t it be cool if we could stop that from happening? I don’t know, maybe by also adding in IDE specific formatting files? No? Oh. I wasn’t aware we could only have formatting files OR a CI format checker. 🙄
None of these things come at the expense of others. You can do both. Even if it’s part of the local build process I’d much rather know in my editor than on the terminal. And you may say “just have everyone do the same setup” to which I’d wonder what sort of magical land you live in where everyone always follows those rules and/or you can get buy in from management to spend that much time bike shedding and why you’d prefer either of them to just adding the damn file to version control to avoid it entirely.
I elaborated on it below. Your team will grow and shrink. No guarantee that each developer will bring the same IDE. This is especially true for open source projects.
If it works your team, no need to be dogmatic about it. Just be careful about what you put there and agree on a set of sane defaults with your team. Your project should build and run tasks without needing a specific IDE.
If your whole team uses the same IDE, what’s wrong with commiting things like run configurations and code styles? I agree in general, but a wholesale ban on it is very cargo culty to me. There can be legitimate times to do it.
Absolutely nothing wrong. Their whole argument is that it delivers no guarantees about the things set in these files, but setting these presets is more about convenience than enforcing an equal development environment.
Whoever needs to enforce things like formatting and linting at the project level should be using a CI step.
Sure, fail the entire build because of a formatting problem. Hey, wouldn’t it be cool if we could stop that from happening? I don’t know, maybe by also adding in IDE specific formatting files? No? Oh. I wasn’t aware we could only have formatting files OR a CI format checker. 🙄
None of these things come at the expense of others. You can do both. Even if it’s part of the local build process I’d much rather know in my editor than on the terminal. And you may say “just have everyone do the same setup” to which I’d wonder what sort of magical land you live in where everyone always follows those rules and/or you can get buy in from management to spend that much time bike shedding and why you’d prefer either of them to just adding the damn file to version control to avoid it entirely.
yeah, also why I do both
I elaborated on it below. Your team will grow and shrink. No guarantee that each developer will bring the same IDE. This is especially true for open source projects.
If it works your team, no need to be dogmatic about it. Just be careful about what you put there and agree on a set of sane defaults with your team. Your project should build and run tasks without needing a specific IDE.