
1 NXzCH8fP20468ML5 2023-09-16 12:33:04 +08:00 我个人倾向 snake_case 。 因为有些时候用 camelCase 比较蛋疼,getId ? getID ? getid ? 不过这些都是取舍问题,统一就好。 |
2 wangkun025 2023-09-16 12:36:18 +08:00 我喜欢后者。因为我用 ruby |
3 des 2023-09-16 12:36:20 +08:00 个人倾向于 snake_case |
4 xieyuheng OP @xxfye 对,camelCase 遇到本身就是大写字母的地方,就有很大歧义。比如 URL JSON ID 之类的。 |
5 xieyuheng OP @wangkun025 我本来也是 snake_case ,我现在也觉得 snake_case 比 camelCase 更易读一点点。 但是作为前端程序员,写了太多太多 Javascript/TypeScript 了,你懂的。。。 |
6 leonshaw 2023-09-16 12:43:29 +08:00 via Android 缝合一下,下划线分词同时保留原始大小写。URL_encode, get_ID, is_iOS |
7 usedTo404 2023-09-16 12:45:59 +08:00 看看 C#的风格,很满足我对微软的想象 |
8 liuguang 2023-09-16 12:51:46 +08:00 rust 都用小写下划线隔开 |
9 cmdOptionKana 2023-09-16 12:52:01 +08:00 关键问题:这个语言的目标用户是谁? 如果目标用户明确,那就按照他们的习惯来。如果预估用户不多,那也可以任性一点按自己的喜好来。 |
10 Nazz 2023-09-16 12:53:35 +08:00 via Android 无 gc 就选 snake_case |
11 NXzCH8fP20468ML5 2023-09-16 12:55:52 +08:00 如果是面向对象,就遵从 Java ,C#的 camelCase 。 如果是其他的,就用 snake_case 吧。 看你的有点像 lisp 和 Elixir ? |
12 xieyuheng OP @cmdOptionKana 目前还是一个研究式的东西,但是想未来让这个语言变成一个通用的程序语言。 |
13 paopjian 2023-09-16 12:58:17 +08:00 我是不喜欢按 shift 键的,很麻烦,都是 ide 自动提示的, 要是语言支持中文,我写中文可能比英文还多 在断句简单时候 camelCase 好,但是全都是大写的时候 snake_case 好点. |
14 xieyuheng OP @xxfye 我其实是实现了一个新奇的计算模型,叫做 Interaction nets ,感觉不算是面向对象或者函数式编程了。 关于这个语言,之前也有在 V2EX 发过分享: t/970898#reply0 |
16 duke807 2023-09-16 13:02:38 +08:00 via Android snake_case +1024 |
17 BBCCBB 2023-09-16 13:20:13 +08:00 |
18 BBCCBB 2023-09-16 13:21:05 +08:00 只要语言没限制死. 想驼峰或者下划线都可以.. |
19 hsfzxjy 2023-09-16 13:23:13 +08:00 via Android 变量 snake_case 类型 Snake_Case /doge |
20 to2false 2023-09-16 13:24:54 +08:00 snake_case++++++++1 |
21 xieyuheng OP |
22 madku 2023-09-16 13:32:55 +08:00 via Android camelCase+1 |
24 hsfzxjy 2023-09-16 13:35:49 +08:00 via Android 原来 inet 是楼主做的,之前就 star 了 |
25 purensong 2023-09-16 13:38:48 +08:00 我想法是都支持,不要让用户做选择了,成年人全都要 |
26 cy18 2023-09-16 13:40:23 +08:00 变量、函数、类,使用不同的方式吧? |
27 loading 2023-09-16 13:41:51 +08:00 via iPhone 建议你参考一下 go fmt |
28 chaleaochexist 2023-09-16 13:42:15 +08:00 camelCase 这样的有点是能稍微短一些. |
29 yolee599 2023-09-16 13:44:24 +08:00 via Android C# 那种比较好 |
30 otakustay 2023-09-16 13:46:57 +08:00 不是工作必须的话,我一般是不碰 snake_case 的语言的 |
31 z1645444 2023-09-16 14:30:42 +08:00 via Android 以前很喜欢 camelCase ,最近开始比较倾向 snake_case ,所以 snake_case 投一票 |
32 xieren58 2023-09-16 14:31:52 +08:00 建议参考 rust... |
33 Dockerfile 2023-09-16 15:09:40 +08:00 个人喜欢 snake_case |
34 runze 2023-09-16 15:15:53 +08:00 @xieyuheng #21 zig 就是:camelCaseFunctionName, TitleCaseTypeName, snake_case_variable_name 。 你想要未来换成 zig 实现,为什么不像 zig 一样“我全都要”呢? |
35 Aloento 2023-09-16 15:17:00 +08:00 pascal 路过 |
36 hcr707305003 2023-09-16 15:21:14 +08:00 这种应该是看场景使用,你这种使用 snake_case 会比较好点 |
37 flyqie 2023-09-16 15:21:42 +08:00 via Android 个人喜欢 snake_case 。 |
38 Daniel17 2023-09-16 15:37:15 +08:00 我觉得 snake_case 更清晰一点 |
39 ychost 2023-09-16 15:41:00 +08:00 c/c++ 喜欢用 snake_case ,其余的 Java/Js/C# 喜欢用 camelCase |
40 ipcjs 2023-09-16 15:50:27 +08:00 类型用 PascalCase 变量用 camelCase 你看新出的语言,有几个还在主用 snake_case 的? |
43 dcsuibian 2023-09-16 16:01:09 +08:00 camelCase python 规范就是应该用 snake_case 的,但我就看到了大量使用 camelCase 的人。比如 opencv 的 cv2.waitKey(0) 相反来说在 java 、Javascript 里我就很少见到要使用 snake_case 的人 |
44 ye4241 2023-09-16 16:07:36 +08:00 我是 C# 开发用 PascalCase 和 camelCase ,但是我也喜欢 Python 的 snake_case ,很多时候 camelCase 显得特别难,比如很多本来就是缩写的词汇,UI ,是用 uI 还是 UI 呢?在 python 里面 ui 小写看着也挺顺的。所以在 C#中,我一般会写全,规避缩写,userInterface ,就没啥太大问题了。 |
45 yougg 2023-09-16 16:08:28 +08:00 via Android 个人从输入偷懒角度看选择 camelCase _c 需要按键 3 次 C 只用按键 2 次 而且按 Shift 和 _ 时右手挪动范围更大,位置稍偏,出错概率更大 |
46 xieyuheng OP @dcsuibian 在 JS 项目里用 snake_case 我只知道一个例子,那就是 svelte 。 比如: https://github.com/sveltejs/svelte/blob/master/packages/svelte/src/compiler/compile/nodes/Element.js |
47 kiroter 2023-09-16 16:15:12 +08:00 _ 这个我觉得写代码的时候,要两手一起按不爽 |
48 James369 2023-09-16 16:22:35 +08:00 业务型软件 camelCase ,技术型软件 snake_case |
49 placeholder 2023-09-16 16:23:17 +08:00 我投 snake_case 一票 |
50 chendy 2023-09-16 16:25:53 +08:00 随便啥都行 下划线的问题是,如果只有一个中文输入法,按 shift 没按明白会切中英文然后难受一下 驼峰的问题是,习惯 shift 的话和下划线一样,习惯 caps lock 的(虽然不理解但是真有不少人这么干…)切起来很麻烦 |
51 IvanLi127 2023-09-16 16:36:06 +08:00 via Android 如果是做语言并且有官方限制的话,那应该就是选 snake_case 了,这种基本上可以肯定,比别的不容易出问题。 |
52 Al0rid4l 2023-09-16 16:38:52 +08:00 |
53 Al0rid4l 2023-09-16 16:42:23 +08:00 考虑到写得爽, 投 camelCase camelCase 只要按 shift snake_case 要 shift + - 就很累 |
54 rekulas 2023-09-16 16:49:36 +08:00 下划线可读性稍微高一点 我选驼峰,因为下划线稍微多几个词 看起来就很怪且 low 的感觉 至于大小写问题感觉还好,有些词是固定大小写的,就应该按它本身的来书写 比如 getPHPUsers 而不是 getPhpUsers |
55 wipbssl 2023-09-16 16:50:43 +08:00 更习惯 snake_case |
56 xieyuheng OP |
57 libook 2023-09-16 17:09:14 +08:00 via Android 看语言、数据库等兼容性,比如有的语言核心库都是遵照某种风格的,或者有的数据库只支持某种风格,就尽量追求统一。 之前一种说法是,驼峰能少按键。 我之前写 JS ,一种风格是变量用小驼峰,常量全大写+下划线,类型大驼峰。不同风格代表不同信息。 |
58 libook 2023-09-16 17:11:01 +08:00 via Android 用驼峰的话,大写只是为了断词所以可以统一规定缩写也一律按照首字母大写其他字母小写的规则。 |
59 yazinnnn 2023-09-16 17:54:52 +08:00 via Android 用-分割的叫啥类别? |
60 cnbatch 2023-09-16 17:57:15 +08:00 其实没什么好不好的,全凭作者喜好而定 |
61 hronro 2023-09-16 18:06:15 +08:00 via Android zig 也不是 camelCase ,而是两种命名混用:普通变量用 snake_case ,类型、函数之类的用 CamelCase 。 |
62 liberize 2023-09-16 18:34:19 +08:00 via Android 现在用 camelCase 的投 snake_case 一票,类名也可以同样 snake_case ,参考 c++ stl |
63 Leviathann 2023-09-16 18:58:56 +08:00 @yazinnnn 烤串 kebab |
64 forgottencoast 2023-09-16 19:28:39 +08:00 |
65 iorilu 2023-09-16 19:43:01 +08:00 不是什么样式问题 关键大小写要统一 普通变量全小写 常量全大写 就这么简单 所以还是 snake case ,python 这种风格更合理 |
67 magicdawn 2023-09-16 20:09:42 +08:00 snake_case 确实易读性强一点 |
68 AItsuki 2023-09-16 21:52:03 +08:00 snake_case 不二之选 |
69 zhangxzh 2023-09-16 22:12:28 +08:00 有些语言没有大小写, 像中文, 这么说可能有人也会笑, 但我有时也用中文写代码, 表达更清楚, 这时下划线就很好. 另外为什么不能是 'A-A' 或其他的连词形式呢, 毕竟下划线要多按一个 shift |
70 Torpedo 2023-09-16 22:22:42 +08:00 snake_case 有点丑。但是比驼峰实用。 |
71 SHF 2023-09-16 22:48:44 +08:00 我喜欢 snake_case ,驼峰字母高高低低太恶心了 |
72 Tanix2 2023-09-17 00:00:27 +08:00 选 snake_case ,易读性好太多。至于有人说输入下划线比较麻烦,我的想法是,变量的命名通常只需要第一次打全,之后都是自动补全,所以并不会有太大差别。并且写熟悉后,用下划线会觉得很有节奏感,因为下划线就像平时打英文句子的空格一样。 |
73 AyanamiAsuka 2023-09-17 00:13:57 +08:00 一个好读一个好写,我大部分时间在读代码,所以我希望大家都用 snake_case |
74 n1cogrv 2023-09-17 00:55:09 +08:00 |
77 xieyuheng OP * 机会/几乎 |
78 xieyuheng OP @rekulas > 至于大小写问题感觉还好,有些词是固定大小写的,就应该按它本身的来书写 > 比如 getPHPUsers 而不是 getPhpUsers 这个很有道理,感觉解决了我的选择困难。 而且你说的这个在 Scala 的命名规范中也有提到: https://docs.scala-lang.org/style/naming-conventions.html 英雄所见略同了,属于是。 |
79 xieyuheng OP 啊不对,你这个刚好的 Scala 相反,哈哈哈,不好意思我看错了。 Scala 说的是 “Acronyms should be treated as normal words” 看来命名规则这个领域,还是真是分仁者见仁智者见智。 |
80 xieyuheng OP @libook > 用驼峰的话,大写只是为了断词所以可以统一规定缩写也一律按照首字母大写其他字母小写的规则。 是这条回复和 Scala 的一样, 同时又说出了为什么, 因为大写只是为了断词。 而 Scala 只是说“Acronyms should be treated as normal words” |
81 xieyuheng OP 我发现,在英文药品的包装上, 还会用到所谓 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 |
82 zxCoder 2023-09-17 11:46:11 +08:00 拒绝下划线,拒绝 c/c++ |
83 zhanglintc 2023-09-17 12:02:11 +08:00 @Nazz #10 这个怎么讲,为啥跟 GC 还有关系? |
84 liuliuliuliu PRO @forgottencoast 是的,推荐大家都看看这本书,最近也刚出了第三版 很大一部分内容其实语言无关 《框架设计指南:构建可复用.NET 库的约定、惯例与模式(第 3 版)》 https://book.douban.com/subject/36308103/ |
85 MeteorCat 2023-09-17 13:24:54 +08:00 via Android 驼峰在有些版本控制的 window 平台切换下大小写会发现都是奇奇怪怪的 |
86 forgottencoast 2023-09-17 14:09:29 +08:00 |
87 shaoyie 2023-09-17 15:19:50 +08:00 最好是 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 的风格,也是混杂的 |
88 shaoyie 2023-09-17 15:24:18 +08:00 |
89 netabare 2023-09-17 15:46:36 +08:00 个人喜好是 camelCase 或者 PascalCase ,不过还是觉得造语言的时候 case 是不重要的事情,这个更多是根据社区的习惯来的吧。 比如说一般来说 C++社区也会有一些特定领域和类库会习惯用 PascalCase 。 (然后印象比较深刻的是 OCaml 社区在类名上用 camel 而不是 Pascal ) |
90 Nazz 2023-09-17 16:10:56 +08:00 via Android @zhanglintc 习惯 |
92 james122333 2023-09-18 06:24:55 +08:00 via Android 能的话我会写 snake case 至于按键问题 就是为何要用 vi 类编辑器的原因 绑定插入时的键位 其它命令行状况 bash 也可以绑定键位 甚至可绑定某键位打开编辑器( EDITOR 环境变量)编辑当前命令储存后执行命令 这个在输入多行命令的时后非常好用 |
93 james122333 2023-09-18 06:28:01 +08:00 via Android 承接以上 还有这是为何 vi 类的要整成秒开的原因 装一堆插件打开很卡 |
94 LieNoWell 2023-09-18 09:10:22 +08:00 没有中文文档都不知道是做啥的。 |