本章我們將對OpenWnn的代碼問題進行解析，從命名、註釋、結構和風格四個方面分別進行闡述。
什麽是OpenWnn呢？
我在前面的博客裏至少兩次提到這個工程。這是壹個Android下的開源日文輸入法，由Omron Software Co.,Ltd 開發。從Android CupCake開始公開。據說它支持中日英韓四語輸入（我只試過日語和英語，沒有找到中文和韓語）。
如何才能夠獲得OpenWnn的源代碼呢？
妳可以按照Android的源代碼下載指南進行下載，也可以在搜索引擎上搜搜找到。
下面是壹個可用地址：
http://gitorious.org/sourcecode/google_android_2_2/trees/e850cee/jp/co/omronsoft/openwnn
為什麽選擇OpenWnn
第壹個原因是這段代碼整體感覺就是壹些沒有什麽經驗的程序愛好者坐在壹起寫的。
第二個原因是因為他是我所接觸過的劣質代碼中唯壹可以公開的源代碼。
在了解為什麽它很糟糕之前，請先下載它的代碼，並且在Android模擬器或者設備上運行壹下看看。
然後對Android輸入法的基本概念有所了解。然後再繼續閱讀下面的內容。否則有些地方可能會沒有頭緒。
本文的目的在於討論編碼方面的問題，不討論易用性、軟件質量方面的問題。
---------------------分割壹下---------------------
壹、命名問題
1.否定式命名
嚴重程度：高
否定式命名讓讀者閱讀的時候必須停頓壹下才能夠理解。比如if(!mNoInput)就不如if(hasInput())容易理解。
OpenWnn中有好幾處否定式命名
DefaultSoftKeyboard.mNoInput 表示沒有輸入
DefaultSoftKeyboard.mDisableKeyInput 表示禁止鍵盤輸入
DefaultSoftKeyboard.mHardKeyboardHidden 表示硬鍵盤隱藏
OpenWnnJAJP.onUpdateSelection中的isNotComposing 表示沒有選中ComposingText
但是，這並不是說，否定式命名壹定不好，比如INVALID_KEYMODE就很好。
2.序號式命名
嚴重程度：高
序號式命名是諸如var1,var2...varn這樣形式的命名，讀者無法從1~n中獲取什麽有價值的信息。
OpenWnn中的序號式命名
ComposingText.LAYER0,LAYER1,LAYER2表示英文->假名->漢字三層轉換。
其實命名為LAYER_ALPHABET, LAYER_KANA, LAYER_JAPANESE會更好壹些。
3.用詞不當
嚴重程度：低
用詞不當是指壹個命名用了壹個接近於真實意思的詞匯，但是並不貼切，有更好的詞匯可以表示更貼切的意思。
DefaultSoftKeyboardJAJP.mLimitedKeyMode表示允許切換的受限制的鍵盤種類數組。實際上Constraint比Limited會更加貼切的表示這個意思。
OpenWnn.LIMIT_INPUT_NUMBER表示最大允許輸入長度，實際上，可以命名為MAX_INPUT_LENGTH;因為LIMIT和NUMBER都有其他意思。
4. 詞不達意
嚴重程度：中
用的詞匯並不能準確的表達真實意思的，歸類為詞不達意。詞不達意的情況會引起讀者的誤解。
比如：OpenWnnJAJP.updatePrediction方法中的第壹個變量candidates，光看命名它應該是數組，List之類的變量，然而它卻是壹個int型變量，用來存儲候補的個數的。正確的命名是candidatesCount。
5. 言行不壹
嚴重程度：高
言行不壹是指方法或者類執行了其聲明的作用以外的工作。這種問題很嚴重，如果別人（包括幾個月之後的自己）來接手該代碼的時候，打算通過名稱復用代碼的時候就要十分小心，然而這種十分小心卻是人為錯誤引起的。如果命名和實際作用壹致那麽準備復用代碼的人也就不必過多的考慮了。
DeafultSoftKeyboardJAJP.toggleShiftLock()，同時調用了ChangeKeyboard()方法。
而ChangeKeyboard會更新很多底層數據...這也涉及到結構的問題。將會在結構性分析中詳細解析。
6.前綴、後綴使用錯誤
嚴重程度：低
前綴、後綴使用錯誤的時候對閱讀會形成壹定的障礙（讀起來有點怪而已），但是並不影響整體閱讀。
has~/is~/等就是用於方法的前綴是不應該用於變量的。
OpenWnnJAJP.mHasContinuedPrediction 想表達是否有後續的預測， 但是這個變量如果命名為mPredictedFurther就可以達到1)縮短命名,2)規避了不當用詞的問題。同樣的，在TextCandidateViewManager中也有幾個類似的命名:mIsFullView，mIsScaleUp。
~Current前綴壹般如果出現是和Prev, Next並列出現的，單獨的Current沒有任何意義。
DefaultSoftKeyboard.mCurrentKeyboard的Current沒有意義。
~List, ~Map不應該出現在後綴中，這也許是受了匈牙利命名法的影響，但是命名中附帶List,Map是沒有必要的。
比如：keyboardList 可以寫成keyboards.
7.長命名
嚴重程度：中
長命名導致閱讀費力。這是公認的問題。
OpenWnnJAJP.processKeyEventNoInputCandidateShown(KeyEvent ev)方法當屬其中壹個
這個命名長的原因是：其中包含了壹定的限制條件：No Input + Candidate Shown(參考調用的代碼才知道這是兩個限制條件)。所以，這個命名其實是結構性問題。這將在結構性問題中詳細討論。這裏簡單的提壹下如何解決這個問題。
其實這段代碼是想解決在Candidate顯示時，左右鍵以外的其他非輸入性按鍵的動作的問題。那麽，這個應該交給OpenWnn.onKeyDown來處理，這個方法應該將各種按鍵進行分類，然後交給不同的分類去處理。那麽這段處理可能屬於FunctionalKey.onKeyDown和ArrowKey.onKeyDown。
8.本地語命名
嚴重程度：低
本地語即采用只有本地人才能明白的詞匯來命名的情況。OpenWnn其中有很多日語命名的情況。除了必要的Hiragana,Katakan之類的命名之外，有些並不應該用本地語來命名。比如isRenbun(這個拼寫還有錯誤，其實想寫的是isRenban)表示連續的數字（ContinuousNumbers）
DefaultSoftKeyboard.KEYCODE_QWERTY_ZEN_HIRA
DefaultSoftKeyboard.KEYCODE_QWERTY_HAN_NUM
其中的HAN和ZEN是表示半角和全角的，如果改成HALF和FULL就易懂的多。
其他的還有：EISU_KANA, convHansuuji, convHanEiji, convZenEiji, moji, inputRomaji等。
由於這個是開發的輸入法，所以這個問題的嚴重程度定為：低，其實這個對於其他的讀者來說是壹個比較大的閱讀問題。
9.類似的命名
嚴重程度：中
命名類似，但是表示不同的意思的情況會引起閱讀問題，也會引起調用問題。
OpenWnn.mHardShift, OpenWnn.mShiftPressing, OpenWnnJAJP.mShiftOn這三個到底有什麽區別呢？
10.大寫字母命名
嚴重程度：中
采用大寫字母進行命名會導致很多問題，包括將來如果采用反射時對於首字母大寫的設定時會產生規則例外。OpenWnn中的包JAJP命名和EN命名就屬於這種情況。還有WnnPOS類也是這種情況。
11.無意義的命名
嚴重程度：高
面對無意義的命名，讀者無法從中獲取有效的信息，也不知道應該如何使用這樣的對象（方法、變量）。
KanaConverter中的mStringBuff就是這樣壹個變量。