PTT職涯區 / Soft_Job (軟體人)

Re: [請益] coding style差太多怎辦?

看板Soft_Job (軟體人)作者 (風在動)時間1年前 (2023/03/21 14:04), 1年前編輯推噓14(14推 0噓 41→)
留言55則, 25人參與, 1年前最新討論串3/3 (看更多)
原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.cc), 來自: 114.32.93.159 (臺灣) ※ 文章網址: https://www.ptt.cc/bbs/Soft_Job/M.1679378684.A.DAD.html
→
03/21 14:33, 1年前 , 1F
就我認知除非為了性能，不然不會考慮轉成組語的代碼量
03/21 14:33, 1F
→
03/21 14:46, 1年前 , 2F
客戶:我發案子給你的,要你怎麼寫就怎麼寫
03/21 14:46, 2F
好客戶 如果薪水先發 那就更好了~~~ ※ 編輯: fatalfeel2 (114.32.93.159 臺灣), 03/21/2023 14:49:53
→
03/21 15:09, 1年前 , 3F
style 是用來管別人的，自己不用遵守
03/21 15:09, 3F
→
03/21 15:09, 1年前 , 4F
主管說的
03/21 15:09, 4F
推
03/21 15:21, 1年前 , 5F
你是不是閒得沒事幹天天想這個
03/21 15:21, 5F
→
03/21 15:23, 1年前 , 6F
反串嗎?上下兩段只差return,意思是不要寫return比較好?
03/21 15:23, 6F
推
03/21 15:23, 1年前 , 7F
formatter+linter下去 花腦力在無聊的枝枝節節做什麼
03/21 15:23, 7F
→
03/21 15:24, 1年前 , 8F
轉成asm兩邊的縮排差異就比不出來了
03/21 15:24, 8F
→
03/21 16:05, 1年前 , 9F
clang format
03/21 16:05, 9F
→
03/21 16:17, 1年前 , 10F
labbat大 完全命中!!!
03/21 16:17, 10F
→
03/21 16:18, 1年前 , 11F
花腦力在無聊的枝枝節節 完全同意~~~
03/21 16:18, 11F
→
03/21 16:19, 1年前 , 12F
這是我進了某間公司 才會研究的東西 因為上頭有要求
03/21 16:19, 12F
→
03/21 16:19, 1年前 , 13F
好的要求我們可以遵守但不好的要求 就應該改進
03/21 16:19, 13F
→
03/21 16:20, 1年前 , 14F
事實上已經有人 因為程式語義學的問題 離職了
03/21 16:20, 14F
推
03/21 16:21, 1年前 , 15F
軟體工程師coding最討厭兩件事，一是follow guideline，二
03/21 16:21, 15F
→
03/21 16:21, 1年前 , 16F
是同事不follow guideline
03/21 16:21, 16F
推
03/21 16:33, 1年前 , 17F
這種事情不都是寫好規範，剩下都丟給lint處理就好嗎@@？
03/21 16:33, 17F
推
03/21 16:43, 1年前 , 18F
鑽牛角尖了
03/21 16:43, 18F
推
03/21 17:43, 1年前 , 19F
這些每個人理解不同,需要有一個架構師出來協調定義
03/21 17:43, 19F
→
03/21 18:16, 1年前 , 20F
天啊
03/21 18:16, 20F
→
03/21 19:02, 1年前 , 21F
Hungarian notation 某間公司還在用的語義命名
03/21 19:02, 21F
→
03/21 19:03, 1年前 , 22F
https://reurl.cc/OV5503 在微軟發明 被自己宣告放棄
03/21 19:03, 22F
→
03/21 19:04, 1年前 , 23F
架構師 就是制定者本人 就是公司規定!!!
03/21 19:04, 23F
→
03/21 19:04, 1年前 , 24F
好在我離開了~~~~~~~~~~~~~~~~
03/21 19:04, 24F
→
03/21 19:05, 1年前 , 25F
增加了系統熵 增加了 語言的組合次數
03/21 19:05, 25F
→
03/21 19:06, 1年前 , 26F
也禁用 inline Asm
03/21 19:06, 26F
→
03/21 19:06, 1年前 , 27F
若大家遇到就看著辦吧~~~~
03/21 19:06, 27F
→
03/21 19:14, 1年前 , 28F
FORTH系asm:dq NUM,1,VARD,0xa,NUM,2,VARD,0xb,NUM,3,
03/21 19:14, 28F
→
03/21 19:14, 1年前 , 29F
dq VARD,0xc,VARA,0xa,FETCH,DOIF,NUM,1,VARA,0xa,
03/21 19:14, 29F
→
03/21 19:14, 1年前 , 30F
dq STORE,VARA,0xb,FETCH,DOIF,NUM 1,VARA,0xb,STORE
03/21 19:14, 30F
→
03/21 20:43, 1年前 , 31F
原po寫過bash makefile? 感覺是個oop狂人
03/21 20:43, 31F
→
03/21 20:45, 1年前 , 32F
人 以bash非常動態的特性習慣來看oop是會覺得
03/21 20:45, 32F
→
03/21 20:47, 1年前 , 33F
會覺得很囉唆
03/21 20:47, 33F
→
03/21 20:49, 1年前 , 34F
1樓說的是 就是雙標 何嘗不是權勢壓力
03/21 20:49, 34F
→
03/21 20:50, 1年前 , 35F
3樓 看錯
03/21 20:50, 35F
推
03/21 23:27, 1年前 , 36F
不管有什麼想法，我都還是得先問過scripts/checkpat
03/21 23:27, 36F
→
03/21 23:27, 1年前 , 37F
ch.pl
03/21 23:27, 37F
→
03/21 23:28, 1年前 , 38F
它老大說ok才算ok
03/21 23:28, 38F
推
03/22 01:19, 1年前 , 39F
該思考的是整體架構，你code 之間依賴越低，拆分得越清
03/22 01:19, 39F
→
03/22 01:19, 1年前 , 40F
楚，整體code style會變成一種自然，架構設計的越好sen
03/22 01:19, 40F
→
03/22 01:19, 1年前 , 41F
ior也不會寫出什麼爛code，因為有架構的限制
03/22 01:19, 41F
推
03/22 01:25, 1年前 , 42F
不用鑽牛角尖一些沒啥效能差異的code style，很多理論
03/22 01:25, 42F
→
03/22 01:25, 1年前 , 43F
大家都清楚，該思考的是當下專案怎做才是最大效益
03/22 01:25, 43F
→
03/22 02:05, 1年前 , 44F
讚成G大~
03/22 02:05, 44F
→
03/22 07:58, 1年前 , 45F
你比較喜歡看著一層又一層的if ，可讀性管他去死？
03/22 07:58, 45F
推
03/22 09:02, 1年前 , 46F
我只記得我為了別人一個if else不加{}的bug，追了一天
03/22 09:02, 46F
推
03/22 09:36, 1年前 , 47F
第一次看到程式心理學
03/22 09:36, 47F
→
03/22 09:53, 1年前 , 48F
閱讀性定期
03/22 09:53, 48F
推
03/22 12:24, 1年前 , 49F
TAKADO那句最討厭兩件事好好笑XDDDDDDD
03/22 12:24, 49F
→
03/23 21:18, 1年前 , 50F
Asm 嘛...優化、PGO、UNLIKELY 下下去都好解決的，不該
03/23 21:18, 50F
→
03/23 21:18, 1年前 , 51F
拿來當決定 coding style 的理由
03/23 21:18, 51F
→
03/24 11:43, 1年前 , 52F
在現在的硬體效能下 努力增加程式碼的容易理解程度 比增加效
03/24 11:43, 52F
→
03/24 11:43, 1年前 , 53F
能來的重要多了
03/24 11:43, 53F
推
03/24 14:38, 1年前 , 54F
15F XDD
03/24 14:38, 54F
推
03/24 16:56, 1年前 , 55F
15F XDD
03/24 16:56, 55F
‣ 更多 fatalfeel2 的文章
文章代碼(AID): #1a6KZysj (Soft_Job)
討論串 (同標題文章)
本文引述了以下文章的的內容：
完整討論串 (本文為第 3 之 3 篇)：
排序： 最舊先 | 最新先 | 留言數
在新視窗開啟完整討論串 (共3篇)
Soft_Job 近期熱門文章
更多 近期熱門文章 >>
PTT職涯區 即時熱門文章
更多 即時熱門文章 >>
‣ 更多 fatalfeel2 的文章
文章代碼(AID): #1a6KZysj (Soft_Job)