[閒聊] Coding Style

看板Soft_Job作者yangyr (山頭斜照卻相迎)時間12年前 (2013/03/24 17:18)推噓6(6推 0噓 19→)

留言25則, 12人參與討論串1/1

[前言] 基本上我覺得我不怎麼強，失業在家閒閒的才會寫這些，所以如果有問題請大力鞭，可以學東西，感謝 (鞠躬) :p ================================================================== 偶然聊天聊到Coding Style，突然想寫些東西。 Coding Style要直譯的話，也許可以翻譯為程式風格? 但其實這是一個不容易解釋的東西。之前的某工作碰到Coding Style這個東西之後，不自覺開始去研究，才發覺就兩個word，卻包含了太多太多的學問。將其視為程式風格，應該是最一般的認知。可以去規範Naming Rule，可以去規範coding時的一些一致性要求如縮排之類，以增強可讀性，甚至詳盡到規範coding時勿犯的錯誤..那問題就來了。問題1：Coding Style這東西是軟體開發時必要的嗎? 相信對軟體業始終要死不活的台灣來說，一定很多老闆會覺得，東西「能動就好啦」，誰去管你怎麼寫的? 但很弔詭的是，在我的認知裡，Coding Style這東西反而是為老闆而準備的。如果我只是在寫自己的程式，如果全公司只有我一個programmer，根本不用去顧慮一致性這種東西。對頂尖的programmer來說 (不是我) ，要求他們的程式有可讀性，可能反而是扼殺他們天馬行空的想像力。但偏偏現實通常不是這樣的，只要是與人合作coding，只要這軟體將來成為產品需要有人維護，只是將來公司還想繼續賣這個產品..可讀性便成為了一個baseline，也許這也算是軟體工業化的初步概念，是軟體品質要求的第一步。問題2. Coding Style對programmer有意義嗎? 前面說到Coding Style可以增強可讀性，使整套原始碼易於維護。但對 programmer來說，Coding Style有意義嗎? 我認為是有的，這可以分兩個層面來看，維護Coding Style的programmer與一般programmer。想當然爾，能制訂一套Coding Style出來的人，必然是programmer，而且是對整體需求有一定了解，自己也有一定水準的programmer。而且在制訂的過程中，也會經由不斷的取捨、調整、深究技術內涵的過程中獲益良多。而這種過程也可能不是單向的，一般的programmer也可以基於自身的了解回饋之，與維護者就某議題深入討論，使一套Coding Style更加完備。就算只是遵循現成的Coding Style，一般的programmer都可以從中挖掘出以前可能未曾深究的問題─好吧，我承認我就是因為這樣，會喜歡去看Google C++ Style Guide之類的東西─不僅僅只是follow而已，一份面面俱到的 Coding Style，其實包含了很多的技術性思考成果，從中可以了解人家可能使用了哪些技術，為什麼要這麼規範，以避免就像以前一樣，寫出可能有潛在錯誤的code.. Coding Style可以精進技術，傻嗎? 或許吧，我想我一直很傻。問題3：Coding Style的範圍到底多廣? 就之前的經驗來說，Naming Rule的規範，coding時的一致性風格，甚至也有人條列coding的建議或應避免的潛在問題─以C++而言，Effective C++這系列名著的內容，「部份」就可能在Coding Style裡出現─ 麻煩就在於「部份」這種不精確的詞彙。難道Coding Style是這麼的不嚴謹? 在我的認知裡，是的，並沒有一套一體適用的Coding Style。隨著程式語言的不同，公司產品及專案性質的差異，Coding Style都應該因地制宜、因時制宜而有所調整。程式語言的差異比較容易理解，如果語法不同，自然會造就不同的coding style。但其它呢? 舉個例子好了，C/C++裡的Null Pointer Check，在我一開始接觸Coding Style時，被教導的是函式參數 (function parameter) 如果有pointer，函式的進入點就應該要做Null Pointer Check。可是寫了一段時間之後，一方面是需要去整理一些亂七八糟的code，改著改著慢慢就產生了疑惑─檢查函式引數 (function argument) 是合理的，畢竟有問題的輸入需要處理或排除；但每一次檢查都是一個運算，是不是真的有必要在每一個函式進入點都檢查null pointer? 後來也確實看到提倡減少這類檢查的說法，所以有另外一個觀念是，如果此函式僅會被內部呼叫，傳入的是較為安全的引數，可以不做Null Pointer Check以減少運算。但這代表我一開始被教導的觀念錯了嗎? 也許不盡然，如果負責撰寫的是 API之類的函式，因為無法期待外部傳入引數的正確性，所以檢查也是合理的，對吧? 那這兩種觀念是否有所牴觸而令人無所適從呢? 我想，取決於不同的時空背景，需要不同的處理方式，這就是說Coding Style難以一體適用的原因，隨著產品及專案、負責內容的不同，需要去調整Coding Style的內容，甚至隨著技術的演進，Coding Style也該與時俱進 ..可能這是個人比較龜毛的想法，但連Code Complete這本大作都一直沒完全看完的廢柴來說 (我啦) ，也只能砥礪自己不斷前進了。 (其實還想到 goto這個議題，不過扯下去沒完沒了) 曾經有一個異想天開的想法，programmer應該都不太喜歡寫文件吧? 是不是可以藉由理想的Coding Style (包含命名及註解)，讓code就像文件一樣易於閱讀，把對文件的依存度減到最低? 再怎麼說明的文件，不過就是在重複闡述既存的code? 當然自己也trace過那種繼承體系不易理解又沒文件的物件導向架構，有夠痛苦的，這個念頭暫時就是想想就好.. -- 從過去到未來，世界與我的對話..都在那些我努力寫下的篇章 http://dflucifer.wordpress.com/ 料峭春風吹酒醒，微冷，山頭斜照卻相迎。 -- ※ 發信站: 批踢踢實業坊(ptt.cc) ◆ From: 123.110.229.165

→

landlord

03/24 17:29, , 1^F

03/24 17:29, 1^F

→

landlord

03/24 17:29, , 2^F

03/24 17:29, 2^F

推

jonastan

03/24 17:39, , 3^F

03/24 17:39, 3^F