非空判斷
// bad
if(user.
getusername()
.equals
("hollis"))
//good
if(user!=null&&
"hollis"
.equals
(user.
getusername()
))
避免了兩種會出現空指標異常的情況:user == null 時,get會異常。user != null但user.username == null時equals會異常。
拓展,如何在專案中減少null的判斷,需要保持乙個好習慣:每個方法都不要返回null,盡量用空集合或者空值物件替代null。
用stringbuffer代替string
// bad
string s ="";
for(
int i =
0; i < field.length;
++i)
// good
stringbuffer buf =
newstringbuffer()
;for
(int i =
0; i < field.length;
++i)
string s = buf.
tostring()
;
儘量減少對變數的重複計算
明確乙個概念,對方法的呼叫,即使方法中只有一句語句,也是有消耗的,
// bad
for(
int i =
0; i < list.
size()
; i++
)// good
for(
int i =
0, length = list.
size()
; i < length; i++
)
// bad
domethod
(user.getdepartmentid)
;domethod2
(user.getdepartmentid)
;// good
string departmentid = user.getdepartmentid;
domethod
(departmentid)
;domethod2
(departmentid)
;
盡量採用懶載入的策略
只在需要用到的時候才建立,除非其他地方也需要這個變數。
盡量不要建立不用的物件,也不要引用沒有用到的,寫完乙個方法及時清理掉多引入的包。
// bad
string str =
"aaa";if
(i ==1)
// good
if(i ==1)
try catch使用要謹慎
不要在迴圈中使用try…catch…,應該把其放在最外層。另外不要濫用,有些程式設計師對**沒有信心,每個方法進來就try一下,這個對程式沒有好處。
手動分配長度
在建立arraylist、linkedllist、stringbuilder、stringbuffer、hashmap、hashset等物件時,盡量給出長度。
// bad
newarraylist
<
>()
;new
stringbuilder()
;// good
newarraylist
<
>(10
);newstringbuilder(10
);
迴圈內需要的物件盡量在迴圈外定義// bad
for(
int i =
1; i <= count; i++
)// good
object obj = null;
for(
int i =
0; i <= count; i++
)
加鎖粒度盡量小
比如synchronized加在方法上沒有加在具體**塊上面好。
還有加鎖在**上不如給某個引數上鎖。比如你有乙個根據不同款式生成唯一訂單號的邏輯,如果直接加synchronized,會導致這個**一次只能處理乙個請求,但是如果給每個款式配一把鎖(可以借助redis實現),那麼你的**就可以同時處理很多訂單請求了。
事務宣告
宣告事務時註解@transactional放在類上不如放在方法上。放在controller上不如放在service方法上。
如果你的方法只有一次資料操作,那麼就不要開啟事務了。
常量名大寫,單詞之間使用下劃線連線
普通變數使用駝峰命名
方法中形參過多可以用乙個實體或者map進行封裝
// bad
public
void
method
(string username,integer userage,string user***,string useraddress)
// good
// 如果使用map最好寫乙個注釋將所有引數列出來。
public
void
method
(user user)
特殊數字或者字元用變數或者常量先定義// bad
// 這有個魔鬼數字 提成 = ** * 0.2
double percentage = price *
0.2;
// good
// 提成係數
double coefficient =
0.2;
double percentage = price * coefficient;
應該使用collection.isempty()檢測空// bad
if(collection.
size()
==0)// good
if(collection.
isempty()
)// best
// 包含了 collection == null的判斷
if(collectionutils.
isempty
(collection)
)
良好的程式設計規範
制定程式設計規範的目的 1 保證 的可讀性 2 保證 的維護性 如aa bb 之類的命名是不符合程式設計規範的,後期維護的過程中,面對成百上千的 很快便會不知道這些常量和變數的意義了,給後期維護帶來的麻煩是不可小覷的 要體現 之美,可以從以下方面改進 1 簡潔,避免冗餘,要使 統一,易於閱讀,就要做...
程式編碼應保持良好的規範(C )
呵呵,這個簡直是超級老生常談了。但我還是希望能讓更多的程式設計師能了解一些細節習慣對於程式閱讀性的影響。而這個很大程度決定了程式的可移植性。1。變數賦值之間注意保留空格。有些程式設計師往往不注意。不好的 body.txtversion.text ib.version.tostring body.or...
怎樣保持良好的心態
有一位朋友有一次氣沖沖的跟我說 氣死我了!我剛剛發現我一位員工出了錯,令產品出現了質量的問題,我修理了他一頓。我問 你認為你的生產流程裡面可能一點錯誤都沒有嗎?他說 應該不可能吧。我說 你現在發現了乙個錯誤,那就避免這個錯誤讓你客戶發現了,那你不是應該高興嗎?他遲疑了一下然後說 好像是對,但心態一時...