java programming hygiene - for didc

Java Programming Hygiene - for DIDC

廖峻鋒June 2,2004NCCU Computer Center

國立政治大學電子計算機中心

Introduction Following figures are selected from the book

“Anti-Patterns” by William J. Brown et al.


權威式管理


主管過份簡化問題


不相信也不願意「 Reuse 」


太驕傲


喜歡把簡單的事情弄複雜


Programming Hygiene Programming Hygiene was proposed by Bruce

Tate in Bitter Java.(Chapter 9) Establishing a good coding style standard

in a company helps to prevent anti-patterns.


Bad smells

當我們發現程式碼中有「不好」的寫法時，我們會說這段程式碼很臭 (bad smell) 。

資深的程式設計師可以很容易地察覺 Bad Smell ，Peer Review 也可以幫助我們找出 Bad Smell

Bad Smell 就是重構下手的主要對象。


什麼是品質好的程式碼 ? (by Kent Beck) 容易閱讀大部份的變異可以在同一個地方改動新的改動不易讓程式爛掉條件邏輯應儘可能簡單


建立共同的編程風格標準在 XP 中採用共同的 Code Convention 名列十二項核心務實作法之一。

After Gold Rush : 現在的軟體界是團隊作戰的時代，團隊中一位功力很強但作風特立獨行的軟體工程師可能反而對軟體開發造成傷害。

透過 Peer Review ，工程師間互相討論良好的設計方式。


A code compiled without error

Class Product {int price = 50;public void setPrice(int price) { …(50 行 code)

int i = price; …(50 行 code)}}


Class Product {int price = 50;public void setPrice(int price) {

// …(50 行 code) int i = price; // which price ?// 案蠀 0ق 行 code)

}}


class Product {int defaultPrice = 50;public void setPrice(int price) {

// …(50 行 code) int i = price; // which price ?// …(50 行 code)

}}


Another Example


不要忽視 Coding Style 程式、註解風格及變數命名方式若能一致，對開發團隊的效率有很大幫助。

程式設計師仍有很大的自由創造空間。 Code Style 嚴重影響程式碼的品質。


Java 的程式慣例 Java 早有官方版本的程式慣例

Java Language:• http://java.sun.com/docs/codeconv/html/CodeConvTOC

.doc.html J2EE:

• http://java.sun.com/blueprints/code/namingconventions.html JSP:

• http://developer.java.sun.com/developer/technicalArticles/javaserverpages/code_convention/

Java 的程式慣例已廣泛被採用從 JDK 的 source code 開始，到所有範例程式碼，都完全配合

這個 convention 。連 OpenSource 的 Java 程式也幾乎都是按照這裏所規定的 Style 來寫程式


.NET 的程式慣例 .NET 目前沒有官方版本的程式慣例。目前已有社群參考 Java 的程式慣例規格書格式開始制定 Coding Style 。在開發社群中最廣泛被採用及認同的版本

http://www.icsharpcode.net/TechNotes/


Deprecated Naming Conventions

The following naming convention are considered as bad practice (include Microsoft)!

Hungarian 傳統 windows 程式及 win32 API 大量採用。把型別加在變數的最前面。例如 sName 表示 string 型別。

Under score 若變數超過一個字，用“ _” 分隔。在 c 語言中常用。 stu_num 、 reg_sts 。


目前通用的命名慣例 Pascal Notation

首字大寫例如 :EventHandler 、 XmlDocument 等等。

Camel Notation 首字小寫，後續大寫。例如 :userId 、 dayOfWeek 、 studentName 等等。

Visual Studio.NET 所產生的程式碼不符合 Naming Convention 。事件處理函式仍有 under score 介面仍用 Hungarian ，例如 IEnumberable


命名範例一個功能是「取消」的 Button 。

btnCancel -> cancelButton 有顏色的多邊形

ColoredPolygon 儲存分享資料的地方

ServletContext 、 BCSSContext 縮寫

HttpServlet 、 URLConnection


Comments


相關文件 C# Coding Style Guide The fine Art of Commenting Technical Writing made easier


Refactoring

重構是什麼 ? 改善程式碼的一種方法論。對軟體內部結構的一種調整，在不改變「外部可觀察到的行為」的前提下，提高軟體的可理解性，降低修改成本。

如何確保「外部可觀察到的行為」不變 Unit Testing!


重構時不會影響到程式之外顯行為

外部使用的類別對其變化沒有感覺


重構幫助設計師看到設計層面的問題 M.Fowler : “隨著程式碼漸趨簡潔，我發現自己可以看到一些以前看不到的設計層面的東西。如果不對程式碼做這些修改，也許我永遠看不到他們，因為我的聰明才智不足以在腦子裏把這一切都想像出來。”

Ralph Johnson : 擦掉窗戶上的污垢，使你看得更遠。


為何要重構 ? 不重構軟體很快就會爛掉增進可重用性 [Gof95]Design Patterns 為重構提供了目標。有機會做抽象化並找出 Framework 。 Lets you worry about generality tomorrow;

( 可以不需要在一開始就寫出漂亮的程式，可以先開發再重構 )


何時要進行重構 ? The rule of three 功能增加時。修補 Bug 時。 Code Review 之後。完成一個功能之後，又察覺 bad smell 時。


如何重構一次一小步 :Make changes as small as possibl

e. Many small changes are easier than one big chang

e. 每次改變都要測試 :Test after each change.


二種不同型式的重構 Visible refactoring Invisible refactoring


Visible refactoring

重構的改變在 UML圖上看得到


使用 Collection 取代多重 if 敘述

String foundPerson(String[] people){

for (int i = 0; i < people.length; i++) {

if (people[i].equals ("Don")){ return "Don"; }

if (people[i].equals ("John")){ return "John"; }

if (people[i].equals ("Kent")){ return "Kent"; } } return "";

}

String foundPerson(String[] people){

List candidates = Arrays.asList(new String[] {"Don", "John", "Kent"});

for (int i=0; i<people.length; i++)

if (candidates.contains(people[i]))

return people[i]; return "";

}

Invisible refactoring

重構的改變在 UML圖上看不到


Bad Smell Examples

Duplicate Code Long Methods Large Classes Long Parameter Lists Too Many Case Statements 程式變數命名不良。程式沒有根據 Code Standard 。過多的註解。


Duplicate code

重複的程式碼出現在不同的地方多次。如何解決 ?

making new methods making new objects moving methods to common superclass


Long methods

一個 Method 應該只負責一項任務 Method should fit on the screen. Method should be in right class.


Large classes

More than 7 variables More than 15 methods

You probably need to break up the class 可使用一些 Design Patterns 手法解決 (Strateg

y, Composite, Decorator)


Long parameter lists

參數數目若超過 4 個就太多了 ! If you see the same set of parameters repeate

d in several methods, bundle them into a new object. (將相關的參數化成新類別 )


Case Statements

使用多型加上 Collection 取代多重 if或 switch敘述。

使用 Strategy Pattern 。


重構 :An Example

IfxDB

IfxDB

ConnectionManager

客戶類別

客戶類別

( 詳見下頁 )DB1DB2DBDB

DB1DB2DB DB


ConnectionManager


大型重構


Q & A

Slides and documents available athttp://java.cc.nccu.edu.tw

java programming hygiene - for didc

Documents