选择PascalCasing而不是camelCasing的原因是什么，或者从编程语言设计POV中选择的原因是什么？

Question

我喜欢这两种语言，但我注意到当您想编辑代码时，使用camelCasing作为成员的语言有时需要更多的调整。例如(在Python中)：

node.customData()

vs

node.setCustomData()

定制更换套管。如果是这样，就可以避免：

node.getCustomData()

例如，在C#中，他们将使用PascalCasing。

我知道有些人甚至不用套管，所以：

node.getcustomdata()

似乎脚本语言通常更喜欢camelCasing而不是PascalCasing，而不是更轻松？

有理由从编程语言设计POV中选择一个而不是另一个吗？

Answer 1

确实没有确凿的证据表明，比起帕斯卡套管，更喜欢骆驼壳。虽然这并不能阻止人们就这件事争吵很多。如果你是一致的，那么两者之间也没有太大的区别。

没有大小写的缺点，没有提供任何提示的词从哪里开始，这使得它更难从精神上分析，并可能导致不幸的歧义。

最后，从编程语言的角度来看，这确实不是一个设计选择，而是一个标准库的观点。这似乎是一个愚蠢的区别，但没有什么能真正阻止您构建一个新的标准库并导入它。事实上，在Haskell，人们经常这样做。没有什么可以阻止您使用新的标准库更改约定，因为这样一切都可以保持一致。

Answer 2

在许多语言中，惯例是对类型使用PascalCasing (我能想到的唯一例外是lisps和STL)。使用camelCasing或snake_casing可以方便地以变量的类型命名(如void foo(Bar bar))。

snake_casing也允许这样做。您必须更改更多的字母(删除下划线和去头字母)，但您可以将get_和set_前缀为完整的属性名。有些语言使用这种语言，有些语言使用这种语言。

虽然C#听起来可能会受益于在属性名称(public CustomData customData{get; set;})等方面使用camelCasing，但它必须考虑.NET框架的另一种主要语言-- Visual Basic.NET。VB.NET是不区分大小写的，CustomData、customData和cUstOMdAta之间不能区别。通过使用PascalCased C#，确保在VB.NET中使用C#类时不会发生名称冲突。