[請益] 如何制訂codestyle?已刪文

看板Soft_Job作者 (ObjC)時間11年前 (2014/02/18 23:04), 編輯推噓16(16推 0噓 35→)
留言51則, 23人參與, 最新討論串1/1
小弟經驗不足，請教各位前輩對Codestyle的統一見解如何？ 如果遇到別人說你寫的Code不好懂，拿著coding guidelines建議你參考， 甚至改掉你的寫法會作何感想呢？ 又如果跟你的習慣差很多，你會改掉自己得習慣嗎？ 我知道滿多人寫Code只求可以Work就好，這些細節是否可以不管它？ -- ※ 發信站: 批踢踢實業坊(ptt.cc) ◆ From: 123.192.244.6
推
02/18 23:10, , 1F
看團隊原本的規範
02/18 23:10, 1F
→
02/18 23:10, , 2F
在團隊裡, 就照著團隊的Style做.
02/18 23:10, 2F
如果團隊還沒有明確的規範呢？ ※ 編輯: PurGle 來自: 123.192.244.6 (02/18 23:11)
→
02/18 23:16, , 3F
有好用IDE就統一團隊formatter如何?
02/18 23:16, 3F
推
02/18 23:17, , 4F
拿GOOGLE的來做參考
02/18 23:17, 4F
→
02/18 23:23, , 5F
同意照團隊的style做
02/18 23:23, 5F
推
02/18 23:23, , 6F
系統要維護，維護也不只是你一個人的事，當然會有一定
02/18 23:23, 6F
→
02/18 23:23, , 7F
的規範，不論是你改別人，或別人改你的程式會有一定的
02/18 23:23, 7F
→
02/18 23:23, , 8F
幫助
02/18 23:23, 8F
→
02/18 23:42, , 9F
還沒有規範的話，就趕緊請團隊訂一個明確的規範.
02/18 23:42, 9F
→
02/18 23:43, , 10F
不然,就參考前人的程式碼怎麼寫的,同一模組內的不要差太多
02/18 23:43, 10F
推
02/18 23:50, , 11F
基本的縮排 命名規則要有 人家一看到沒縮排 爛命名就知
02/18 23:50, 11F
→
02/18 23:50, , 12F
道是新人了
02/18 23:50, 12F
推
02/18 23:59, , 13F
順帶一問 定了但是沒人要理呢?
02/18 23:59, 13F
推
02/19 00:05, , 14F
這種就是找一個夠大尾的上去登高一呼..沒這種腳色就難
02/19 00:05, 14F
推
02/19 00:12, , 15F
看要強制到什麼程度,強的話可以自動化檢查,不通過不准submit
02/19 00:12, 15F
推
02/19 00:39, , 16F
前人怎麼做就跟著做,除非瑕疵很大.
02/19 00:39, 16F
推
02/19 01:57, , 17F
前人用的是匈牙利命名法...follow反而更難用
02/19 01:57, 17F
推
02/19 02:44, , 18F
還要管coding style,此團隊的leader肯定不太強
02/19 02:44, 18F
→
02/19 02:45, , 19F
很多人不經思考,人云亦云,以為管人家的coding style是好事
02/19 02:45, 19F
→
02/19 09:58, , 20F
要看情況啦，有些可能混亂陣營屬性太高的也沒辦法維護...
02/19 09:58, 20F
→
02/19 10:01, , 21F
codestyle不包含寫法，會改到寫法通常程式邏輯應該是有問
02/19 10:01, 21F
→
02/19 10:01, , 22F
題，至於排版請他寫成ide用的template 。
02/19 10:01, 22F
推
02/19 10:30, , 23F
匈牙利命名法真的是很鳥的東西
02/19 10:30, 23F
→
02/19 10:44, , 25F
聽到匈牙利命名法就是 cue 這個連結的暗號
02/19 10:44, 25F
→
02/19 10:53, , 26F
看完裡面的C範例後，我有點理解為什麼有人認為Joel先生是個
02/19 10:53, 26F
→
02/19 10:53, , 27F
嘴砲王.
02/19 10:53, 27F
推
02/19 15:18, , 28F
看最初版怎麼寫 就follow他的....
02/19 15:18, 28F
→
02/19 15:18, , 29F
之前接過一個tab限定5個空白 命名還有一大堆規則寫成文件....
02/19 15:18, 29F
→
02/19 15:19, , 30F
什麼global一定要g_開頭、member一定要m_開頭之類的= =
02/19 15:19, 30F
推
02/19 21:00, , 31F
recommend a book "code complete"
02/19 21:00, 31F
推
02/20 23:21, , 32F
個人做法是盡量站在別人角度想...思考怎樣可以讓人快速
02/20 23:21, 32F
→
02/20 23:21, , 33F
了解你的code
02/20 23:21, 33F
推
02/20 23:26, , 34F
要改掉習慣很難，要人家跟著你的習慣走更難，比起統一s
02/20 23:26, 34F
→
02/20 23:26, , 35F
tyle，每個人都用自己的方法但是站在維護者的角度思考
02/20 23:26, 35F
→
02/20 23:26, , 36F
來寫，還比較簡單吧
02/20 23:26, 36F
→
02/21 11:17, , 37F
幾乎每個 open source project 都有限定 coding style
02/21 11:17, 37F
→
02/21 11:17, , 38F
只能說這東西是有意義的，不懂得遵守的人通常技術沒到家
02/21 11:17, 38F
→
02/21 11:18, , 39F
想要抄的話 有幾個大家常用的
02/21 11:18, 39F
→
02/21 11:18, , 40F
1) Linux kernel 2) KDE/Qt 3) LLVM
02/21 11:18, 40F
→
02/21 11:19, , 41F
其中KDE/Qt 用的就是改良的匈牙利
02/21 11:19, 41F
→
02/21 11:19, , 42F
在大型軟體專案當中 匈牙利有其快速搞懂記憶體配置的優點
02/21 11:19, 42F
→
02/21 11:20, , 43F
可以大幅加速資深工程師讀code的速度
02/21 11:20, 43F
→
02/21 11:21, , 44F
可以讓人一眼分出auto/static/dynamic storage
02/21 11:21, 44F
→
02/21 21:46, , 45F
如果只用純文字記事本能用 我才會考慮匈牙利吧...XDDDD
02/21 21:46, 45F
→
02/22 06:56, , 46F
相信匈牙利命名法命名出來的變數是災難的開始
02/22 06:56, 46F
→
02/22 06:57, , 47F
確保每個變數都正確命名是不實際的
02/22 06:57, 47F
→
02/22 09:29, , 48F
信不信任是取決於團隊品質的...
02/22 09:29, 48F
推
02/26 14:34, , 49F
命名是整個軟體開發最重要也是最困難的事
02/26 14:34, 49F
→
02/26 14:35, , 50F
好的命名就是好的故事鋪陳 會說故事才能寫好軟體
02/26 14:35, 50F
→
02/26 14:35, , 51F
匈牙利是在說 storage allocation 的故事，如果連這點都看不
02/26 14:35, 51F
‣ 更多 PurGle 的文章
文章代碼(AID): #1J0tQQzY (Soft_Job)