※ 引述《meokay (我可以)》之铭言：
: 如题
: 现在常常会Review别人的程式码
: 发现大家的命名习惯都好不同
: 举例来说
: 一个Func是Check Status
: 有的人会写 void check_status()
: 也有的人写 void checkStatus()
: 也有看过写 void CStatus()
: 姑且不论第三种
: 那大致上就是分成底线派跟非底线派
: 大家的命名是哪种风格啊？
: 有没有大大愿意分享一下～
: 或是有什么坚持xDD
: 我先投非底线派一票QQ
命名规则是为了增加识别和可读性，没有强制的规定，但一旦选择其中一种，会建议编写
时统一格式；而化学、天文、生物也有其惯用的命名方法；大部分的程式语言也有对此进
行建议，以统一风格。
在程式设计的命名上，当变量、函式及类别等名称由两个以上的单字组合，就可以使用现
有的命名方法，增加识别和可读性。目前已经出现的命名方法，可以分为Underscore(底
线式)、Camel-case(驼峰式)及Hungarian notation(匈牙利命名法)三大类。此文进行汇
整，并以个人经验，探讨其优缺点。

匈牙利命名对现代IDE有多余吗？ 当有一堆membervariable或可选的变量时，我反而会直接从型别类型找szXXX这种C-String命名法 取stringZero我反而会误会

我现在也不用匈牙利命名法了

不熟sz的惯用命名 应该只是写得不够多 看得不够多有些idiom是广为流传 命名就看语言使用者/团队习惯像pimpl 如果你不懂C++的idiom 当然看不懂

你列的这些约定成俗我都没用过......is做input stream...?? 我是都当boolean变量啦 像isValid

if/is/of/os我都看过 这真的看习惯 如果scope不大我是直接取stream 反正你function不超过20行不会有困扰 因为型别已经告诉你

型别我会放后面 像amt/amtStr 这样传json就放在一起了

匈牙利我觉得用在built-in type就好 OOP太多抽象的东西强迫自己想个有鉴别性的缩写只是徒增困扰

amount->amt, member->mbr...之类的约定成俗反而更常见

member我看到比较多都写m耶 C++啦 WunoW是写哪个语言？

只写m我也看过 但我都会尽量要求缩写也要明确C和C++派大概是我见过变量名称最懒的...不然其实ide有按tab自动完成功能 变量长一点不会麻烦但命名明确一点我觉得还是对开发和维护都有好处不然专案多人开发 你的m不是我的m 不太好

XDDDD

三种我都有用过，大家有共识统一用什么就用什么，member variable近年多加底线来区分

amt mbr 是啥鬼有人的约定俗成不太一样

维护老屁股系统 各种命名都会遇到 还能在这挑是幸福啊

今年初专案的会议结果光是命名规则就讨论快3小时XDD最后共识还是驼峰式为主

命名规则竟然能讨论到三个小时 还 满 屌 ㄉ

svc 我觉得当service的变量不错啊

能不缩写就不缩写

我也觉得不缩写的好 以方便看为主if input file这还真少见开头大写的驼峰式也愈来愈常见 因为很多protocol文件都是开头大写驼峰式 变量命名也直接照搬ZoneNameString 这种放后面的也愈来愈常见

匈牙利命名稍微有碰过win32 api应该都知道在干嘛，但可能不知道那个叫匈牙利命名

有人说匈牙利命名很难阅读，是真的吗？

https://www.slideshare.net/mobile/kylinfish/clean-code-72688451

PHP PSR-2规范是小写开始的驼峰命名

Java派方法也是小写开始驼峰，类别名大写驼峰

能不要缩写就不要用

缩写只有那个专案原始开发者自以为约定俗成...

直接看guideline或是看公司规定，大学生学写code的话，直接看guideline。像google的python guideline 就有写很多原因不推荐的写法。像很多新鲜人喜欢写expect:这样所有的错误都会被忽略掉，所以不推荐这样写。新手不想养出坏习惯就按照guideline 来避免写出乱七八糟的code。所谓的命名也是高手之间约定俗成的写法，除非公司特别规定，要不然就尽量照高手之间的写法，未来管理也会方便一点。