当开发环境非常擅长让用户知道每个项目是什么时，绝对讨厌的是命名规则。
正如标题所暗示的那样，如果开发人员要命名所有类型、对象、变量等，会不会有任何陷阱。'所有这些都在“snake_case”中，特别是在 Kotlin 中。忽略自动生成的绑定名称等。
【问题讨论】：
编码风格，例如命名，对编译器无关。
但这对人类很重要——正如几个聪明人曾经说过的那样，“programs must be written for people to read, and only incidentally for machines to execute.”（他们可能夸大了效果，但我认为那里仍然有一定的道理。）
命名的一致性意味着您不必停下来考虑是否使用下划线或大写（或空格或破折号或反引号内的任何内容）；它使在您的代码以及库和框架中更容易找到类和方法；它与 Kotlin 属性（在字节码中查找 getXxx/setXxx/isXxx 方法）配合得更好；它消除了开发人员之间的分歧来源；它不太可能导致 IDE 和框架以及源代码工具出现问题，这些工具往往假设您使用的是标准命名约定；它使新开发人员更容易上手代码库。
但是，更重要的是，不遵循约定的代码iS_нa℞???-τଠ?ɘⱭ?。当工作相同的事物看起来相同时，差异就更容易看出。你花在破译名字上的时间越少，就有更多的时间来理解代码对它们做了什么。这与我们使用一致的缩进和间距以及结构和设计模式的原因相同。通过更少的表面差异，您可以更轻松地看到代码中的底层结构和模式，并且偏差（以及因此的错误）变得更加明显。
编码——我包括调试、维护和增强以及编写新代码——是困难，而且我们人类是有限的，所以我们应该尽可能让事情变得简单。开发软件是一场与复杂性的持续战斗；每一个小小的简化都有帮助。您可能认为使用snake_case 代替camelCase 是微不足道的；但是，您在这里询问的事实表明它有所作为！
this question 和 this question 的答案给出了更多（并且更有说服力的）理由说明一致性很重要。
（碰巧，我多年来一直在使用喜欢snake_case的语言，以及喜欢camelCase的语言，我确实发现后者在上下文中更容易阅读。但与一致性相比，这是一个不太重要的考虑因素。 )
【讨论】：
除了与其他开发人员争论这一点，以及对所有看起来不同的库函数的调用之外，该语言将完美地工作而不在乎这些。
【讨论】：