Ever seen "thePlague of_mixed namingstyles WhereNoOne Seems_To_Agree on-what-to-use orWorse-they_start_mixingstyles"? Package repositories, command names, function names...it’s everywhere.

It’s hard to remember both the what and how of a name. Text-completion tools help for code but not package repositories and command-line arguments.

In systems I know where naming chaos ensued, there was initially consistency: one obvious, predictable style. Yet, as if to follow Broken Windows Theory, it only seemed to take one or two people introducing “whatever style they felt like” for everything else to break down.

Do people not notice when a pattern has formed? Do they not care? Do they not check first, and later decide they don’t feel like renaming?

A sign of professionalism is maintaining consistency within a unit. For instance, never have a Unix command like "cmd_abc -optOne -opt_two -optthree" (I mean, really, three styles in one command!?).

There are reasons to mix styles, if done so consistently. For instance: in header file "xyz.h", maybe every function is prefixed "xyz_", e.g. xyz_funcA() and xyz_funcB(). While this technically mixes two styles, it is predictable; and arguably, two styles make it easier to identify the prefix (compare: for "xyz_abc_def", is the prefix "xyz" or "xyz_abc"?).

Maybe you are joining namespaces, like C++ bindings for scripting. If C++ uses functionsLikeThis() and it implements TCL commands like "my_tcl_command", it helps to let the string "my_tcl_command" appear unmolested in C++ code instead of being transformed; if one can bend style rules to use someImplFunc_my_tcl_command(), that is superior to forcing someImplFuncMyTclCommand().

Interfaces and package repositories should be consistent. Languages cannot be, because there are good reasons to diverge. My hope is that developers twist names only when that is helpful, and stop arbitrary changes that ruin predictability.