作者lion741205 (狮子)
看板Soft_Job
标题Re: [讨论] 大家的命名习惯 - 现有命名方法汇整及比较
时间Sun Aug 18 17:31:43 2019
※ 引述《meokay (我可以)》之铭言：
: 如题
: 现在常常会Review别人的程式码
: 发现大家的命名习惯都好不同
: 举例来说
: 一个Func是Check Status
: 有的人会写 void check_status()
: 也有的人写 void checkStatus()
: 也有看过写 void CStatus()
: 姑且不论第三种
: 那大致上就是分成底线派跟非底线派
: 大家的命名是哪种风格啊？
: 有没有大大愿意分享一下～
: 或是有什麽坚持xDD
: 我先投非底线派一票QQ
命名规则是为了增加识别和可读性，没有强制的规定，但一旦选择其中一种，会建议编写
时统一格式；而化学、天文、生物也有其惯用的命名方法；大部分的程式语言也有对此进
行建议，以统一风格。
在程式设计的命名上，当变数、函式及类别等名称由两个以上的单字组合，就可以使用现
有的命名方法，增加识别和可读性。目前已经出现的命名方法，可以分为Underscore(底
线式)、Camel-case(驼峰式)及Hungarian notation(匈牙利命名法)三大类。此文进行汇
整，并以个人经验，探讨其优缺点。
------
Underscore(底线式)：
------
单字之间使用底线分隔，GNU/Linux环境中最常见，例如：string_name。
优点：使用底线取代空格，阅读上比较直觉易懂。
缺点：比起Camel-case使用字首大写取代空格，底线比较少在日常输入，因此需要适应。
------
Camel-case(驼峰式)：
------
单字之间使用大写分隔，又可以分为Lower Camel-case(小驼峰式)，或Upper
Camel-case(大驼峰式)，而後者又称为Pascal-case(帕斯卡式)。
Lower Camel-case(小驼峰式)：
第一个字母用小写，此变化常用在变数名称上，例如stringName。
Upper Camel-case(大驼峰式)：
第一个字母用大写，此变化常用在函数、类别、属性及命名空间上，例如StringName。
优点：
可以利用名称前缀的大小写，区分变数，以及函数、类别等其他型别。
单字之间使用大写取代底线，能够减少名称的长度，减少程式码超出视窗被遮挡的情况。
缺点：
比起Underscore使用底线取代空格，阅读上较不直觉易懂。
------
Hungarian notation(匈牙利命名法)
------
在Camel-case(驼峰式)的基础上，在名称前缀添加预先约定好的缩写，例如约定如下：
b boolean
c character
str C++ String
si short integer
i integer
li long integer
f floating point
d double-precision floating point
ld long double-precision floating point
sz Old-Style Null Terminated String
if Input File Stream
is Input Stream
of Output File Stream
os Output Stream
S declaring a struct
C declaring a class
Source:
http://web.mst.edu/~cpp/common/hungarian.html
根据缩写用途的不同，又可分为Systems Hungarian，以及Apps Hungarian。
Systems Hungarian：
名称前前缀代表的是实际的资料型别，例如：strName。
Apps Hungarian：
名称前缀代表的是目的或其他提示，例如：usName，其中us代表unsafe，为了避免Code
injection或XSS，之後必须进行过滤处理。
优点：
不需要IDE支援，就能够从名称能看出型别。
制定好的编码规则，能够在搜寻时更加统一易找。
制定好的编码规则，能够在命名及输入上更快。
缺点：
需要另外学习编码规则。
现代IDE已经可以轻易的区分型别，在资料型别上，此方法稍嫌多余。
变数型别修改时，名称也必须修正维护。
采用缩写来命名，对新手较不友善，例如szName，不如stringZeroName。
也更容易造成歧义，例如szName，更容易被误读成其他意思，也难以Google。
--
※ 发信站: 批踢踢实业坊(ptt.cc), 来自: 101.13.41.25 (台湾)
※ 文章网址: https://webptt.com/cn.aspx?n=bbs/Soft_Job/M.1566120705.A.C1F.html
※ 编辑: lion741205 (101.13.41.25 台湾), 08/18/2019 17:52:55
1F：→ EricTCartman: 匈牙利命名对现代IDE有多余吗？ 当有一堆member 08/18 18:05
2F：→ EricTCartman: variable或可选的变数时，我反而会直接从型别类型找 08/18 18:05
3F：→ EricTCartman: szXXX这种C-String命名法 取stringZero我反而会误会 08/18 18:06
4F：推 abc0922001: 我现在也不用匈牙利命名法了 08/18 18:07
5F：→ EricTCartman: 不熟sz的惯用命名 应该只是写得不够多 看得不够多 08/18 18:07
6F：→ EricTCartman: 有些idiom是广为流传 命名就看语言使用者/团队习惯 08/18 18:09
7F：→ EricTCartman: 像pimpl 如果你不懂C++的idiom 当然看不懂 08/18 18:10
嗯，有些约定俗成的缩写，有时候会造成新手混淆，但对老手来说很方便
※ 编辑: lion741205 (101.13.41.25 台湾), 08/18/2019 18:16:13
8F：→ WunoW: 你列的这些约定成俗我都没用过...... 08/18 18:15
9F：→ WunoW: is做input stream...?? 我是都当boolean变数啦 像isValid 08/18 18:16
只是为了讲匈牙利命名找的范例，里面的缩写我也不全用的 XD
10F：→ EricTCartman: if/is/of/os我都看过 这真的看习惯 如果scope不大 08/18 18:18
11F：→ EricTCartman: 我是直接取stream 反正你function不超过20行不会有 08/18 18:19
12F：→ EricTCartman: 困扰 因为型别已经告诉你 08/18 18:19
※ 编辑: lion741205 (101.13.41.25 台湾), 08/18/2019 18:20:50
13F：→ WunoW: 型别我会放後面 像amt/amtStr 这样传json就放在一起了 08/18 18:20
14F：→ EricTCartman: 匈牙利我觉得用在built-in type就好 OOP太多抽象的 08/18 18:21
15F：→ EricTCartman: 东西强迫自己想个有监别性的缩写只是徒增困扰 08/18 18:21
16F：→ WunoW: amount->amt, member->mbr...之类的约定成俗反而更常见 08/18 18:21
17F：→ EricTCartman: member我看到比较多都写m耶 C++啦 WunoW是写哪个语 08/18 18:22
18F：→ EricTCartman: 言？ 08/18 18:22
19F：→ WunoW: 只写m我也看过 但我都会尽量要求缩写也要明确 08/18 18:30
20F：→ WunoW: C和C++派大概是我见过变数名称最懒的... 08/18 18:30
21F：→ WunoW: 不然其实ide有按tab自动完成功能 变数长一点不会麻烦 08/18 18:32
22F：→ WunoW: 但命名明确一点我觉得还是对开发和维护都有好处 08/18 18:34
23F：→ WunoW: 不然专案多人开发 你的m不是我的m 不太好 08/18 18:35
24F：→ EricTCartman: XDDDD 08/18 18:37
25F：推 doranako: 三种我都有用过，大家有共识统一用什麽就用什麽，memb 08/18 19:14
26F：→ doranako: er variable近年多加底线来区分 08/18 19:14
27F：→ LinuxKernel: amt mbr 是啥鬼 08/18 19:42
28F：→ LinuxKernel: 有人的约定俗成不太一样 08/18 19:42
29F：→ jej: 维护老屁股系统 各种命名都会遇到 还能在这挑是幸福啊 08/18 20:25
30F：推 bill0205: 今年初专案的会议结果光是命名规则就讨论快3小时XDD 08/18 20:55
31F：→ bill0205: 最後共识还是驼峰式为主 08/18 20:55
32F：→ EricTCartman: 命名规则竟然能讨论到三个小时 还 满 屌 ㄉ 08/18 21:37
33F：→ MOONY135: svc 我觉得当service的变数不错啊 08/18 21:50
34F：推 steve1012: 能不缩写就不缩写 08/19 03:42
35F：→ shooter555: 我也觉得不缩写的好 以方便看为主 08/19 09:29
36F：→ shooter555: if input file这还真少见 08/19 09:31
37F：→ shooter555: 开头大写的驼峰式也愈来愈常见 因为很多protocol文件 08/19 09:32
38F：→ shooter555: 都是开头大写驼峰式 变数命名也直接照搬 08/19 09:33
39F：→ shooter555: ZoneNameString 这种放後面的也愈来愈常见 08/19 09:34
40F：推 jason710068: 匈牙利命名稍微有碰过win32 api应该都知道在干嘛，但 08/19 09:49
41F：→ jason710068: 可能不知道那个叫匈牙利命名 08/19 09:49
42F：→ eva19452002: 有人说匈牙利命名很难阅读，是真的吗？ 08/19 09:52
我觉得编码约定做得好，能够统一写法，反而有利团队阅读、搜寻和命名，
只是对专案新人或以後接手的人比较不友善，还要另外去了解那些缩写的含意；
比起写清楚讲明白，更容易造成歧义，所以有些书提倡不要使用匈牙利命名法。
44F：→ hooll111: de-72688451 08/19 10:25
45F：推 leveger0903: PHP PSR-2规范是小写开始的驼峰命名 08/19 12:58
46F：→ pttworld: Java派方法也是小写开始驼峰，类别名大写驼峰 08/19 15:03
47F：推 tennyleaz: 能不要缩写就不要用 08/20 12:52
48F：→ ssccg: 缩写只有那个专案原始开发者自以为约定俗成... 08/20 13:44
49F：推 sxy67230: 直接看guideline或是看公司规定，大学生学写code的话， 08/20 13:58
50F：→ sxy67230: 直接看guideline。像google的python guideline 就有写 08/20 13:58
51F：→ sxy67230: 很多原因不推荐的写法。像很多新鲜人喜欢写expect:这样 08/20 13:58
52F：→ sxy67230: 所有的错误都会被忽略掉，所以不推荐这样写。新手不想养 08/20 13:58
53F：→ sxy67230: 出坏习惯就按照guideline 来避免写出乱七八糟的code。 08/20 13:58
54F：推 sxy67230: 所谓的命名也是高手之间约定俗成的写法，除非公司特别规 08/20 14:01
55F：→ sxy67230: 定，要不然就尽量照高手之间的写法，未来管理也会方便一 08/20 14:01
56F：→ sxy67230: 点。 08/20 14:01
57F：推 sxy67230: 还有一点就是变数用缩写尽量避免，原因是像py这种dict是 08/20 14:21
58F：→ sxy67230: 一种宣告型别，我看过一堆人把dict当变数使用。这样虽然 08/20 14:21
59F：→ sxy67230: 可以跑，但是日後管理真的会很混乱，你可以取word_dicti 08/20 14:21
60F：→ sxy67230: onary，但不要用缩写，看得人会很痛苦 08/20 14:21
※ 编辑: lion741205 (49.218.17.17 台湾), 08/20/2019 15:27:33