作者fatalfeel2 (風在動)
標題Re: [請益] coding style差太多怎辦?
時間2023-03-21 14:04:37
原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: 架構師 就是制定者本人 就是公司規定!!! 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