I think your camelCase example really nails it. Code should be written in a way that is both non-ambiguous and idiomatic to the existing codebase.
If you're in a position where you can define that idiom, then by all means do so. But stay consistent so that when others join a project, or you leave a project, the intent of your codebase is well understood without needing to wade through pages of documentation.
So, IMO, while semicolons are important, they're relatively trivial and an easy "bug" to fix. If I'm looking for an authority, I typically check out the Google Style Guides.
A similar, though more pressing issue that I've faced recently is the proper parenthization of conditions for if. It's generally nice when you don't have to spend a minute or two remembering/looking up the nuances of C++ operator precedence. Know all of the intricacies and tricks for a language doesn't mean every member of your team knows them that well either.
If you're in a position where you can define that idiom, then by all means do so. But stay consistent so that when others join a project, or you leave a project, the intent of your codebase is well understood without needing to wade through pages of documentation.
So, IMO, while semicolons are important, they're relatively trivial and an easy "bug" to fix. If I'm looking for an authority, I typically check out the Google Style Guides.
A similar, though more pressing issue that I've faced recently is the proper parenthization of conditions for if. It's generally nice when you don't have to spend a minute or two remembering/looking up the nuances of C++ operator precedence. Know all of the intricacies and tricks for a language doesn't mean every member of your team knows them that well either.