I felt that. I have a colleague whose coding style is different to mine and whenever they work on code that I originally wrote, I have to resist the temptation to modify things to camelCase.
It’s interesting that something this minor gets people so upset. I mean, I get it, but objectively it’s weird of us.
I had a debate years ago about test naming. When I was a junior, the lead dev used test methods with an underscore separating different cases. Like testServiceConnector_success(). I thought that’s pretty neat and kept that style. In another project one of the devs almost had a meltdown because I dared introducing underscore scum into “his” project.
Last year I had a module for ai stuff. We did things in Python and I am quite into doing things as coding standards say. My mate didn’t really care so much and just went for his style of doing things, also not really worrying about descriptive names etc.
Well, let’s say, we weren’t having a good time.
I also realized that I was probably too harsh and tried to go a bit more easy on it later, but many things just felt wrong.
I work on a proprietary language that translates everything to uppercase before compiling. So having a specific case is useless. The standard functions all have wacky cases. Some from the same module may use CamelCase, while it’s brother use snake_case.
… I just use Rust’s style. Simple, easy.
for a second I thought I read
publ;c