Re: [討論] 前輩們變數都怎麼命名2?

[fatalfeel2 (風在動)]

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://www.ptt.cc/bbs/C_and_CPP/M.1679025860.A.E70.html
推 stallings: 關於縮排，我比較接受 4 個空格
→ stallings: 8 個空格我覺得過多了。至於用 tab？嗯...
→ stallings: 關於區塊，現在好像有人提倡
→ stallings: 即使只有一行也加括號以使程式碼清楚
→ tomsawyer: vscode的linter會把if弄成大括號跟函數一樣
推 closer76: Google open-source style 是 2 空格.... 我一開始不習
→ closer76: 慣，但用了一段時間覺得也還不錯。 XD
推 Lipraxde: 比起縮幾格，不要搞成五、六層巢狀比較舒服
推 chuegou: 最後一個就防呆來說不好 misra規範就強制要加大括號 蘋
→ chuegou: 果的goto fail某種程度上也是因為沒加大括號
推 stallings: 沒在寫 Linux kernel code 就不用理那些了
推 mmmmei: 大括號我們組要求要新的一行。理由是這樣比較容易看出一
→ mmmmei: 個clause從哪裡開始的
推 johnjohnlin: 用一個tab縮排就能同時滿足2 4 8空白三種需求
→ fatalfeel2: 有些ide tab 可以設定 字元數
※ 編輯: fatalfeel2 (218.187.80.32 臺灣), 03/18/2023 19:24:46
推 stallings: 不定寬度正是 tab 的短處啊
→ stallings: 唯一支持 sp～叭叭叭～
※ 編輯: fatalfeel2 (218.187.80.32 臺灣), 03/19/2023 06:27:11
推 CoNsTaR: 我都去找算命的算變數名稱，這樣以後程式有 bug 他比較好
→ CoNsTaR: 通靈
→ Caesar08: 不定寬度"是"tab的長處吧。tab可以解釋成各種space長度
→ Caesar08: 喜歡2 space的把tab設成2 space，喜歡4 space的就設成4
→ Caesar08: tab應該被大力推廣才對，不懂tab有什麼"缺點"
推 CoNsTaR: tab 的缺點是除了在你自己的 IDE A裡以外你永遠無法保證
→ CoNsTaR:  tab 和 space 混用的檔案會被 display aligned
推 CoNsTaR: 就算你真的只用 tab 還是會有 misalignment，但只用 spac
→ CoNsTaR: e 永遠不會出錯
推 CoNsTaR: *IDE
→ madturtle: 按照樓上的理論，只用tab也永遠不會出錯。
→ Caesar08: 為什麼只用tab會misalignment？你tab不都是等寬嗎？
→ lycantrope: 用tab一定要跟space混用，除非你所有間隔都用tab
→ Caesar08: 為什麼要跟space混用？只有indent用tab，其他才用space
推 CoNsTaR: 除非你的其他字元也都跟 tab 一樣可以自由伸縮，whitespa
→ CoNsTaR: ce 全部都用 tab，否則就是會有 misalignment 啊
→ CoNsTaR: 你要怎麼保證你用 tabs indent 的 comments 開頭一定會
→ CoNsTaR: 對齊下一行的某個字元？
→ CoNsTaR: 除了一個參數一行以外，你要怎麼對齊多行的函數參數？
→ CoNsTaR: 你要怎麼保證你的 comments 不會超過 80 或 120 字元寬？
推 CoNsTaR: 更正，要怎麼把你開頭用 tabs indent 的 comments 對齊在
→ CoNsTaR:  80 或 120 字元寬？
推 CoNsTaR: 每行一個 statement，每個 statement 後面都有註解，你要
→ CoNsTaR: 怎麼對齊那些註解？
→ MOONRAKER: 想太多。space最大的好處是增加原始碼長度，看起來很多
推 johnjohnlin: 拿tab縮排 空白對齊就不會亂掉了
推 CoNsTaR: 樓上... tab 和 space 同時存在就是亂掉的主因啊
→ CoNsTaR: 用 tab 縮排之後到底要怎麼做到用 space 對齊？
→ Caesar08: 你舉的例子裡只有保證寬度（80或120）是tab做不到的
→ Caesar08: statement後面要把註解對齊，跟tab多寬沒有關係
→ Caesar08: 既然縮排是tab，那要對齊的時候也要補tab，而不是space
→ Lipraxde: 對齊 argument、三元運算子，tab 行嗎XD？
推 Richun: statement後對齊註解跟tab對應寬度很有關係，statement間
→ Richun: 的字元數落差只要大於一個hard tab寬度就會開始對不齊了。
→ Richun: 長度落差10個字元，hard tab在這台電腦佔8個，另一台佔4個
→ Richun: 這時對齊所需的tab數在兩台之間一定會差至少1格。
推 johnjohnlin: https://reurl.cc/GeG1gx  網路上找一下tab indent
→ johnjohnlin: space align很多，vscode都有外掛了
→ johnjohnlin: 的確我常常看到亂混tab space的會很不爽，但是把握
→ johnjohnlin: 好的話我還沒遇過問題，同時可以滿足不同寬度喜好
推 johnjohnlin: @Lipraxde 當然不行 tab是"縮排" space才是"對齊"
推 CoNsTaR: 真要混用也是 space indent, tab align 吧
→ CoNsTaR: @johnjohnlin 貼的那篇只適用於每行縮排都相同的情況而已
→ CoNsTaR: ，要是有一個 block 或 statement 需要多縮一排，不又直
→ CoNsTaR: 接爆炸了？
→ CoNsTaR: * 誤， space indent tab align 照樣行不通
推 CoNsTaR: 反正回到一開始，space 和 tab 混用就是可能會有問題，通
→ CoNsTaR: 通用 tab 還是可能有問題，不要用就對了
→ Caesar08: 甚麼叫做“多縮一排”？那就補一個tab阿，只要indent就
→ Caesar08: 用tab，其他才用space，有那麼困難嗎？
→ Caesar08: @johnjohnlin 貼的文章就說明怎麼用tab了。tab又不是拿
→ Caesar08: 來取代space，他只是提供indent而已
→ Caesar08: 你覺得space很方便，因為不會有亂用的問題。但是tab也有
→ Caesar08: 方便的地方，因為每個人喜歡的indent都不同，tab提供了
→ Caesar08: 一個抽象層，讓大家可以在不改source code的狀況下得到
→ Caesar08: 自己喜歡的style
噓 CoNsTaR: 多補一個 tab，然後你用 space 做的 alignment 就壞掉了
→ CoNsTaR: 這樣有很難理解？
噓 CoNsTaR: 從來沒有在討論喜歡哪個 style 或哪個方便，從頭到尾討
→ CoNsTaR: 論的都是 tab 會在很多專案被禁止使用的原因
噓 CoNsTaR: 我就已經說明 @johnjohnlin 貼的文章會遇到什麼問題了，
→ CoNsTaR: 也從來沒有說過你要用 tab 來取代 space，從頭到尾說的
→ CoNsTaR: 都是 tab 不要和 space 混用
→ CoNsTaR: 我有說過的話你通通不看不理解，我沒說過的話你通通指著
→ CoNsTaR: 我鼻子罵，到底哪一點讓你這麼難接受？
→ LPH66: 你的"多縮一排"是指連結文章裡 int var1 var2 這種內縮?
→ LPH66: 那篇文章裡已經明確跟你說了那種叫 alignment 限用 space
→ LPH66: 連結文章開頭那種長條件切行內縮那也是 alignment
→ LPH66: indent 只限指在大階層內縮, 多一個 {} 內縮那種是 indent
→ LPH66: 啊我知道啦, 你的"space 做的 alignment 就壞掉了"該不會是
→ LPH66: 某些編輯器會多事的幫你把所有開頭的空白全部換成 tab 那種
→ LPH66: 如果編輯器會多事這樣轉的那當然按個 tab 內縮就全幫你轉了
→ LPH66: 自然就壞光光...
→ LPH66: 當編輯器只懂得「開頭要嘛全 Tab 要嘛全 space」的時候
→ LPH66: 自然是全 space 才不壞事, 但如果編輯器不會多事那當然是
→ LPH66: 用的人有分好 indent 跟 alignment 哪個用哪個
→ LPH66: 就都不會有問題
→ Caesar08: 因為你說混用是不行的。@johnjohnlin貼的文章也說可以混
→ Caesar08: 用，也有code補充論點。既然你不同意這些觀點，那我想知
→ Caesar08: 道實際code是甚麼，你的“內縮一排”是甚麼code
噓 CoNsTaR: 根本不存在同不同意的問題，可以就是可以，不行就是不行
→ CoNsTaR: ，不要滑坡
→ CoNsTaR: 我原先的推文就已經告訴你在怎樣的情況下那樣的做法一樣
→ CoNsTaR: 不行，是你不聽不討論不理解根本不是我不講（只要 indent
→ CoNsTaR: ation 不是每行完全相同）
→ CoNsTaR: 相同的 use case 在我更之前的推文也早就已經提到過了
→ CoNsTaR: https://pastebin.com/UEd8y5aA
→ CoNsTaR: 只要某一行和其他行有不同 indentation， comments 就是
→ CoNsTaR: 不可能對齊
→ CoNsTaR: 而無法對齊的根本原因就是 space 和 tab 混用
→ Caesar08: 註解不就這樣對齊嗎？ https://pastebin.com/AybKwY6H
推 yvb: 樓上,問題就是<tab>定位點用8k會對齊時,改為4k未必會對齊.
→ yvb: 但是要這樣子的方式寫註解, 又要對齊的意義是什麼?
→ yvb: 有疑慮時就規定<tab>的縮排量吧.
推 LPH66: > 只要 indentation 不是每行完全相同
→ LPH66: 所以看起來你是把所有開頭的 whitespace 全部稱為 indent
→ LPH66: 那這就是定義不同的問題不是誰不聽誰的問題了
→ LPH66: 該連結文章裡的 indent 只稱大排版
→ LPH66: 像長行切斷下面內縮這種開頭 whitespace 該文稱 alignment
→ LPH66: 那一行的內縮會有稱為 indent 跟隨大部隊的內縮
→ LPH66: 以及只有自己有為了對齊文字或顯示斷行歸屬的 alignment
→ LPH66: (這些都是該文的叫法) 你要全叫它 indent 行啊, 但就說清楚
→ LPH66: 至於 comment, comment 對齊用 whitespace 對該文來說
→ LPH66: 當然是屬於 alignment, 所以自然全得用空白
→ LPH66: 你所點出的跨 indent level 的對齊 comment
→ LPH66: 是啦, 這些對不齊沒錯, 但我不覺得在會時常改動的程式碼中
→ LPH66: 會需要時常因為改程式碼而去調整對齊
→ LPH66:                                   是一件舒服的事
→ LPH66: 我自己就只會在不常改的地方 (像表格) 這樣做
→ LPH66: 那種地方很少會有跨 indent level 的程式碼需要這樣
→ LPH66: 實際例子大概像這樣 https://i.imgur.com/26IJSWH.png
→ Caesar08: @yvb嗯，我現在才注意到就算都是tab，寬度也會有不同的
→ Caesar08: 狀況，但這應該是屬於編輯器怎麼處理tab的問題。不過既
→ Caesar08: 然每個人使用的編輯器都不同，那在這code用tab做對齊就
→ Caesar08: 是不可能的了
推 yvb: 不過我個人覺得, 在每行末端註解要對齊這種事太枝微末節了,
→ yvb: 還不如程式寫整齊,命名適當,以及函式及區段註解寫清楚就夠了.
→ yvb: 至於程式內容寫得清不清楚漂不漂亮,那則是另一件事.
推 johnjohnlin: LPH大大那種不對齊我今天才注意到有這個可能
→ johnjohnlin: 應該是這類型註解真的很少出現
推 johnjohnlin: https://imgur.com/a/bapZMHo 正確使用都不會亂掉
→ johnjohnlin: 還要我開哪個奇怪的編輯器嗎？Microsoft word 如何
推 johnjohnlin: https://www.youtube.com/watch?v=X34ZmkeZDos
→ johnjohnlin: 我錯了，你如果這樣用的話會跑掉
推 wulouise: 我覺得程式有很多可以討論 coding style是最沒有產出的.
→ wulouise: 訂好一起用就好，至於space tab就是不要混用就沒差
→ wulouise: 大多用space的原因就是ide不會亂動space但tab不好說
推 CoNsTaR: @LPH66 那篇文章對 alignment 和 indentation 的定義和
→ CoNsTaR: 我沒有不一樣啊 @@
推 CoNsTaR: 我也沒有要 promote 把 comments 寫在行尾，我只是試圖
→ CoNsTaR: 用例子解釋當你用 space 去 makeup 另一行的 tab，或是
→ CoNsTaR: 用 tab 去 makeup 另一行的 space 的時候 alignment 就無
→ CoNsTaR: 法被保證
→ LPH66: 老實說我也是邊想邊回打字到一半才發現你在強調這個
→ LPH66: 所以後來才補了為什麼我不會去用這種會造成問題的寫法
推 wulouise: 我大概懂意思 如果有一行註解是\t\t//^^^^ magic
→ wulouise: 你要怎麼樣確保magic指到的位置是對的...應該是無解XD
推 timofEE: 對齊的問題好一點的IDE會幫你處理好
→ timofEE: space跟tab也是 但就是會被寵壞
→ timofEE: 已經好幾次程式跑不起來結果是有幾行是tab或空格
→ timofEE: 反正我現在一律養成用space了
推 johnjohnlin: 樓上可是這裡不是python版（？
推 lc85301: 我都用 clang-format 沒在管排版 (owo)
推 Lhmstu: 把tab換成幾個空白不就好了，想設幾個就設幾個