请问一个新设计的程序语言，是选择 camelCase 好，还是先择 snake_case 好？

[xieyuheng]

大家可能要笑了，这也算问题？

但是其实我是很严肃地在考虑这个问题的。
因为尽管在写代码的时候，用户可以做出选择，
但在语言的文档和标准库中，还是要选择一种命名规范的。
而做这种选择对我来说是很艰难的。

我说的 “新设计的程序语言” 具体是这个： https://github.com/cicada-lang/inet

我刚刚用一个 commit 把 snake_case 改成了 camelCase：

https://github.com/cicada-lang/inet/commit/7625a8ad5f87da1ab9c4fd231fc8142ca8900d79

但是我不确定这样做是 “正确的”。

我能想到的，选择 camelCase 的理由：

（ 1 ）语言已经选择使用 BigCamelCase 作为类型的命名规则了，比如 `DiffList`，
此时如何想要一个变量，直接在这个类型名字前面加上变量的前缀就好了，比如 `emptyDiffList`，
如果用 snake_case ，就需要编辑类型名，而写成 `empty_diff_list`。

（ 2 ）这个语言目前是用 JavaScript/TypeScript 实现的，而 JavaScript 用的是 camelCase 。
并且未来想要用 Zig 再实现一遍，而 Zig 用的也是 camelCase 。

我能想到的，选择 snake_case 的理由：

（ 1 ） snake_case 我个人认为，确实好读一些。

希望大家能给出一些建议。

[NXzCH8fP20468ML5]

我个人倾向 snake_case 。
因为有些时候用 camelCase 比较蛋疼，getId ？ getID ？ getid ？
不过这些都是取舍问题，统一就好。

[wangkun025]

我喜欢后者。因为我用 ruby

[des]

个人倾向于 snake_case

[xieyuheng]

@xxfye 对，camelCase 遇到本身就是大写字母的地方，就有很大歧义。比如 URL JSON ID 之类的。

[xieyuheng]

@wangkun025 我本来也是 snake_case ，我现在也觉得 snake_case 比 camelCase 更易读一点点。

但是作为前端程序员，写了太多太多 JavaScript/TypeScript 了，你懂的。。。

[leonshaw]

缝合一下，下划线分词同时保留原始大小写。URL_encode, get_ID, is_iOS

[usedTo404]

看看 C#的风格，很满足我对微软的想象

[liuguang]

rust 都用小写下划线隔开

[cmdOptionKana]

关键问题：这个语言的目标用户是谁？

如果目标用户明确，那就按照他们的习惯来。如果预估用户不多，那也可以任性一点按自己的喜好来。

[Nazz]

无 gc 就选 snake_case

[NXzCH8fP20468ML5]

如果是面向对象，就遵从 Java ，C#的 camelCase 。
如果是其他的，就用 snake_case 吧。
看你的有点像 lisp 和 Elixir ？

[xieyuheng]

@cmdOptionKana 目前还是一个研究式的东西，但是想未来让这个语言变成一个通用的程序语言。

[paopjian]

我是不喜欢按 shift 键的,很麻烦,都是 ide 自动提示的, 要是语言支持中文,我写中文可能比英文还多
在断句简单时候 camelCase 好,但是全都是大写的时候 snake_case 好点.

[xieyuheng]

@xxfye 我其实是实现了一个新奇的计算模型，叫做 Interaction nets ，感觉不算是面向对象或者函数式编程了。

关于这个语言，之前也有在 V2EX 发过分享： https://www.v2ex.com/t/970898#reply0

[xieyuheng]

@paopjian 是可以支持中文，并且语法关键词之后也可以考虑支持双语的，那就有意思了，哈哈。

[duke807]

snake_case +1024

[BBCCBB]

我喜欢 camelCase

[BBCCBB]

只要语言没限制死. 想驼峰或者下划线都可以..

[hsfzxjy]

变量 snake_case
类型 Snake_Case
/doge

[to2false]

snake_case++++++++1

[xieyuheng]

@hsfzxjy 可惜就是没有主流程序语言是这样用的。

比如 python 是：

变量 snake_case
类型 BigCamelCase

[madku]

camelCase+1

[hsfzxjy]

@xieyuheng 你可以做开创者（ doge ），BigCamelCase 区分度还是不够

[hsfzxjy]

原来 inet 是楼主做的，之前就 star 了

[purensong]

我想法是都支持，不要让用户做选择了，成年人全都要

[cy18]

变量、函数、类，使用不同的方式吧？

[loading]

建议你参考一下 go fmt

[chaleaochexist]

camelCase
这样的有点是能稍微短一些.

[yolee599]

C# 那种比较好

[otakustay]

不是工作必须的话，我一般是不碰 snake_case 的语言的

[z1645444]

以前很喜欢 camelCase ，最近开始比较倾向 snake_case ，所以 snake_case 投一票

[xieren58]

建议参考 rust...

[Jwyt]

个人喜欢 snake_case

[runze]

@xieyuheng #21
zig 就是：camelCaseFunctionName, TitleCaseTypeName, snake_case_variable_name 。

你想要未来换成 zig 实现，为什么不像 zig 一样“我全都要”呢？

[Aloento]

pascal 路过

[hcr707305003]

这种应该是看场景使用，你这种使用 snake_case 会比较好点

[flyqie]

个人喜欢 snake_case 。

[Daniel17]

我觉得 snake_case 更清晰一点

[ychost]

c/c++ 喜欢用 snake_case ，其余的 Java/Js/C# 喜欢用 camelCase

[ipcjs]

类型用 PascalCase
变量用 camelCase

你看新出的语言，有几个还在主用 snake_case 的？

[xieyuheng]

@ipcjs 确实，Zig 就是你说的这样。

[uni]

@ipcjs rust 就是 snake_case 啊

[dcsuibian]

camelCase
python 规范就是应该用 snake_case 的，但我就看到了大量使用 camelCase 的人。比如 opencv 的 cv2.waitKey(0)
相反来说在 java 、javascript 里我就很少见到要使用 snake_case 的人

[ye4241]

我是 C# 开发用 PascalCase 和 camelCase ，但是我也喜欢 Python 的 snake_case ，很多时候 camelCase 显得特别难，比如很多本来就是缩写的词汇，UI ，是用 uI 还是 UI 呢？在 python 里面 ui 小写看着也挺顺的。所以在 C#中，我一般会写全，规避缩写，userInterface ，就没啥太大问题了。

[yougg]

个人从输入偷懒角度看选择 camelCase
_c 需要按键 3 次
C 只用按键 2 次
而且按 Shift 和 _ 时右手挪动范围更大，位置稍偏，出错概率更大

[xieyuheng]

@dcsuibian 在 JS 项目里用 snake_case 我只知道一个例子，那就是 svelte 。

比如： https://github.com/sveltejs/svelte/blob/master/packages/svelte/src/compiler/compile/nodes/Element.js

[kiroter]

_ 这个我觉得写代码的时候，要两手一起按不爽

[James369]

业务型软件 camelCase ，技术型软件 snake_case

[placeholder]

我投 snake_case 一票

[chendy]

随便啥都行
下划线的问题是，如果只有一个中文输入法，按 shift 没按明白会切中英文然后难受一下
驼峰的问题是，习惯 shift 的话和下划线一样，习惯 caps lock 的（虽然不理解但是真有不少人这么干…）切起来很麻烦

[IvanLi127]

如果是做语言并且有官方限制的话，那应该就是选 snake_case 了，这种基本上可以肯定，比别的不容易出问题。

[Al0rid4l]

@runze Zig 可太草了, 昨天还看到有人吐槽

https://www.reddit.com/r/Zig/comments/16him8q/name_casing_in_zig_snake_case_camelcase/

[Al0rid4l]

考虑到写得爽, 投 camelCase

camelCase 只要按 shift
snake_case 要 shift + - 就很累

[rekulas]

下划线可读性稍微高一点
我选驼峰,因为下划线稍微多几个词 看起来就很怪且 low 的感觉
至于大小写问题感觉还好,有些词是固定大小写的,就应该按它本身的来书写
比如 getPHPUsers 而不是 getPhpUsers

[wipbssl]

更习惯 snake_case

[xieyuheng]

@rekulas 你这个 “很怪且 low 的感觉”我觉得确实是有一些。

比如商标都选择：

YouTube
GitHub
iPhone
eBay

而不是

you_tube
git_hub
i_phone
e_bay

[libook]

看语言、数据库等兼容性，比如有的语言核心库都是遵照某种风格的，或者有的数据库只支持某种风格，就尽量追求统一。

之前一种说法是，驼峰能少按键。

但归根结底还是看喜好。

我之前写 JS ，一种风格是变量用小驼峰，常量全大写+下划线，类型大驼峰。不同风格代表不同信息。

[libook]

用驼峰的话，大写只是为了断词所以可以统一规定缩写也一律按照首字母大写其他字母小写的规则。

[yazinnnn]

用-分割的叫啥类别？

[cnbatch]

其实没什么好不好的，全凭作者喜好而定

[hronro]

zig 也不是 camelCase ，而是两种命名混用：普通变量用 snake_case ，类型、函数之类的用 CamelCase 。

[liberize]

现在用 camelCase 的投 snake_case 一票，类名也可以同样 snake_case ，参考 c++ stl

[Leviathann]

@yazinnnn 烤串 kebab

[forgottencoast]

@ye4241 44#
C#里面你说的这个缩写词规范（《框架设计指南》）里面也是有涉及到的。
除了几个特别约定的，比如 Id ，其它都是全大写，比如 URL 。

[iorilu]

不是什么样式问题

关键大小写要统一

普通变量全小写

常量全大写

就这么简单

所以还是 snake case ，python 这种风格更合理

[Jakarta]

@dcsuibian 因为 opencv 是写 cpp 的人写的

[magicdawn]

snake_case 确实易读性强一点

[AItsuki]

snake_case 不二之选

[zhangxzh]

有些语言没有大小写, 像中文, 这么说可能有人也会笑, 但我有时也用中文写代码, 表达更清楚, 这时下划线就很好.

另外为什么不能是 'A-A' 或其他的连词形式呢, 毕竟下划线要多按一个 shift

[Torpedo]

snake_case 有点丑。但是比驼峰实用。

[SHF]

我喜欢 snake_case ，驼峰字母高高低低太恶心了

[Tanix2]

选 snake_case ，易读性好太多。至于有人说输入下划线比较麻烦，我的想法是，变量的命名通常只需要第一次打全，之后都是自动补全，所以并不会有太大差别。并且写熟悉后，用下划线会觉得很有节奏感，因为下划线就像平时打英文句子的空格一样。

[AyanamiAsuka]

一个好读一个好写，我大部分时间在读代码，所以我希望大家都用 snake_case

[n1cogrv]

@yazinnnn #59
@usedTo404 #7

微软的想象？ M$要把 PowerShell 里面用 "-" 分割的尿性带到他们家别的编程语言上，我感觉那才叫末日...
snake_case.replace("_", "-").toPascalCase() -> Powershell-Case

用"-"分隔的叫 Kebab Case ，但是人家是纯小写的(e.g., kebab-case)。混上 PascalCase ，恕我孤陋寡闻，PowerShell 算是独一份。每次打这玩意我都血压拉满。

[ooops]

@xieyuheng 商标这种不能分开，不分开的情况下也还行。youtube github iphone ebay ipad

[xieyuheng]

@ooops 对的，机会没有商标和域名会用下划线。

[xieyuheng]

* 机会/几乎

[xieyuheng]

@rekulas

> 至于大小写问题感觉还好,有些词是固定大小写的,就应该按它本身的来书写
> 比如 getPHPUsers 而不是 getPhpUsers

这个很有道理，感觉解决了我的选择困难。

而且你说的这个在 Scala 的命名规范中也有提到：

https://docs.scala-lang.org/style/naming-conventions.html

英雄所见略同了，属于是。

[xieyuheng]

啊不对，你这个刚好的 Scala 相反，哈哈哈，不好意思我看错了。

Scala 说的是 “Acronyms should be treated as normal words”

看来命名规则这个领域，还是真是分仁者见仁智者见智。

[xieyuheng]

@libook

> 用驼峰的话，大写只是为了断词所以可以统一规定缩写也一律按照首字母大写其他字母小写的规则。

是这条回复和 Scala 的一样，
同时又说出了为什么，
因为大写只是为了断词。

而 Scala 只是说“Acronyms should be treated as normal words”

[xieyuheng]

我发现，在英文药品的包装上，
还会用到所谓 Tall-Man Letters ，
来强调相似药品名的差异。

https://en.wikipedia.org/wiki/Tall_Man_lettering

比如：

acetaZOLAMIDE vs. acetoHEXAMIDE
buPROPion vs. busPIRone
chlorproMAZINE vs. chlorproPAMIDE
clomiPHENE vs. clomiPRAMINE
cycloSERINE vs. cycloSPORINE
DAUNOrubicin vs. DOXOrubicin
DOBUTamine vs. DOPamine
hydrALAzine vs. hydrOXYzine
TOLAZamide vs. TOLBUTamide
vinBLAStine vs. vinCRIStine

[zxCoder]

拒绝下划线，拒绝 c/c++

[zhanglintc]

@Nazz #10 这个怎么讲，为啥跟 GC 还有关系？

[nikenidage1]

@forgottencoast
是的，推荐大家都看看这本书，最近也刚出了第三版
很大一部分内容其实语言无关
《框架设计指南：构建可复用.NET 库的约定、惯例与模式（第 3 版）》
https://book.douban.com/subject/36308103/

[MeteorCat]

驼峰在有些版本控制的 window 平台切换下大小写会发现都是奇奇怪怪的

[forgottencoast]

@nikenidage1
OP 说的这个主题其实和语言无关对吧，你用什么方式来写变量名、类名对编译器来说都是无感的。
这其实就这本书题目中的约定、惯例。

[shaoyie]

最好是 snake_case
考虑以下因素，能保证整体统一
1. 文件名，包名，路径等
2. 类名，函数名，变量名

如果是 linux 下，你发现 shell ，libc syscall 都是小写为主，比如你在命令行里边找个文件，如果一路按着 shift 过去就很麻烦，文件名是 snake_case 了 包名自然也就是一样的了，
那这样继续推理下去，包名是 snake_case ，代码里边你如果用 camelCase ，岂不是有些乱？

我就不喜欢 google c/c++ code style ，因为 syscall, libc, stl, boost 都是小写的，你项目用 camelCase ，代码看着真丑。不知道咋想的

还有 rust 的风格，也是混杂的

[shaoyie]

https://github.com/cicada-lang/inet/tree/master/src/utils
https://github.com/cicada-lang/inet/tree/master/src/loader
https://github.com/cicada-lang/inet/tree/master/src/app
光文件名，这 1 个项目就已经存在 3 种风格了

[netabare]

个人喜好是 camelCase 或者 PascalCase ，不过还是觉得造语言的时候 case 是不重要的事情，这个更多是根据社区的习惯来的吧。

比如说一般来说 C++社区也会有一些特定领域和类库会习惯用 PascalCase 。

（然后印象比较深刻的是 OCaml 社区在类名上用 camel 而不是 Pascal ）

[Nazz]

@zhanglintc 习惯

[LK99]

@xieyuheng getIphoneUsers? getiPhoneUsers? getIPhoneUsers?
#78

[james122333]

能的话我会写 snake case 至于按键问题 就是为何要用 vi 类编辑器的原因 绑定插入时的键位 其它命令行状况 bash 也可以绑定键位 甚至可绑定某键位打开编辑器（ EDITOR 环境变量）编辑当前命令储存后执行命令 这个在输入多行命令的时后非常好用

[james122333]

承接以上 还有这是为何 vi 类的要整成秒开的原因 装一堆插件打开很卡

[MrSheng]

没有中文文档都不知道是做啥的。