標籤:經驗 演算法 技術
今天我想說說代碼習慣:
剛開始學Android時相信很多新手都會有一個疑問,我們作為菜鳥除了技術上的不足到底哪點比不上大神呢?相信問這個問題的新手,肯定是一個不服輸的人(不能叫憤青吧,我認
為憤青貌似是個貶義詞)所以喜歡問問題,但是一些經驗豐富的大神有的時候就會說自己百度,不行Google,這麼簡單的問題還問!這可能深深的傷害到我們菜鳥,但挺多時候是應
該我們自己動手找自己研究,其實作為菜鳥不是不喜歡動手自己找自己寫,只是想有個捷徑站在巨人的肩膀上,但是事實卻不是這樣的因為所有的問題要想記得更牢固,更清晰的
理解,的確需要自己找,自己研究雖然這可能費些時間,但是還是有價值的,好了說了這麼多快跑題了下面說說到底該怎樣最佳化代碼代碼寫作習慣代碼規整:
首先是命名,這個我深有體會,老是被公司其他成員說,
注釋:
養成良好的注釋習慣,對提升自己的編程能力和團隊合作能力有很大的益處。
- 不要使用拼音命名(英語不好可以用有道翻譯,但是切忌拼音)
- 名稱應簡潔而富於描述,使用完整單詞,避免使用縮寫(除非該縮寫被更廣泛使用,例如URL、HTML)
- 注釋遵循英文寫作習慣,英文標點符號後空一格,避免句子緊湊
1. 包命名
包名由小寫字母組成,預設以com.example.android開頭,然後接上根據功能劃分的模組名。(這個中間的我們一般都是用公司名命名)
2. 類和介面命名
名稱的首字母需要大寫,如果由多個單片語成,那麼每個單詞的首字母需要大寫,其他字母小寫。
3. 方法的命名
採用駝峰命名法來命名。(這個最好見名知意,讓別人知道你這個方法大概是幹什麼的)
4. 變數的命名
採用駝峰命名法命名。(現在這個變數名Google給了一個小小的規範,就是前面的m)
- 非公用的、非靜態域變數用m首碼
- 靜態域變數用s首碼
- 集合類型的變數使用複數形式,若多種集合類型的變數儲存的是相同類型的對象,除了根據功能區分,也可以簡單通過集合類型來區分
5. ID的命名(這個估計很多同學會亂命名這個挺重要的,對以後看代碼,所以這個要切記)組成名稱的單詞必須全部小寫,單詞之間用底線隔開,名稱不需要複雜的層級定位,只需要準確描述所代表控制項的功能作用即可,通常我們在名稱前使用控制項類型的縮寫首碼來避免重複起名的麻煩。
6.常量的命名
常量需要聲明為final static形式,組成名稱的單詞必須全部大寫,單詞之間用底線隔開。
下面我們講講寫代碼過程中的一些有利於閱讀和代碼規範的介紹:
比如我們在使用中經常使用到的就是:
android:text="確定"
其實這樣寫的話挺方便的但是對於程式和編碼問題卻不方便Google官方建議是這樣寫:
android:text="@string/main_table"(把欄位放到string中去,這樣據說可以加快編譯速度,具體我沒有測過。。。)
還有就是在XML檔案中要用到很多控制項,其中很多控制項有相同的屬性,很多剛開始不太會使用style這個屬性:
對於很多控制項有相同的屬性時我們可以這樣寫
<RadioButton android:id="@+id/rb_main_table" style="@style/main_radiobtn_style" android:checked="true" android:text="@string/main_table" /> <RadioButton android:id="@+id/rb_main_total" style="@style/main_radiobtn_style" android:text="@string/main_total" />
把一些屬性封到Style中:
<style name="main_radiobtn_style"> <item name="android:layout_width">fill_parent</item> <item name="android:layout_height">@dimen/activity_main_radiogroup_height</item> <item name="android:background">@color/menu_radiobutton_bgcolor_selector</item> <item name="android:button">@null</item> <item name="android:drawablePadding">4dp</item> <item name="android:textColor">@color/menu_radiobutton_textcolor_selector</item> <item name="android:textSize">@dimen/normal_textsize</item> </style>
還有就是要看自己的寫法了,就是有的時候在代碼中一個方法中有很多演算法.聲明.加監聽什麼的,使用Adapter之類的,我們可以把,這些抽取成方法,在放到方法中去,比如把Adapter類抽取出來單放到一個類中去,這樣寫出來的代碼在一個類中不會有太多,讓人看起來眼花繚亂。有的很多方法也可以單獨抽取出去放到一個類中,這樣代碼就簡潔很多了呢。。
還有就是我們有的時候可能會用到viewpager,和addView如果view比較多的話,這樣就會造成一個類中的代碼特別多,各種處理,看起來不太好,這個時候我們就可以用Fragment來代替這其中的view,我之前也寫過,就是可以滑動的Fragment中這個就是一個挺好的封裝,省了挺多事,
最後在絮叨一句,就是有時間多看,多動手實踐,最後百度Google都沒有的答案在找大神們問哈!
哪位同學有更好的我們可以一起交流下,以上僅代表我個人看法和建議
Android 最佳化代碼代碼寫作習慣代碼規整