作者fatalfeel2 (风在动)
看板C_and_CPP
标题Re: [讨论] 前辈们变数都怎麽命名2?
时间Fri Mar 17 12:04:16 2023
Linux Coding Style
https://docs.kernel.org/next/translations/zh_TW/process/coding-style.html
第3段
大括号 为何 function 与 判断式会不同
Linus 本人给出的理由是 function 中不会包着function
即没有巢状式的function 而判断式中会包着判断式
另一点文中提到的 K&R coding style 也是function与判断式不同
新型的K&R style function 与 判断式的左括号统一了
https://gist.github.com/jesseschalken/0f47a2b5a738ced9c845
再来就是自C++11 之後 Function 内可以包着Function
EX: lambdas 表示式
https://stackoverflow.com/questions/4324763/can-we-have-functions-inside-functions-in-c
!!!上述原因 目前的 C++ [判断式的左括号] 已无规范必要!!!
判断式的左括号 在行尾或下一行皆可
///////////////////linux coding style///////////////
1) 缩进
制表符是 8 个字符，所以缩进也是 8 个字符。有些异端运动试图将缩进变爲 4
(甚至 2！) 字符深，这几乎相当於尝试将圆周率的值定义爲 3。
理由：缩进的全部意义就在於清楚的定义一个控制块起止於何处。尤其是当你盯着你的
屏幕连续看了 20 小时之後，你将会发现大一点的缩进会使你更容易分辨缩进。
2)
...略
3) 大括号和空格的放置
C 语言风格中另外一个常见问题是大括号的放置。和缩进大小不同，选择或弃用某种放
置策略并没有多少技术上的原因，不过首选的方式，就像 Kernighan 和 Ritchie 展示
给我们的，是把起始大括号放在行尾，而把结束大括号放在行首，所以：
if (x is true) {
we do y
}
不过，有一个例外，那就是函数：函数的起始大括号放置於下一行的开头，所以：
int function(int x)
{
body of function
}
全世界的异议份子可能会抱怨这个不一致性是… 是的 … 不一致的，不过所有思维健全
的人 都知道
(a) K&R 是 正确的 并且 (b) K&R 是正确的。
此外，不管怎样函数都是特 殊的 (C 函数是不能嵌套的)。
当只有一个单独的语句的时候，不用加不必要的大括号。
if (condition)
action();
和
if (condition)
do_this();
else
do_that();
※ 引述《fatalfeel2 (风在动)》之铭言：
: 程式命名规则 与 Makefile
: 1. 查阅了 ISO 1999 C99, ISO 2011 C++, ISO 2014 C++, ISO 2020 C++,
: https://reurl.cc/gZGz6L
: https://reurl.cc/XLGlq0
: ISO都有基本的命名规则
: 另查阅 微软 安卓 程式规范
: 微软 的 命名规则偏向 The Hungarian Naming Convention
: 由2001 制定完整规范, prefix 如ch, sz, p
: https://idleloop.com/hungarian/
: 2. variable prefix naming convention 一定是正确的吗?
: (a)
: 北美电网程式规范与openPDC 首席设计师 James Ritchie Carroll
: https://www.gridprotectionalliance.org/docs/GPA_Coding_Guidelines_2011_03.pdf
: Page 12 原文贴上
: Do not use Hungarian notation
: Do not abbreviate
: Do not prefix enums, classes, or delegates with any letter
: (b)
: Linux核心的创始者 开源专案Git创始者 Linus Torvalds
: https://www.kernel.org/doc/html/v4.10/process/coding-style.html
: https://slurm.schedmd.com/coding_style.pdf
: 第四章 原文贴上
: Encoding the type of a function into the name (so-called Hungarian notation)
: is brain damaged - the compiler knows the types anyway and can check those,
: and it only confuses the programmer. No wonder MicroSoft makes buggy programs.
: (注意一下这两位大神coding在意的重点是什麽)
: 3.
: GNU MAKE
: https://www.gnu.org/software/make/manual/make.html
: #dir named with www.gnu.org/software/make/manual/make.html 4.3 16.3 16.5
: SRCDIR = ./source
: OBJDIR = ./obj
: BINDIR = ./bin
: #compile optione with www.gnu.org/software/make/manual/make.html 4.3 16.3 16.5
: $(OBJDIR)/%.o : ./$(SRCDIR)/%.cpp
: $(CXX) -c $(CXXFLAGS) $< -o $@
: #Note: CPPFLAGS at www.gnu.org/software/make/manual/make.html 10.3
: CC
: Program for compiling C programs; default ‘cc’.
: CXX
: Program for compiling C++ programs; default ‘g++’.
: CPPFLAGS
: Extra flags to give to the C preprocessor and programs that use it (the
: C and Fortran compilers).
: CXXFLAGS
: Extra flags to give to the C++ compiler.
: ※ 引述《heaviest (heaviest)》之铭言：
: : 最近开始学C，刚刚把前几天写的程式，打开来看
: : 发现变数一时之间完全搞不清楚
: : 明明当初有尽力的取有意义的名称，然後照着大写来分开字这样打
: : 跑去问了学长，他叫我去背单字，他说变数名字取不出来是我单字被太少QQ
: : 请问各位前辈们都怎麽取有意义的名字
--
※ 发信站: 批踢踢实业坊(ptt.cc), 来自: 114.32.93.159 (台湾)
※ 文章网址: https://webptt.com/cn.aspx?n=bbs/C_and_CPP/M.1679025860.A.E70.html
1F：推 stallings: 关於缩排，我比较接受 4 个空格 03/17 15:09
2F：→ stallings: 8 个空格我觉得过多了。至於用 tab？嗯... 03/17 15:09
3F：→ stallings: 关於区块，现在好像有人提倡 03/17 15:09
4F：→ stallings: 即使只有一行也加括号以使程式码清楚 03/17 15:09
5F：→ tomsawyer: vscode的linter会把if弄成大括号跟函数一样 03/17 16:10
6F：推 closer76: Google open-source style 是 2 空格.... 我一开始不习 03/17 16:43
7F：→ closer76: 惯，但用了一段时间觉得也还不错。 XD 03/17 16:43
8F：推 Lipraxde: 比起缩几格，不要搞成五、六层巢状比较舒服 03/17 17:59
9F：推 chuegou: 最後一个就防呆来说不好 misra规范就强制要加大括号 苹 03/17 21:12
10F：→ chuegou: 果的goto fail某种程度上也是因为没加大括号 03/17 21:12
11F：推 stallings: 没在写 Linux kernel code 就不用理那些了 03/17 22:14
12F：推 mmmmei: 大括号我们组要求要新的一行。理由是这样比较容易看出一 03/18 07:27
13F：→ mmmmei: 个clause从哪里开始的 03/18 07:27
14F：推 johnjohnlin: 用一个tab缩排就能同时满足2 4 8空白三种需求 03/18 10:37
15F：→ fatalfeel2: 有些ide tab 可以设定 字元数 03/18 19:23
※ 编辑: fatalfeel2 (218.187.80.32 台湾), 03/18/2023 19:24:46
16F：推 stallings: 不定宽度正是 tab 的短处啊 03/18 21:25
17F：→ stallings: 唯一支持 sp～叭叭叭～ 03/18 21:25
※ 编辑: fatalfeel2 (218.187.80.32 台湾), 03/19/2023 06:27:11
18F：推 CoNsTaR: 我都去找算命的算变数名称，这样以後程式有 bug 他比较好 03/19 14:00
19F：→ CoNsTaR: 通灵 03/19 14:00
20F：→ Caesar08: 不定宽度"是"tab的长处吧。tab可以解释成各种space长度 03/22 19:00
21F：→ Caesar08: 喜欢2 space的把tab设成2 space，喜欢4 space的就设成4 03/22 19:01
22F：→ Caesar08: tab应该被大力推广才对，不懂tab有什麽"缺点" 03/22 19:04
23F：推 CoNsTaR: tab 的缺点是除了在你自己的 IDE A里以外你永远无法保证 03/22 22:32
24F：→ CoNsTaR: tab 和 space 混用的档案会被 display aligned 03/22 22:32
25F：推 CoNsTaR: 就算你真的只用 tab 还是会有 misalignment，但只用 spac 03/22 22:35
26F：→ CoNsTaR: e 永远不会出错 03/22 22:35
27F：推 CoNsTaR: *IDE 03/23 00:20
28F：→ madturtle: 按照楼上的理论，只用tab也永远不会出错。 03/24 05:40
29F：→ Caesar08: 为什麽只用tab会misalignment？你tab不都是等宽吗？ 03/24 12:35
30F：→ lycantrope: 用tab一定要跟space混用，除非你所有间隔都用tab 03/24 12:41
31F：→ Caesar08: 为什麽要跟space混用？只有indent用tab，其他才用space 03/24 19:53
32F：推 CoNsTaR: 除非你的其他字元也都跟 tab 一样可以自由伸缩，whitespa 03/25 09:13
33F：→ CoNsTaR: ce 全部都用 tab，否则就是会有 misalignment 啊 03/25 09:13
34F：→ CoNsTaR: 你要怎麽保证你用 tabs indent 的 comments 开头一定会 03/25 09:13
35F：→ CoNsTaR: 对齐下一行的某个字元？ 03/25 09:13
36F：→ CoNsTaR: 除了一个参数一行以外，你要怎麽对齐多行的函数参数？ 03/25 09:13
37F：→ CoNsTaR: 你要怎麽保证你的 comments 不会超过 80 或 120 字元宽？ 03/25 09:13
38F：推 CoNsTaR: 更正，要怎麽把你开头用 tabs indent 的 comments 对齐在 03/25 09:17
39F：→ CoNsTaR: 80 或 120 字元宽？ 03/25 09:17
40F：推 CoNsTaR: 每行一个 statement，每个 statement 後面都有注解，你要 03/25 09:19
41F：→ CoNsTaR: 怎麽对齐那些注解？ 03/25 09:19
42F：→ MOONRAKER: 想太多。space最大的好处是增加原始码长度，看起来很多 03/27 09:24
43F：推 johnjohnlin: 拿tab缩排 空白对齐就不会乱掉了 03/28 07:54
44F：推 CoNsTaR: 楼上... tab 和 space 同时存在就是乱掉的主因啊 03/28 15:25
45F：→ CoNsTaR: 用 tab 缩排之後到底要怎麽做到用 space 对齐？ 03/28 15:25
46F：→ Caesar08: 你举的例子里只有保证宽度（80或120）是tab做不到的 03/28 20:41
47F：→ Caesar08: statement後面要把注解对齐，跟tab多宽没有关系 03/28 20:42
48F：→ Caesar08: 既然缩排是tab，那要对齐的时候也要补tab，而不是space 03/28 20:46
49F：→ Lipraxde: 对齐 argument、三元运算子，tab 行吗XD？ 03/28 22:28
50F：推 Richun: statement後对齐注解跟tab对应宽度很有关系，statement间 03/28 23:02
51F：→ Richun: 的字元数落差只要大於一个hard tab宽度就会开始对不齐了。 03/28 23:02
52F：→ Richun: 长度落差10个字元，hard tab在这台电脑占8个，另一台占4个 03/28 23:03
53F：→ Richun: 这时对齐所需的tab数在两台之间一定会差至少1格。 03/28 23:09
55F：→ johnjohnlin: space align很多，vscode都有外挂了 03/29 00:20
56F：→ johnjohnlin: 的确我常常看到乱混tab space的会很不爽，但是把握 03/29 00:21
57F：→ johnjohnlin: 好的话我还没遇过问题，同时可以满足不同宽度喜好 03/29 00:22
58F：推 johnjohnlin: @Lipraxde 当然不行 tab是"缩排" space才是"对齐" 03/29 00:38
59F：推 CoNsTaR: 真要混用也是 space indent, tab align 吧 03/29 01:26
60F：→ CoNsTaR: @johnjohnlin 贴的那篇只适用於每行缩排都相同的情况而已 03/29 01:26
61F：→ CoNsTaR: ，要是有一个 block 或 statement 需要多缩一排，不又直 03/29 01:26
62F：→ CoNsTaR: 接爆炸了？ 03/29 01:26
63F：→ CoNsTaR: * 误， space indent tab align 照样行不通 03/29 01:27
64F：推 CoNsTaR: 反正回到一开始，space 和 tab 混用就是可能会有问题，通 03/29 01:29
65F：→ CoNsTaR: 通用 tab 还是可能有问题，不要用就对了 03/29 01:29
66F：→ Caesar08: 甚麽叫做“多缩一排”？那就补一个tab阿，只要indent就 03/29 01:37
67F：→ Caesar08: 用tab，其他才用space，有那麽困难吗？ 03/29 01:37
68F：→ Caesar08: @johnjohnlin 贴的文章就说明怎麽用tab了。tab又不是拿 03/29 01:38
69F：→ Caesar08: 来取代space，他只是提供indent而已 03/29 01:38
70F：→ Caesar08: 你觉得space很方便，因为不会有乱用的问题。但是tab也有 03/29 01:44
71F：→ Caesar08: 方便的地方，因为每个人喜欢的indent都不同，tab提供了 03/29 01:44
72F：→ Caesar08: 一个抽象层，让大家可以在不改source code的状况下得到 03/29 01:44
73F：→ Caesar08: 自己喜欢的style 03/29 01:44
74F：嘘 CoNsTaR: 多补一个 tab，然後你用 space 做的 alignment 就坏掉了 03/29 03:03
75F：→ CoNsTaR: 这样有很难理解？ 03/29 03:03
76F：嘘 CoNsTaR: 从来没有在讨论喜欢哪个 style 或哪个方便，从头到尾讨 03/29 03:05
77F：→ CoNsTaR: 论的都是 tab 会在很多专案被禁止使用的原因 03/29 03:05
78F：嘘 CoNsTaR: 我就已经说明 @johnjohnlin 贴的文章会遇到什麽问题了， 03/29 03:08
79F：→ CoNsTaR: 也从来没有说过你要用 tab 来取代 space，从头到尾说的 03/29 03:08
80F：→ CoNsTaR: 都是 tab 不要和 space 混用 03/29 03:08
81F：→ CoNsTaR: 我有说过的话你通通不看不理解，我没说过的话你通通指着 03/29 03:09
82F：→ CoNsTaR: 我鼻子骂，到底哪一点让你这麽难接受？ 03/29 03:09
83F：→ LPH66: 你的"多缩一排"是指连结文章里 int var1 var2 这种内缩? 03/29 07:11
84F：→ LPH66: 那篇文章里已经明确跟你说了那种叫 alignment 限用 space 03/29 07:11
85F：→ LPH66: 连结文章开头那种长条件切行内缩那也是 alignment 03/29 07:13
86F：→ LPH66: indent 只限指在大阶层内缩, 多一个 {} 内缩那种是 indent 03/29 07:13
87F：→ LPH66: 啊我知道啦, 你的"space 做的 alignment 就坏掉了"该不会是 03/29 07:14
88F：→ LPH66: 某些编辑器会多事的帮你把所有开头的空白全部换成 tab 那种 03/29 07:15
89F：→ LPH66: 如果编辑器会多事这样转的那当然按个 tab 内缩就全帮你转了 03/29 07:15
90F：→ LPH66: 自然就坏光光... 03/29 07:15
91F：→ LPH66: 当编辑器只懂得「开头要嘛全 Tab 要嘛全 space」的时候 03/29 07:19
92F：→ LPH66: 自然是全 space 才不坏事, 但如果编辑器不会多事那当然是 03/29 07:20
93F：→ LPH66: 用的人有分好 indent 跟 alignment 哪个用哪个 03/29 07:20
94F：→ LPH66: 就都不会有问题 03/29 07:20
95F：→ Caesar08: 因为你说混用是不行的。@johnjohnlin贴的文章也说可以混 03/29 09:27
96F：→ Caesar08: 用，也有code补充论点。既然你不同意这些观点，那我想知 03/29 09:27
97F：→ Caesar08: 道实际code是甚麽，你的“内缩一排”是甚麽code 03/29 09:27
98F：嘘 CoNsTaR: 根本不存在同不同意的问题，可以就是可以，不行就是不行 03/29 11:41
99F：→ CoNsTaR: ，不要滑坡 03/29 11:41
100F：→ CoNsTaR: 我原先的推文就已经告诉你在怎样的情况下那样的做法一样 03/29 11:41
101F：→ CoNsTaR: 不行，是你不听不讨论不理解根本不是我不讲（只要 indent 03/29 11:41
102F：→ CoNsTaR: ation 不是每行完全相同） 03/29 11:41
103F：→ CoNsTaR: 相同的 use case 在我更之前的推文也早就已经提到过了 03/29 11:41
105F：→ CoNsTaR: 只要某一行和其他行有不同 indentation， comments 就是 03/29 11:41
106F：→ CoNsTaR: 不可能对齐 03/29 11:41
107F：→ CoNsTaR: 而无法对齐的根本原因就是 space 和 tab 混用 03/29 11:51
109F：推 yvb: 楼上,问题就是<tab>定位点用8k会对齐时,改为4k未必会对齐. 03/29 18:27
110F：→ yvb: 但是要这样子的方式写注解, 又要对齐的意义是什麽? 03/29 18:30
111F：→ yvb: 有疑虑时就规定<tab>的缩排量吧. 03/29 18:38
112F：推 LPH66: > 只要 indentation 不是每行完全相同 03/29 18:55
113F：→ LPH66: 所以看起来你是把所有开头的 whitespace 全部称为 indent 03/29 18:55
114F：→ LPH66: 那这就是定义不同的问题不是谁不听谁的问题了 03/29 18:56
115F：→ LPH66: 该连结文章里的 indent 只称大排版 03/29 18:56
116F：→ LPH66: 像长行切断下面内缩这种开头 whitespace 该文称 alignment 03/29 18:57
117F：→ LPH66: 那一行的内缩会有称为 indent 跟随大部队的内缩 03/29 18:57
118F：→ LPH66: 以及只有自己有为了对齐文字或显示断行归属的 alignment 03/29 18:58
119F：→ LPH66: (这些都是该文的叫法) 你要全叫它 indent 行啊, 但就说清楚 03/29 18:59
120F：→ LPH66: 至於 comment, comment 对齐用 whitespace 对该文来说 03/29 19:00
121F：→ LPH66: 当然是属於 alignment, 所以自然全得用空白 03/29 19:00
122F：→ LPH66: 你所点出的跨 indent level 的对齐 comment 03/29 19:02
123F：→ LPH66: 是啦, 这些对不齐没错, 但我不觉得在会时常改动的程式码中 03/29 19:03
124F：→ LPH66: 会需要时常因为改程式码而去调整对齐 03/29 19:04
125F：→ LPH66: 是一件舒服的事 03/29 19:04
126F：→ LPH66: 我自己就只会在不常改的地方 (像表格) 这样做 03/29 19:05
127F：→ LPH66: 那种地方很少会有跨 indent level 的程式码需要这样 03/29 19:05
129F：→ Caesar08: @yvb嗯，我现在才注意到就算都是tab，宽度也会有不同的 03/29 20:03
130F：→ Caesar08: 状况，但这应该是属於编辑器怎麽处理tab的问题。不过既 03/29 20:03
131F：→ Caesar08: 然每个人使用的编辑器都不同，那在这code用tab做对齐就 03/29 20:03
132F：→ Caesar08: 是不可能的了 03/29 20:03
133F：推 yvb: 不过我个人觉得, 在每行末端注解要对齐这种事太枝微末节了, 03/29 21:52
134F：→ yvb: 还不如程式写整齐,命名适当,以及函式及区段注解写清楚就够了. 03/29 21:54
135F：→ yvb: 至於程式内容写得清不清楚漂不漂亮,那则是另一件事. 03/29 21:59
136F：推 johnjohnlin: LPH大大那种不对齐我今天才注意到有这个可能 03/30 23:20
137F：→ johnjohnlin: 应该是这类型注解真的很少出现 03/30 23:20
139F：→ johnjohnlin: 还要我开哪个奇怪的编辑器吗？Microsoft word 如何 03/30 23:28
141F：→ johnjohnlin: 我错了，你如果这样用的话会跑掉 03/30 23:30
142F：推 wulouise: 我觉得程式有很多可以讨论 coding style是最没有产出的. 04/01 22:22
143F：→ wulouise: 订好一起用就好，至於space tab就是不要混用就没差 04/01 22:23
144F：→ wulouise: 大多用space的原因就是ide不会乱动space但tab不好说 04/01 22:24
145F：推 CoNsTaR: @LPH66 那篇文章对 alignment 和 indentation 的定义和 04/01 23:45
146F：→ CoNsTaR: 我没有不一样啊 @@ 04/01 23:45
147F：推 CoNsTaR: 我也没有要 promote 把 comments 写在行尾，我只是试图 04/01 23:48
148F：→ CoNsTaR: 用例子解释当你用 space 去 makeup 另一行的 tab，或是 04/01 23:48
149F：→ CoNsTaR: 用 tab 去 makeup 另一行的 space 的时候 alignment 就无 04/01 23:48
150F：→ CoNsTaR: 法被保证 04/01 23:48
151F：→ LPH66: 老实说我也是边想边回打字到一半才发现你在强调这个 04/02 04:50
152F：→ LPH66: 所以後来才补了为什麽我不会去用这种会造成问题的写法 04/02 04:51
153F：推 wulouise: 我大概懂意思 如果有一行注解是\t\t//^^^^ magic 04/02 22:47
154F：→ wulouise: 你要怎麽样确保magic指到的位置是对的...应该是无解XD 04/02 22:48
155F：推 timofEE: 对齐的问题好一点的IDE会帮你处理好 04/03 04:05
156F：→ timofEE: space跟tab也是 但就是会被宠坏 04/03 04:05
157F：→ timofEE: 已经好几次程式跑不起来结果是有几行是tab或空格 04/03 04:05
158F：→ timofEE: 反正我现在一律养成用space了 04/03 04:05
159F：推 johnjohnlin: 楼上可是这里不是python版（？ 04/03 12:34
160F：推 lc85301: 我都用 clang-format 没在管排版 (owo) 04/05 13:22
161F：推 Lhmstu: 把tab换成几个空白不就好了，想设几个就设几个 04/24 02:21