原Po 研究過 Allman Style , K&R style, GNU style 還有 ISO c99 c++2011 c++2014 c++2022 實際撰寫過 Linux kernel, Zephyr, Android framework & App, Python3 for AI Scala for Risc-V, IOS Object-C .m .mm, tracing gcc source, C#, Inline assembly buildroot, bash, Makefile 拜讀過大師 Weinberg 的程式心理學 The Psychology of Computer Programming 另有 系統開發思惟 An Introduction to General Systems Thinking 也撰寫過完整的 Hungarian notation 語義學 分析 和 它的歷史 // 這是有發過文的 int a=1,b=2,c=3; if(a) { a=1; if(b) { b=1; if(c) { c=1; } } } //////////////// int a=1,b=2,c=3; if(!a) { return; } a=1; if(!b) { return; } b=1; if(!c) { return; } c=1; 上下那一段的 coding style 好些? 不管選上或選下 你可以有一百種理由 但當我轉換到 asm 時 你就知道原因 push %rbp mov %rsp,%rbp int a=1,b=2,c=3; movl $0x1,-0xc(%rbp) movl $0x2,-0x8(%rbp) movl $0x3,-0x4(%rbp) if(a) cmpl $0x0,-0xc(%rbp) je 0x555555555e7f <teseMe1()+64> a=1; movl $0x1,-0xc(%rbp) if(b) cmpl $0x0,-0x8(%rbp) je 0x555555555e7f <teseMe1()+64> b=1; movl $0x1,-0x8(%rbp) if(c) cmpl $0x0,-0x4(%rbp) je 0x555555555e7f <teseMe1()+64> c=1; movl $0x1,-0x4(%rbp) // push %rbp mov %rsp,%rbp int a=1,b=2,c=3; movl $0x1,-0xc(%rbp) movl $0x2,-0x8(%rbp) movl $0x3,-0x4(%rbp) if(!a) cmpl $0x0,-0xc(%rbp) je 0x555555555ec4 <teseMe2()+66> a=1; movl $0x1,-0xc(%rbp) if(!b) cmpl $0x0,-0x8(%rbp) je 0x555555555ec7 <teseMe2()+69> b=1; movl $0x1,-0x8(%rbp) if(!c) cmpl $0x0,-0x4(%rbp) je 0x555555555eca <teseMe2()+72> c=1; movl $0x1,-0x4(%rbp) jmp 0x555555555ecb <teseMe2()+73> return; nop jmp 0x555555555ecb <teseMe2()+73> return; nop jmp 0x555555555ecb <teseMe2()+73> return; nop 現在你可以看得出來代碼的數量....心裡也有答案了 這是開放性的解答 ///////// 想要制定coding style的人或主管 必先要學會自省的功夫 1. 自己有嘗試過 別人寫的style 一天或一週嗎? 還是我只是將某個我習慣的style 強加在別人身上 2. 我有試過 新的coding style嗎? 3. 我有試過 各種不同的語言嗎? 99%的人 在制定coding style的人 沒有這3點的自省~~~ 他也沒有考慮過 語義學 心理學 在coding style的影響 把時間耗在 定名字 定括號 導到工程師實際上花了三倍的時間 在view code 沒有時間去 思惟 整個架構的安全性 速度 cpu & memory 負載量 要打磨的是畫作 不是畫框 看過python3的人都知 if else. 括號? 我根本不用考慮這東西!!! 制定的 coding style 能使c/c++ 轉到 python 的人 在跨語上 更容易讀懂嗎? 一個好的 coding style 制定者 會自省 使用大腦使用最少的組合 或 拆解次數 做為制定方針 把更多的時間 放在對的地方~~~ 如果說目前最常用的組譯器 gcc g++ arm-linux-gcc aarcg64-linux-gcc gdb gdbserver they are all released by GNU 或 經過修改過 https://ftp.gnu.org/gnu/gcc 那使用組譯器最易懂的 style 會不會是最好的呢? 答案當然是 不會只有某一種style 是最好的 你可以 考上述原因 融合各種 style 創立最適合 自己團隊的!!! 未來的主管們 請多想想 你是怎麼制定 coding style的~~~~ ※ 引述《prag222 (prag)》之銘言: : 大家好 : 小弟上上份工作快離職前 : 聽到新進的同事說 : 他都習慣把程式寫成一個一個小的function : 後來離職我花了一點時間學習設計模式 : 和了解SOLID原則 : 我越覺得這種作法很OK : 我大概也知道這應該是重複說高手說過的話 : 所以後來找到工作 : 專案自己一個人開發 : 也沒主管強制要求程式該怎麼寫 : 變照著 之前同事說的話去開發 : 讓程式碼 程式碼也是有結構性架構性的 : 而不是一個function寫幾百行幾千行 : mvc Model層也是切得很乾淨 : Model層寫的就像api : controller帶參數給MODEL層撈資料出來 : 不過我最近的公司 : 完全不是這種做法 : 雖然是MVC不過還是下SQL查出資料 : 看到function寫幾百行我看了就昏(業務邏輯) : 為了符合公司專案的coding style有點辛苦 : 基本上我速度也差不多折損一半也有了 : 不過盡可能把程式碼寫成一個一個小單元應該也沒錯吧 : 畢竟單元測試 : 跟我最近看重構的書也是建議這樣 : 上份工作有改到open source的專案 : 好像也是這樣 : 是很難看的懂 但擴充維護修改都很輕鬆 -- ※ 發信站: 批踢踢實業坊(ptt-web.org.tw), 來自: 114.32.93.159 (臺灣) ※ 文章網址: https://ptt-web.org.tw/Soft_Job/M.1679378684.A.DAD
bmiss: 就我認知除非為了性能,不然不會考慮轉成組語的代碼量 03/21 14:33
leolarrel: 客戶:我發案子給你的,要你怎麼寫就怎麼寫 03/21 14:46
labbat: style 是用來管別人的,自己不用遵守 03/21 15:09
labbat: 主管說的 03/21 15:09
CaptainH: 你是不是閒得沒事幹天天想這個 03/21 15:21
lezabo: 包養網站葉配啦 03/21 15:21
kiedveian: 反串嗎?上下兩段只差return,意思是不要寫return比較好? 03/21 15:23
CaptainH: formatter+linter下去 花腦力在無聊的枝枝節節做什麼 03/21 15:23
kiedveian: 轉成asm兩邊的縮排差異就比不出來了 03/21 15:24
loadingN: clang format 03/21 16:05
fatalfeel2: labbat大 完全命中!!! 03/21 16:17
silberger: 記者收了包養網多少啦 03/21 16:17
fatalfeel2: 花腦力在無聊的枝枝節節 完全同意~~~ 03/21 16:18
fatalfeel2: 這是我進了某間公司 才會研究的東西 因為上頭有要求 03/21 16:19
fatalfeel2: 好的要求我們可以遵守但不好的要求 就應該改進 03/21 16:19
fatalfeel2: 事實上已經有人 因為程式語義學的問題 離職了 03/21 16:20
TAKADO: 軟體工程師coding最討厭兩件事,一是follow guideline,二 03/21 16:21
xayile: 包養真亂 03/21 16:21
TAKADO: 是同事不follow guideline 03/21 16:21
APTON: 這種事情不都是寫好規範,剩下都丟給lint處理就好嗎@@? 03/21 16:33
s06yji3: 鑽牛角尖了 03/21 16:43
acgotaku: 這些每個人理解不同,需要有一個架構師出來協調定義 03/21 17:43
MoonCode: 天啊 03/21 18:16
cazo: 演藝圈一堆包養好嗎 03/21 18:16
fatalfeel2: Hungarian notation 某間公司還在用的語義命名 03/21 19:02
fatalfeel2: https://reurl.cc/OV5503 在微軟發明 被自己宣告放棄 03/21 19:03
fatalfeel2: 架構師 就是制定者本人 就是公司規定!!! 03/21 19:04
fatalfeel2: 好在我離開了~~~~~~~~~~~~~~~~ 03/21 19:04
fatalfeel2: 增加了系統熵 增加了 語言的組合次數 03/21 19:05
izilo: 政治圈一堆包養好嗎 03/21 19:05
fatalfeel2: 也禁用 inline Asm 03/21 19:06
fatalfeel2: 若大家遇到就看著辦吧~~~~ 03/21 19:06
enthos: FORTH系asm:dq NUM,1,VARD,0xa,NUM,2,VARD,0xb,NUM,3, 03/21 19:14
enthos: dq VARD,0xc,VARA,0xa,FETCH,DOIF,NUM,1,VARA,0xa, 03/21 19:14
enthos: dq STORE,VARA,0xb,FETCH,DOIF,NUM 1,VARA,0xb,STORE 03/21 19:14
SEDAP: 有錢人一堆包養好嗎 03/21 19:14
superpandal: 原po寫過bash makefile? 感覺是個oop狂人 03/21 20:43
superpandal: 人 以bash非常動態的特性習慣來看oop是會覺得 03/21 20:45
superpandal: 會覺得很囉唆 03/21 20:47
superpandal: 1樓說的是 就是雙標 何嘗不是權勢壓力 03/21 20:49
superpandal: 3樓 看錯 03/21 20:50
TUZom: 學生妹被包養多嗎 03/21 20:50
e12518166339: 不管有什麼想法,我都還是得先問過scripts/checkpat 03/21 23:27
e12518166339: ch.pl 03/21 23:27
e12518166339: 它老大說ok才算ok 03/21 23:28
gary75952: 該思考的是整體架構,你code 之間依賴越低,拆分得越清 03/22 01:19
gary75952: 楚,整體code style會變成一種自然,架構設計的越好sen 03/22 01:19
Jiulon: 有錢人為啥都想包養 03/22 01:19
gary75952: ior也不會寫出什麼爛code,因為有架構的限制 03/22 01:19
gary75952: 不用鑽牛角尖一些沒啥效能差異的code style,很多理論 03/22 01:25
gary75952: 大家都清楚,該思考的是當下專案怎做才是最大效益 03/22 01:25
fatalfeel2: 讚成G大~ 03/22 02:05
xxi511: 你比較喜歡看著一層又一層的if ,可讀性管他去死? 03/22 07:58
laetuon: 有錢人為啥都想包養 03/22 07:58
TeaEEE: 我只記得我為了別人一個if else不加{}的bug,追了一天 03/22 09:02
wilson6405: 第一次看到程式心理學 03/22 09:36
yamagishi: 閱讀性定期 03/22 09:53
KanzakiHAria: TAKADO那句最討厭兩件事好好笑XDDDDDDD 03/22 12:24
Lipraxde: Asm 嘛...優化、PGO、UNLIKELY 下下去都好解決的,不該 03/23 21:18
slot365: 亞洲最大包養網上線啦 03/23 21:18
Lipraxde: 拿來當決定 coding style 的理由 03/23 21:18
ku72: 在現在的硬體效能下 努力增加程式碼的容易理解程度 比增加效 03/24 11:43
ku72: 能來的重要多了 03/24 11:43
zero11995: 15F XDD 03/24 14:38
bjk: 15F XDD 03/24 16:56
colortea: 我哥上包養網被我抓包.. 03/24 16:56
laxw: follow公司rule就好, 都看的懂 03/29 15:22
MonyemLi: 有大廠定義,ide抓來匯入就好。如果這語言沒有,看是否 04/06 07:18
MonyemLi: 有必要為了效能犧牲可讀性。早期java常見c的sytle,但 04/06 07:18
MonyemLi: 為了什麼?效能?怎麼可能 04/06 07:18