Naming things sensibly and doing so consistently is pretty important in designing software because names are relied on to convey meaning. Sensible naming helps

Naming things sensibly and doing so consistently is pretty important in designing software because names are relied on to convey meaning. Sensible naming helps people. Bad and inconsistent naming confuses people. Naming matters more for interface types and APIs than for local variables. "acquire" and "take_ownership" might be equally good names for an operation, but you should pick one and stick to it throughout the codebase. And it would make sense to poll other people about what they think is a good name. Especially if you don't really care one way or another. Other people may have valid perspectives or they may just be better at expressing meaning through names. You can't really nail everything down in the official style guide for a language without it becoming baroque and oppressive. If you want to avoid bikeshedding, have a process in place for choosing naming conventions. Name someone as the arbiter. If consensus cannot be reached within a reasonable amount of time, the arbiter decides. It might help to keep a record of naming choices so people understand the reasoning behind why certain practices are chosen. Most programming is a social activity in that multiple people will have to deal with the code. Not caring about something as essential as naming, and wanting to avoid effort because you don't care, can be seen as a kind of anti-social behavior. On well functioning teams I've worked on, naming tends to not be a big issue because over time a team develops a common vocabulary. When in doubt, ask someone else on the team how they interpret a name.