節錄部份
ptt.cc
=============================================================
作者 hegemon (hegemon) 看板 Soft_Job
Java Code都要符合CheckStyle Plugin的標準.
tab跟四個space,括號前後space,或是變數大小寫
一個method不能超過一百五十行,一個method不能代入超過七個變數.
========================================================================
作者: newjoy (職業格鬥家) 看板: Soft_Job
<軟體建構之道>(code complete)裡面就有提到
"人腦所能掌握的物件個數大約在七個左右, 所以變數跟參數最好不要超過7"
掌握設計時真正的想法, 才能循線把整個設計實作出來
設計師把衣服的設計圖畫好, 材質選好, ......然後送給中國大陸去製造
然後成品就整個毀了...
由於製作的工人完全不能體會設計者的用心, 作出來的成品自然參差不齊.
========================================================================
根據統計, 只要一個method超過這個行數, 可能就要思考一下另行的作法了
另一方面也是為了code可讀性的關係.
所以, 當參數個數太多的時候, 你可能要考慮一下是不是要把這些參數包成一個
private的class, 然後user看class name就大概能知道這裡面的參數是什麼用途.
ex :
菜刀
覘板
牛肉
鹽
的參數可以包在一個叫做"晚餐材料"的class裡面傳遞給method.
==========================================================================
一個method 不能超過 150行, 也是為了怕沒經驗的coder把一堆有的沒的全部寫在
同一個method裡面, 造成可讀性&複用性差(而且會這樣通常是copy & paste造成的).
通常如果幾行code描述一件事, 那最好就用一個method把這件事包起來.
比如說 :
脫外褲;
脫內褲;
大便;
沖水;
穿內褲;
穿外褲;
看的人可能要一直讀到一個段落才能了解你的意思, 那乾脆就直接包成一個叫
"去上大號"的method, 清楚多了
=========================================================================
因為就你所說的情況, 很明顯是因為整個程式整體架構的問題,
現行有ORM比如引入Hibernate可以減少SQL行數的問題,
反正絕對不是幾個小coder敲敲鍵盤全手工打造 + check style
就能在一兩個月內解決的, (這是架構問題, 應該是project leader要解決的)
在沒整體修改架構前, 反而會為了要遵守這個check style而產生更多問題.
另外, 一支優秀的API, 註解比code多很多才能讓user用得很安心
這個150行的限制竟然包含註解絕對是錯的
這豈不是鼓勵大家為了就範而產生大量無註解的爛code嗎?
=========================================================================
如果不清楚原因跟相對應的OO寫作技巧
而硬是要去遵守150行限制, 會產生一大堆沒有內聚力的
classA-1
classA-2
classA-3
這是OO典型的anti-pattern阿! 它本來是想解決code難以閱讀維護的問題,
但是方法沒用對, 反而造成更大的問題. (比全部寫在同一隻code還難trace)
沒有留言:
張貼留言