首先,編程風(fēng)格并不同于其他的style，目的并不是形成自己獨(dú)樹一幟的風(fēng)格，而是為了讓你的程序易讀,有利于團(tuán)隊(duì)合作以及別人幫你改錯(cuò)。
鯉城網(wǎng)站建設(shè)公司創(chuàng)新互聯(lián),鯉城網(wǎng)站設(shè)計(jì)制作，有大型網(wǎng)站制作公司豐富經(jīng)驗(yàn)。已為鯉城千余家提供企業(yè)網(wǎng)站建設(shè)服務(wù)。企業(yè)網(wǎng)站搭建\外貿(mào)網(wǎng)站建設(shè)要多少錢，請找那個(gè)售后服務(wù)好的鯉城做網(wǎng)站的公司定做！
風(fēng)格是通用的
C語言和C++語言的編程風(fēng)格 （Java見下）
第一章:縮進(jìn)格式
Tab是8個(gè)字符,于是縮進(jìn)也是8個(gè)字符.有很多怪異的風(fēng)格,他們將縮進(jìn)格式定義為4個(gè)字符(設(shè)置為2個(gè)字符!)的深度,這就象試圖將PI定義為3一樣讓人難以接受.
理由是:縮進(jìn)的大小是為了清楚的定義一個(gè)塊的開始和結(jié)束.特別是當(dāng)你已經(jīng)在計(jì)算機(jī)前面呆了20多個(gè)小時(shí)了以后,你會(huì)發(fā)現(xiàn)一個(gè)大的縮進(jìn)格式使得你對(duì)程序的理解更容易.
現(xiàn)在,有一些人說,使用8個(gè)字符的縮進(jìn)使得代碼離右邊很近,在80個(gè)字符寬度的終端屏幕上看程序很難受.回答是,但你的程序有3個(gè)以上的縮進(jìn)的時(shí)候,你就應(yīng)該修改你的程序.
總之,8個(gè)字符的縮進(jìn)使得程序易讀,還有一個(gè)附加的好處,就是它能在你將程序變得嵌套層數(shù)太多的時(shí)候給你警告.這個(gè)時(shí)候,你應(yīng)該修改你的程序.
第二章:大符號(hào)的位置
另外一個(gè)C程序編程風(fēng)格的問題是對(duì)大括號(hào)的處理.同縮進(jìn)大小不同,幾乎沒有什么理由去選擇一種而不選擇另外一種風(fēng)格,但有一種推薦的風(fēng)格,它是Kernighan和Ritchie的經(jīng)典的那本書帶來的,它將開始
的大括號(hào)放在一行的最后,而將結(jié)束大括號(hào)放在一行的第一位,如下所示:
if (x is true) { we do y }
然而,還有一種特殊的情況:命名函數(shù):開始的括號(hào)是放在下一行的第一位,如下:
int function(int x) { body of function }
所有非正統(tǒng)的人會(huì)非難這種不一致性,但是,所有思維正常的人明白: (第一) KR是___對(duì)___的,(第二)如果KR不對(duì),請參見第一條. (:-))......另外,函數(shù)也是特殊的,不一定非得一致.
需要注意的是結(jié)束的括號(hào)在它所占的那一行是空的,__除了__它跟隨著同一條語句的繼續(xù)符號(hào).如"while"在do-while循環(huán)中,或者"else"在if語句中.如下:
do { body of do-loop } while (condition);
以及
if (x == y) { .. } else if (x y) { ... } else { .... }
理由: KR.
另外,注意到這種大括號(hào)的放置方法減小了空行的數(shù)量,但卻沒有減少可讀性.于是,在屏幕大小受到限制的時(shí)候,你就可以有更多的空行來寫些注釋了.
第三章:命名系統(tǒng)
C是一種簡潔的語言,那么,命名也應(yīng)該是簡潔的.同MODULE-2以及ASCAL語言不同的是,C程序員不使用諸如ThisVariableIsATemporaryCounter之類的命名方式.一個(gè)C語言的程序員會(huì)將之命名為"tmp",這很容易書寫,且并不是那么難以去理解.
然而,當(dāng)混合類型的名字不得不出現(xiàn)的時(shí)候,描述性名字對(duì)全局變量來說是必要的了.調(diào)用一個(gè)名為"foo"全局的函數(shù)是很讓人惱火的.全局變量(只有你必須使用的時(shí)候才使用它) ,就象全局函數(shù)一樣,需要描述性的命名方式.假如你有一個(gè)函數(shù)用來計(jì)算活動(dòng)用戶的數(shù)量,你應(yīng)該這樣命名--"count_active_users()"--或另外的相近的形式,你不應(yīng)命名為"cntusr()".
有一種稱為Hungarian命名方式,它將函數(shù)的類型編碼寫入變量名中,這種方式是腦子有毛病的一種表現(xiàn)---編譯器知道這個(gè)類型而且會(huì)去檢查它,而這樣只會(huì)迷惑程序員. --知道為什么Micro$oft為什么會(huì)生產(chǎn)這么多"臭蟲"程序了把!!.
局部變量的命名應(yīng)該短小精悍.假如你有一個(gè)隨機(jī)的整數(shù)循環(huán)計(jì)數(shù)器,它有可能有"i",如果沒有任何可能使得它能被誤解的話,將其寫作"loop_counter"是效率低下的.同樣的,""tmp"可以是任何臨時(shí)數(shù)值的函數(shù)變量.
如果你害怕混淆你的局部變量的名字,還有另外一個(gè)問題,就是稱
function-growth-hormone-imbalancesyndrome.
第四章:函數(shù)
函數(shù)應(yīng)該短小而迷人,而且它只作一件事情.它應(yīng)只覆蓋一到兩個(gè)屏幕(80*24一屏),并且只作一件事情,而且將它做好.(這不就是UNIX的風(fēng)格嗎,譯者注).
一個(gè)函數(shù)的最大長度和函數(shù)的復(fù)雜程度以及縮進(jìn)大小成反比.于是,如果你已經(jīng)寫了簡單但長度較長的的函數(shù),而且你已經(jīng)對(duì)不同的情況做了很多很小的事情,寫一個(gè)更長一點(diǎn)的函數(shù)也是無所謂的.
然而,假如你要寫一個(gè)很復(fù)雜的函數(shù),而且你已經(jīng)估計(jì)到假如一般人讀這個(gè)函數(shù),他可能都不知道這個(gè)函數(shù)在說些什么,這個(gè)時(shí)候,使用具有描述性名字的有幫助的函數(shù).
另外一個(gè)需要考慮的是局部變量的數(shù)量.他們不應(yīng)該超過5-10個(gè),否則你有可能會(huì)出錯(cuò).重新考慮這個(gè)函數(shù),將他們分割成更小的函數(shù).人的大腦通?？梢院苋菀椎挠涀?件不同的事情,超過這個(gè)數(shù)量會(huì)引起混亂.你知道你很聰明,但是你可能仍想去明白2周以前的做的事情.
第5章:注釋
注釋是一件很好的事情,但是過多的注釋也是危險(xiǎn)的,不要試圖區(qū)解釋你的代碼是注釋如何如何的好:你應(yīng)該將代碼寫得更好,而不是花費(fèi)大量的時(shí)間去解釋那些糟糕的代碼.
通常情況下,你的注釋是說明你的代碼做些什么,而不是怎么做的.而且,要試圖避免將注釋插在一個(gè)函數(shù)體里:假如這個(gè)函數(shù)確實(shí)很復(fù)雜,你需要在其中有部分的注釋,你應(yīng)該回到第四章看看.你可以寫些簡短的注釋來注明或警告那些你認(rèn)為特別聰明(或極其丑陋)的部分,但是你必須要避免過多.取而代之的是,將注釋寫在函數(shù)前,告訴別人它做些什么事情,和可能為什么要這樣做.
第六章:你已經(jīng)深陷其中了.
不要著急.你有可能已經(jīng)被告之"GUN emacs"會(huì)自動(dòng)的幫你處理C的源代碼格式,而且你已經(jīng)看到它確實(shí)如此,但是,缺省的情況下,它的作用還是不盡如人意(實(shí)際上,他們比隨便敲出來的東西還要難看- ainfinite number of monkeys typing into GNU emacs would never make a good program)
于是,你可以要么不要使用GUN emacs,要么讓它使用sanervalules.使用后者,你需要將如下的語句輸入到你的.emacs文件中.(defun linux-c-mode() "C mode with adjusted defaults for use with the Linux kernel."(interactive) (c-mode) (c-set-style"KR") (setq c-basic-offset8))
這會(huì)定義一個(gè)M-x Linux-c-mode的命令.當(dāng)你hacking一個(gè)模塊的時(shí)候,如何你將-*- linux-c -*-輸入在最開始的兩行,這個(gè)模式會(huì)自動(dòng)起作用.而且,你也許想加入如下
(setq auto-mode-alist (cons '("/usr/src/linux.*/.*.〖ch〗$" . linux-c-mode) auto-mode-alist))
到你的.emacs文件中,這樣的話,當(dāng)你在/usr/src/linux下編輯文件的時(shí)候,它會(huì)自動(dòng)切換到linux-c-mode .
但是,假如你還不能讓emaces去自動(dòng)處理文件的格式,不要緊張,你還有一樣?xùn)|西: "縮進(jìn)" .
GNU的縮進(jìn)格式也很死板,這就是你為什么需要加上幾行命令選項(xiàng).然而,這還不算太壞,因?yàn)镚NU縮進(jìn)格式的創(chuàng)造者也記得KR的權(quán)威, (GNU沒有罪,他們僅僅是在這件事情上錯(cuò)誤的引導(dǎo)了人們) ,你要做的就只有輸入選項(xiàng)"-kr -i8"(表示"KR,縮進(jìn)8個(gè)字符).
"縮進(jìn)"有很多功能,特別是當(dāng)它建議你重新格式你的代碼的時(shí)候,你應(yīng)該看看幫助.但要記住: "縮進(jìn)"不是風(fēng)格很差的程序的萬靈丹.
JAVA編程風(fēng)格簡析
很久以來都在體會(huì)著JAVA的風(fēng)格，現(xiàn)在做一簡單陳述，希望大家多提寶貴意見。
對(duì)于一種好的編程語言，學(xué)習(xí)它的編程風(fēng)格是很重要的。每種語言都有自己的編寫和注釋約定，當(dāng)然所有語言都建立在最基本的約定之上。編程中最重要的并不是讓代碼按自己希望的方式運(yùn)行，而是程序中那種自明的編程風(fēng)格（這對(duì)于程序員的益處相信眾多程序員都身有體會(huì)）！但這還不夠，程序還應(yīng)該具有可讀、相對(duì)持久和可維護(hù)性?？勺x性非常重要，因?yàn)槟悴幌Ｍ约阂郧暗淖髌吩谥蟮拈喿x中給自己留下障礙，當(dāng)然，更重要的是自己的程序能讓其他程序員讀懂并且修改。
下面我把工作中所理解的java風(fēng)格做一簡單總結(jié)，這是我所理解的好的編程風(fēng)格和應(yīng)用中我們應(yīng)當(dāng)如何使用java編寫自己的代碼的小Guide。這并不完全，希望大家?guī)臀谊懤m(xù)總結(jié)各自的經(jīng)驗(yàn)。
一般性概述
好的編程風(fēng)格固然重要，但是你一定聽說過一些程序員的個(gè)人風(fēng)格。其實(shí)我們完全不必為那些所謂條條框框所累，但是作為原則是我們至少不能打破這些常規(guī)。我們應(yīng)該在保持自己風(fēng)格的同時(shí)盡量的把自己與編程潛原則靠攏。
可讀性很容易達(dá)到，比如，讓自己的代碼縮排排列、名字采用描述性但不要過長（短名應(yīng)僅僅用在非遠(yuǎn)程）、特殊名稱比如pi應(yīng)當(dāng)被定義為final類型。模塊性是編程需要注意的另一重點(diǎn)，把代碼劃分到類里，在類中把功能劃分到方法中，別讓一個(gè)類太大，否則在使用、修改和理解上都會(huì)造成不必要的麻煩，方法也一樣，如果一個(gè)方法長度超過50行，它產(chǎn)生錯(cuò)誤的概率將接近100％，盡量把大方法劃分為小方法，編程中為避免重復(fù)編寫，還應(yīng)盡量調(diào)用JAVA標(biāo)準(zhǔn)類庫。
盡量避免在寫代碼和注釋時(shí)使用不同語言，經(jīng)常見到論壇有朋友詢問諸如在java中調(diào)用c、調(diào)用php、調(diào)用shell之類的問題，其實(shí)在編程中，我們應(yīng)盡量使用一種語言去完成事情。另外就是不必最優(yōu)化自己的代碼，應(yīng)該選擇相對(duì)較優(yōu)的算法就可以了。
類、方法和fields
類應(yīng)體現(xiàn)出某種物質(zhì)的基本概念，比如要編程實(shí)現(xiàn)“汽車”的組成，那么所有的汽車都可以用類Car實(shí)現(xiàn)。這個(gè)類應(yīng)當(dāng)包括域描述、屬性描述和car的狀態(tài)（color, number of doors, age等）和由car可完成的操作（getColor, setColor等）。為了提高類的可重用性，不要在類中有過多的描述，當(dāng)然這也會(huì)增加錯(cuò)誤產(chǎn)生的機(jī)會(huì)。
類名首字母大寫，比如Date, String, Hashtable等 ... ...
類如下定義：(未使用Javadoc做注釋):
public class Car {
/* Instance variables are placed either in the beginning
or at the end of the class */
private int age;
private Color color;
/* The constructor should be placed in the beginning */
public Car(int age, Color color) {
this.age = age;
this.color = color;
}
/* Example method */
public int getAge() {
return age;
}
/* The main method is optional, but looks like this.
If it exists, it is either the first or the last
method in the class */
public static void main(String [] args) {
...
}
}
注意類名和大括號(hào)間的空格！
方法
方法一般定義為public。當(dāng)然，如果方法僅僅在當(dāng)前類用到可以定義為private，而如果希望一個(gè)子類沿用這個(gè)方法則不同，這時(shí)候的方法應(yīng)定義為protected。
java中的方法定義很有趣，它們一般小寫字母開頭，如果有兩個(gè)字組成，第二個(gè)字的首字母則大寫。因此名字的描述性是至關(guān)重要的。這使你不用閱讀整篇代碼來判斷這是一個(gè)什么方法。在給自己的方法取名時(shí)應(yīng)盡量不要太短或者太長，另一個(gè)需要注意的是大多方法使用動(dòng)詞（動(dòng)賓短語）。
例如：
public void eat() {}
public void eatBananas() {}
Selector（選擇器）方法有g(shù)et前綴，后綴是它們將要get的，比如
public int getBananas() {}
Mutator（存取器）方法則有set前綴，后綴則是他們要set的，比如
public void setBananas(int amount) {}
注意mutators大多無返回值。
方法的參數(shù)應(yīng)當(dāng)以如下方式給出：
public void aMethod(type parameter1, type parameter2, ... , type parametern) {}
如果參數(shù)過長，也可以斷開為幾行，應(yīng)對(duì)齊向下排列如：
public void aMethod(type parameter1, type parameter2,... ,
type parametern, type parameter n+1,... ,
type parameterm, type parameter m+1) {}
另外要注意類的左束括號(hào)應(yīng)在方法的右束括號(hào)之后而非下一行:
public int aMethod() {
int i = 0;
if(i == 0)
System.out.println("success！");
}
為了文件可讀性好，還要注意語句最好寫在同一行，當(dāng)然一行寫不下是可以斷行的，比如行字母超過80。
fields
比如變量，如果不希望它永久有效，應(yīng)設(shè)為private。如果一個(gè)變量在類中不發(fā)生任何動(dòng)作（比如數(shù)據(jù)結(jié)構(gòu)中的node）則可以設(shè)置為public，常量一般聲明為public。如果不能確定一個(gè)變量到底該聲明為什么，應(yīng)暫且聲明為private。
field的名字一般使用小寫字母，不要使用下橫線或其他特殊字符。 如果變量包含兩個(gè)字，那么第二個(gè)字的首字母大寫。比如：
int i, j, k;
Date date;
double myField;
常量一般全部大寫，也可以包含下橫線：
public static final int MAX_SIZE_OF_DATABASE
fields的名字通常為名詞。較重要的fields更應(yīng)具備描述性，比如程序中包含一個(gè)游戲的得分，那可以用score來代表。如果變量變化較頻繁，那使用一個(gè)單一字符來代表就ok了：
i, j, k 通常代表整數(shù)
r, t, u, v, w 通常代表實(shí)數(shù)
x, y, z 通常是并列出現(xiàn)或代表浮點(diǎn)數(shù)
s, s1, s2, 通常代表字符串
c, ch 通常代表字符
f, file 通常代表文件
tmp, temp 通常代表臨時(shí)變量
ctr, cnt, cntr 一般代表計(jì)數(shù)器(如果i, j, k這些變量已被使用)
dummy, foo, bar 一般代表啞元變量
args 是main-method的主參數(shù)名
縮排與換行
每行長度不得超過80字符。如果需要可以折行時(shí)，也應(yīng)當(dāng)與上一行有共同的縮排距離。代碼應(yīng)如何交錯(cuò)、如何建立新行、在哪里建立允許、哪里不允許都有一些一般約定，縮排空格一般為2個(gè)或4個(gè)空格。
條件表達(dá)式
如果見到如下語法表達(dá)式：
if (expr)
statement1;
else
statement2;
代碼行向右錯(cuò)排兩個(gè)空格如上所示。
如果在一個(gè)表達(dá)式中有超過一條的聲明，則需要大括號(hào):
if (expr){
statement1;
statement2;
} else{
statement3;
statement4;
}
有時(shí)我們會(huì)希望在表達(dá)式中使用表達(dá)式（比如條件嵌套），這時(shí)應(yīng)注意else表達(dá)式，它的位置很容易出錯(cuò)！如例：
if (expr1) {
statement1;
statement2;
} else if (expr2)
statement3;
else if (expr3) {
statement4;
statement5;
} else {
statement6;
statement7;
}
注意大括號(hào)位置！
Loops
while-loop語法如下：
while (expr) {
statement1;
statement2;
}
for-loop語法如下：
for (expr1; expr2; expr3){
statement1;
statement2;
}
注意大括號(hào)位置！僅一條聲明時(shí)大括號(hào)省略：
while (expr)
statement;
for (expr1; expr2; expr3)
statement;
例如，我們寫一個(gè)procedure寫出1到10這十個(gè)數(shù)字：
for (i = 1; i = 10; i++)
System.out.println(i);
try-catch語法形如：
try {
statements;
} catch (ExceptionClass e) {
statements;
}
如果try-catch語句后跟隨finally子句則形如：
try {
statements;
} catch (ExceptionClass e) {
statements;
} finally {
statements;
}
新行
每一行最好只闡述一件事情。比如，一行包含一個(gè)聲明、一個(gè)條件語句、一個(gè)循環(huán)等。不論多小，最好不要一行辦兩件事及以上。例如不要把一個(gè)if表達(dá)式或循環(huán)語句的主體放置在同一行，這樣的表達(dá)式斷行的易讀性會(huì)更高。通常，互相協(xié)作的代碼應(yīng)放在一起，為保證代碼美觀可讀，我們應(yīng)將代碼的不同代碼段放置在不同的段落。不過要牢記斷行不要太過分！比如:
public int factorial(int n) {
int result = 1;
for(int i = 1; i = n; i++)
result*=i;
return result;
}
給自己的代碼加入注釋
注釋就是類的描繪、方法存在的原因、它完成了什么以及它對(duì)它其中（變量）的作用域。假定閱讀你代碼的人已經(jīng)知道這是什么語言，所以不需要注釋語句功能，盡量使用簡短而有描述力的注釋。
Java有兩種類型的注釋：
//This is a comment that continues until the end of the line.
/* This is a comment. It goes on and on and on and on and on and on and on
and on and on and on and on and on and on and on and on and on and on and
on and on and on and on and on and on and on and on and ends like this: */
/**
* This is a JavaDoc comment. More about JavaDoc in the next section.
*/
如果在注釋中加入注釋則會(huì)出錯(cuò)：
/* You are not allowed to do anything like this /* because the compiler will
complain, if you are lucky */ DON'T DO THIS! And don't write comments in
upper case either... */
注釋應(yīng)放在它要解釋內(nèi)容上下，這樣會(huì)讓代碼更易于理解。
不要注釋一些語言的語句功能：
i++; // Add 1 to i
更不要讓自己的代碼處于這種狀態(tài)：
for(int i = 1; i = n; i++)
/* don't place comments where
they don't belong */
result*=i;
較短的注釋既可被放在被注釋代碼上下，而長注釋則習(xí)慣性的放在代碼之上：
/* Comments can be placed before the
block that is to be commented */
for(int i = 1; i = n; i++)
result*=i;
或者:
for(int i = 1; i = n; i++){
result*=i; // short comments can be placed like this
tmp++; // if necessary, they continue here
}
不要寫沒用的注釋：
i++; // change this later
Excuse me,這句肯定是胡扯！
不要寫自己都看不懂的注釋：
i++; // BMW
BMW? 如果你能連續(xù)十天記住這是什么意思的話，那么你的記憶真是不錯(cuò)了。所以不要寫沒人能看懂的注釋，ok？
最后重申一下：寫簡短而富于描述性的注釋，把它們放在該放的地方，而不要考驗(yàn)?zāi)阕约旱挠洃浟Γ?/p>
JavaDoc - 文檔工具
JavaDoc不僅是另一種給代碼加注釋的仿佛咱，更是一個(gè)文檔工具。類、方法和一些重要地方需要用JavaDoc來注釋。這并不是說你可以放棄常規(guī)的注釋，這兩者在代碼中應(yīng)該是相輔相成、互相彌補(bǔ)的關(guān)系。
類被注釋如：
/**
* Car represents cars ... A description of the class
* should be place here. Note that the description begins
* on the second line and that there is a space between
* the asterix and the text. Next we will add some fields
* indicating who the authors of the class are and
* other useful information. Notice the newline!
*
* @author Jerry Meng
* @version %I%, %G%
*/
public class Car {
注意JavaDoc結(jié)束和類開始間無空行。
方法被注釋如：
/**
* A description of what the method does...
*
* @param n a description of the parameter
* @return a description of the return value
*/
public int factorial(int n) {
某些不是全部，被JavaDoc注釋區(qū)域如：
/**
* Short description of the variable (one line)
*/
type variable;
什么應(yīng)當(dāng)使用JavaDoc做注釋？如何注釋的恰當(dāng)呢？
可以這樣想，JavaDoc中所作的注釋都可以在類的文檔中看到。所有讀這個(gè)類的文檔的讀者都會(huì)明白這個(gè)類所完成的功能、它包括的方法、如何使用這些方法及方法的返回值。一些作用域，比如public的變量或常量將會(huì)一目了然。任何不了解這個(gè)類內(nèi)部結(jié)構(gòu)的人都可以輕松的調(diào)用它。這便是你用JavaDoc可以輕松提供的信息。而使用一般注釋的地方，一般是給那些可能修改你的類代碼的程序員，它們一般描述了類的內(nèi)部信息和結(jié)構(gòu)。
下面我寫一下car的類來描述一個(gè)編程風(fēng)格好的java類應(yīng)該是怎樣的。當(dāng)然這僅僅是一個(gè)小例子(apart from selector and mutator methods)，僅僅是在考慮JAVA編程風(fēng)格上一個(gè)參考而已。
import java.awt.Color;
/**
* This is a class representing cars. A car has certain features, such
* as color, age, number of doors etc and a car can be repainted,
* the tank can be filled etc.
*
* @author Jerry Meng
* @version %I%, %G%
*/
public class Car {
/**
* The maximum size of the tank in litres.
*/
private static final double TANK_SIZE = 100.0;
/**
* The color of the car.
*/
private Color color;
/**
* The age of the car.
*/
private int age;
/**
* The number of doors of the car.
*/
private int doors;
/**
* The amount of gasoline in the tank.
*/
private double gasoline;
/**
* Class constructor, which constructs a brand new, black car with
* five doors and a full tank.
*/
public Car() {
this(Color.black, 0, 5, TANK_SIZE);
}
/**
* Class constructor specifying the color, age, number of doors
* and litres of gasoline
*
* @param color The color of the car
* @param age The age of the car
* @param doors The number of doors
* @param km Kilometres driven
* @param gasoline The litres of gasoline
*/
public Car(Color color, int age, int doors, double gasoline) {
this.color = color;
this.age = age;
this.doors = doors;
this.gasoline = gasoline;
}
/**
* Returns the color of the car
*/
public Color getColor() {
return color;
}
/**
* Repaints the car (i.e. changes its color)
*/
public void setColor(Color color) {
this.color = color;
}
/**
* Returns the age of the car
*/
public int getAge() {
return age;
}
/**
* Returns the number of doors of the car
*/
public int getDoors() {
return doors;
}
/**
* Returns the amount of gasoline in the tank
*/
public double getGasoline() {
return gasoline;
}
/**
* Fills the tank. The amount of gasoline cannot exceed
* the size of the tank. In that case, the tank will be
* filled to the maximum and the rest will run out in
* the sand.
*
* @param gas The amount of gasoline to put in the tank
*/
public void setGasoline(double gas) {
if(gasoline + gas = TANK_SIZE)
gasoline+=gas;
else
gasoline = TANK_SIZE;
}
}
對(duì)于程序員來說，養(yǎng)成良好的代碼寫作能力是非常重要的。
今天，我們就一起來了解一下，規(guī)范化的代碼編寫都有哪些要求。
希望通過對(duì)本文的閱讀，能夠提高大家對(duì)于代碼規(guī)范的認(rèn)識(shí)。
1.保證代碼壓縮后不出錯(cuò)對(duì)于大型的JSP項(xiàng)目，一般會(huì)在產(chǎn)品發(fā)布時(shí)對(duì)項(xiàng)目包含的所有JSP文件進(jìn)行壓縮處理，比如可以利用GoogleClosureCompilerService對(duì)代碼進(jìn)行壓縮，新版jQuery已改用這一工具對(duì)代碼進(jìn)行壓縮，這一般會(huì)去掉開發(fā)時(shí)寫的注釋，除去所有空格和換行，甚至可以把原來較長的變量名替換成短且無意義的變量名，這樣做的目的是加快文件的下載速度，同時(shí)也減小網(wǎng)站訪問帶來的額外數(shù)據(jù)流量，另外在代碼保護(hù)上也起到了一點(diǎn)點(diǎn)作用，至少壓縮后的代碼即使被還原還是沒那么容易一下讀懂的。
要想代碼能正確通過壓縮，一般要求語句都要以分號(hào)正常結(jié)束，大括號(hào)也要嚴(yán)格結(jié)束等，具體還要看壓縮工具的要求。
所以如果一開始沒有按標(biāo)準(zhǔn)來做，等壓縮出錯(cuò)后再回去找錯(cuò)誤那是浪費(fèi)時(shí)間。
2.保證代碼能通過特定IDE的自動(dòng)格式化功能一般較為完善的開發(fā)工具(比如AptanaStudio)都有代碼"自動(dòng)格式"化功能，這一功能幫助實(shí)現(xiàn)統(tǒng)一換行、縮進(jìn)、空格等代碼編排，你可以設(shè)置自己喜歡的格式標(biāo)準(zhǔn)，比如左大括號(hào){是否另起一行。
達(dá)到這個(gè)要求的目的在于方便你的開發(fā)團(tuán)隊(duì)成員拿你代碼的一個(gè)副本用IDE自動(dòng)格式化成他喜歡或熟悉的風(fēng)格進(jìn)行閱讀。
你同事需要閱讀你的代碼，可能是因?yàn)槟銓懙氖峭ㄓ梅椒?，他在其它模塊開發(fā)過程中也要使用到，閱讀你的代碼能深入了解方法調(diào)用和實(shí)現(xiàn)的細(xì)節(jié)，這是簡單API文檔不能達(dá)到的效果。
3.使用標(biāo)準(zhǔn)的文檔注釋這一要求算是基本的，這有利于在方法調(diào)用處看到方法的具體傳參提示，也可以利用配套文檔工具生成html或其它格式的開發(fā)文檔供其他團(tuán)隊(duì)成員閱讀，你可以嘗試使用jsdoc-toolkit。
如果你自動(dòng)生成的API是出自一個(gè)開放平臺(tái)，就像facebook點(diǎn)抗 應(yīng)用，那么你的文檔是給天下所有開發(fā)者看的。
另外編寫完整注釋，也更方便團(tuán)隊(duì)成員閱讀你的代碼，通過你的參數(shù)描述，團(tuán)隊(duì)成員可以很容易知道你編寫的方法傳參與實(shí)現(xiàn)細(xì)節(jié)。
當(dāng)然也方便日后代碼維護(hù)，這樣即使再大的項(xiàng)目，過了很長時(shí)間后，回去改點(diǎn)東西也就不至于自己都忘記了當(dāng)時(shí)自己寫的代碼是怎么一回事了。
4.使用規(guī)范有意義的變量名使用規(guī)范有意義的變量名可以提高代碼的可讀性，作為大項(xiàng)目開發(fā)成員，自己寫的代碼不僅僅要讓別人容易看懂。
電腦培訓(xùn)認(rèn)為開發(fā)大項(xiàng)目，其實(shí)每個(gè)人寫的代碼量可能都比較大，規(guī)范命名，日后自己看回自己的代碼也顯的清晰易懂，比如日后系統(tǒng)升級(jí)或新增功能，修改起代碼來也輕松多了。
如果到頭發(fā)現(xiàn)自己當(dāng)初寫的代碼現(xiàn)在看不太懂了，那還真是天大的笑話了。
世界上并沒有成為高手的捷徑，但一些基本原則是可以遵循的。
1、扎實(shí)的基礎(chǔ)
數(shù)據(jù)結(jié)構(gòu)、離散數(shù)學(xué)、編譯原理，這些是所有計(jì)算機(jī)科學(xué)的基礎(chǔ)，如果不掌握它們，很難寫出高水平的程序。程序人人都會(huì)寫，但當(dāng)你發(fā)現(xiàn)寫到一定程度很難再提高的時(shí)候，就應(yīng)該想想是不是要回過頭來學(xué)學(xué)這些最基本的理論。不要一開始就去學(xué)OOP，即使你再精通OOP，遇到一些基本算法的時(shí)候可能也會(huì)束手無策。因此多讀一些計(jì)算機(jī)基礎(chǔ)理論方面的書籍是非常有必要的。
2、豐富的想像力
不要拘泥于固定的思維方式，遇到問題的時(shí)候要多想幾種解決問題的方案，試試別人從沒想過的方法。豐富的想像力是建立在豐富的知識(shí)的基礎(chǔ)上，除計(jì)算機(jī)以外，多涉獵其他的學(xué)科，比如天文、物理、數(shù)學(xué)等等。開闊的思維對(duì)程序員來說很重要。
3、最簡單的是最好的
這也許是所有科學(xué)都遵循的一條準(zhǔn)則，復(fù)雜的質(zhì)能轉(zhuǎn)換原理在愛因斯坦眼里不過是一個(gè)簡單得不能再簡單的公式：E=mc2。簡單的方法更容易被人理解，更容易實(shí)現(xiàn)，也更容易維護(hù)。遇到問題時(shí)要優(yōu)先考慮最簡單的方案，只有簡單方案不能滿足要求時(shí)再考慮復(fù)雜的方案。
4、不鉆牛角尖
當(dāng)你遇到障礙的時(shí)候，不妨?xí)簳r(shí)遠(yuǎn)離電腦，看看窗外的風(fēng)景，聽聽輕音樂，和朋友聊聊天。當(dāng)我遇到難題的時(shí)候會(huì)去玩游戲，當(dāng)負(fù)責(zé)游戲的那部分大腦細(xì)胞極度亢奮的時(shí)候，負(fù)責(zé)編程的那部分大腦細(xì)胞就得到了充分的休息。當(dāng)重新開始工作的時(shí)候，我會(huì)發(fā)現(xiàn)那些難題現(xiàn)在竟然可以迎刃而解。
5、對(duì)答案的渴求
人類自然科學(xué)的發(fā)展史就是一個(gè)渴求得到答案的過程，即使只能知道答案的一小部分也值得我們?nèi)ジ冻觥Ｖ灰銏?jiān)定信念，一定要找到問題的答案，你才會(huì)付出精力去探索，即使最后沒有得到答案，在過程中你也會(huì)學(xué)到很多東西。
6、多與別人交流
三人行必有我?guī)煟苍S在一次和別人不經(jīng)意的談話中，就可以迸出靈感的火花。多上上網(wǎng)，看看別人對(duì)同一問題的看法，會(huì)給你很大的啟發(fā)。
7、良好的編程風(fēng)格
注意養(yǎng)成良好的習(xí)慣，代碼的縮進(jìn)編排，變量的命名規(guī)則要始終保持一致。大家都知道如何排除代碼中錯(cuò)誤，卻往往忽視了對(duì)注釋的排錯(cuò)。注釋是程序的一個(gè)重要組成部分，它可以使你的代碼更容易理解，而如果代碼已經(jīng)清楚地表達(dá)了你的思想，就不必再加注釋了，如果注釋和代碼不一致，那就更加糟糕。
8、韌性和毅力
這也許是“高手”和一般程序員最大的區(qū)別。高手們并不是天才，他們是在無數(shù)個(gè)日日夜夜中磨煉出來的。成***能給我們帶來無比的喜悅，但過程卻是無比的枯燥乏味。沙河電腦培訓(xùn)建議你不妨做個(gè)測試，找個(gè)10000以內(nèi)的素?cái)?shù)表，把它們?nèi)汲聛恚缓笤贆z查三遍，如果能夠不間斷地完成這一工作，你就可以滿足這一條。
怎么判斷代碼是否是優(yōu)質(zhì)量的代碼呢？下面河南電腦培訓(xùn)來簡單對(duì)代碼質(zhì)量的問題進(jìn)行一個(gè)介紹。
代碼質(zhì)量所涉及的5個(gè)方面，編碼標(biāo)準(zhǔn)、代碼重復(fù)、代碼覆蓋率、依賴項(xiàng)分析、復(fù)雜度分析。
我們分別來看一下這5方面：編碼標(biāo)準(zhǔn)：一般來說，公司都會(huì)有一份編碼規(guī)范，類命名、包命名、代碼風(fēng)格之類的都會(huì)有所要求。
代碼重復(fù)：顧名思義就是重復(fù)的代碼，如果代碼中有大量的重復(fù)代碼，就要考慮是否將重復(fù)的代碼提取出來，封裝成一個(gè)公共的方法或者組件。
代碼覆蓋率：測試代碼能運(yùn)行到的代碼比率，代碼經(jīng)過了單元測試了嗎？是不是每個(gè)方法都進(jìn)行了測試，代碼覆蓋率是多少？這關(guān)系到代碼的功能性和穩(wěn)定性。
依賴項(xiàng)分析：代碼依賴關(guān)系怎么樣？耦合關(guān)系怎么樣？是否有循環(huán)依賴？是否符合高內(nèi)聚低耦合的原則？復(fù)雜度分析：如果代碼中嵌套了很多層的ifelse，就會(huì)讓人很難閱讀。
要相信越優(yōu)秀的代碼，越容易讀懂。
重慶分公司
重慶分公司
