建站
咨詢
售后
建站咨詢
新聞中心
避免這些常見(jiàn)的編碼習(xí)慣，會(huì)讓我們的工作更輕松、軟件更安全且更易于擴(kuò)展。
作為一家“創(chuàng)意+整合+營(yíng)銷”的成都網(wǎng)站建設(shè)機(jī)構(gòu)，我們?cè)跇I(yè)內(nèi)良好的客戶口碑。創(chuàng)新互聯(lián)提供從前期的網(wǎng)站品牌分析策劃、網(wǎng)站設(shè)計(jì)、網(wǎng)站設(shè)計(jì)、網(wǎng)站制作、創(chuàng)意表現(xiàn)、網(wǎng)頁(yè)制作、系統(tǒng)開(kāi)發(fā)以及后續(xù)網(wǎng)站營(yíng)銷運(yùn)營(yíng)等一系列服務(wù)，幫助企業(yè)打造創(chuàng)新的互聯(lián)網(wǎng)品牌經(jīng)營(yíng)模式與有效的網(wǎng)絡(luò)營(yíng)銷方法,創(chuàng)造更大的價(jià)值。
帕雷托法則明確指出，20％的因?qū)е?0％的果。又稱為80-20法則，它適用于幾乎每一個(gè)需要人作為勞動(dòng)主體的相關(guān)領(lǐng)域。
在軟件開(kāi)發(fā)領(lǐng)域，這個(gè)法則可以概括為，大多數(shù)的問(wèn)題都是由少數(shù)不良編碼習(xí)慣造成的。改變這些習(xí)慣，你會(huì)更有效率。
下面講講最要不得的10條編碼習(xí)慣：
1.拼寫錯(cuò)誤
讓我特別訝異的是，為什么大家明知這個(gè)習(xí)慣百害而無(wú)一利，竟然還是任其在代碼中肆虐橫行，以致于經(jīng)常出現(xiàn)拼寫錯(cuò)誤的變量名和函數(shù)名。更加悲劇的是，錯(cuò)誤的拼寫常常隱蔽得很好，很難發(fā)現(xiàn)。
至于解決方法，可以在一個(gè)良好的集成開(kāi)發(fā)環(huán)境（IDE）上寫代碼，或者干脆用程序員專用的文本編輯器，這些都可以顯著減少拼寫錯(cuò)誤。還可以選擇特定的變量名和函數(shù)名，一方面容易拼寫，另一方面即便寫錯(cuò)了也能輕易發(fā)現(xiàn)。盡量避免使用很容易拼錯(cuò)的單詞，例如“receive”，很容易拼寫成“recieve”。
2.未按規(guī)定格式寫代碼
縮進(jìn)和格式化，能讓我們的代碼一目了然、易于理解，有什么錯(cuò)誤也能一覽無(wú)余。而且也方便別人理解和維護(hù)。
如果你使用的是不會(huì)自動(dòng)格式化代碼的IDE，那么可以考慮使用代碼美化軟件，如Uncrustify，這個(gè)軟件允許用戶自定義格式要求，然后它會(huì)一絲不茍地執(zhí)行。
3.未按規(guī)定模塊化編寫代碼
一個(gè)函數(shù)對(duì)應(yīng)一個(gè)指令的習(xí)慣相當(dāng)好，因?yàn)楹?jiǎn)短所以易于理解和維護(hù)。長(zhǎng)函數(shù)實(shí)現(xiàn)的可能路徑太多，所以測(cè)試起來(lái)就特別麻煩。
***個(gè)規(guī)范原則：一個(gè)函數(shù)最多只能占一顯示屏的空間。第二個(gè)：如果有10個(gè)以上的if語(yǔ)句或者循環(huán)語(yǔ)句，那么你就可以考慮重寫了。
4.過(guò)度依賴IDE
毫無(wú)疑問(wèn)，IDE和其他一些工具能讓你的代碼寫得又快又好。在一定范圍內(nèi)它們能提供變量和其他很多東西，給出你想要輸入內(nèi)容的多種選擇提示。但是這種類型的工具也存在著風(fēng)險(xiǎn)——如果你不能保證自己有火眼金睛，那么很容易誤選相似的變量名。從本質(zhì)上說(shuō)，這類工具替代了人的一部分思維，但實(shí)際上這是你自己的責(zé)任。
工具的確是我們的好幫手，例如可以消除拼寫錯(cuò)誤，以及提高工作效率等，但是如果你自己不仔細(xì)的話，同樣會(huì)有寫錯(cuò)代碼的問(wèn)題出現(xiàn)。
5.使用硬編碼的密碼
很多人傾向于硬編碼一個(gè)秘密帳戶和密碼，這樣之后就可以自由進(jìn)入系統(tǒng)。但是這是不對(duì)的——沒(méi)錯(cuò)，這于你而言的確是大大的方便了，但同時(shí)這也大大方便了別人去訪問(wèn)你的源代碼。
究其原因在于，硬編碼的代碼比你想象的還要脆弱，這就使得它成為了一個(gè)巨大的安全隱患，而且還是一個(gè)很不好修復(fù)的安全隱患。
6.沒(méi)有采取良好的加密手段保護(hù)數(shù)據(jù)
敏感數(shù)據(jù)在互聯(lián)網(wǎng)上傳輸時(shí)是需要加密的，因?yàn)樵谶@個(gè)過(guò)程中它很有可能被攔截。不要抱怨麻煩，這是最基本的安全要求。
這也意味著以明文形式發(fā)送數(shù)據(jù)是不被認(rèn)可的，同時(shí)也排除了我們使用自己的加密方式和混淆目標(biāo)的措施。寫安全加密系統(tǒng)是很難的——看看wep的情況就知道了——所以我們不妨使用經(jīng)過(guò)驗(yàn)證的標(biāo)準(zhǔn)加密庫(kù)。
7.過(guò)早優(yōu)化代碼
Donald Knuth，一位傳奇的程序員，曾經(jīng)說(shuō)過(guò)，“程序員將太多的時(shí)間花在了思考和擔(dān)憂程序非緊要部分的進(jìn)度問(wèn)題上，因?yàn)檫@些舉措反而對(duì)效率產(chǎn)生了強(qiáng)烈的負(fù)面影響，如果還同時(shí)要考慮到調(diào)試和維護(hù)的話，那么影響更甚?！?/p>
善于寫代碼的程序員的確能讓代碼跑得更快更順暢，但是后期調(diào)試和維護(hù)相反則會(huì)變難。提供一個(gè)好策略：清清楚楚地寫好代碼之后，再去找真正需要優(yōu)化的地方以提高性能。
8.沒(méi)有超前的思想
項(xiàng)目的目標(biāo)是什么？預(yù)計(jì)規(guī)模有多大？會(huì)有多少用戶，運(yùn)行速度得有多快？這些問(wèn)題乍一看上去好像和我們程序員沒(méi)啥關(guān)系——但是，如果不好好思考這些問(wèn)題，我們?cè)趺茨苷_選擇開(kāi)發(fā)應(yīng)用程序的框架，以滿足這些要求？
Twitter在這方面就有因?yàn)榈凸牢磥?lái)需求而失敗的例子，導(dǎo)致其最終不得不放棄Ruby on Rails，并且重寫了很多使用Scala和其他技術(shù)的代碼，這是因?yàn)樵扔糜诩軜?gòu)的Ruby代碼，根本跟不上Twitter的快速增長(zhǎng)的用戶群。
9.以為增加人手就能加快進(jìn)度
幾乎所有的軟件項(xiàng)目都會(huì)落后于計(jì)劃。有人會(huì)說(shuō)，人多力量大，落后了那我添加人手不就能跟上進(jìn)度了嗎？聽(tīng)上去挺美的，但事實(shí)卻是，幾乎所有的項(xiàng)目在增加“新鮮血液”之后都發(fā)生了“凝血反應(yīng)”——整體效率不升反降。
10.知錯(cuò)不改，錯(cuò)上加錯(cuò)
接上面第9點(diǎn)，有人會(huì)說(shuō)，既然不能添加人手，那我死命趕進(jìn)度總可以了吧。我奉勸一句，不要抱這種幻想。如果你遠(yuǎn)遠(yuǎn)落后于計(jì)劃時(shí)間，那說(shuō)明本身你對(duì)項(xiàng)目的預(yù)估時(shí)間就是錯(cuò)的。不要盲目地堅(jiān)持將錯(cuò)就錯(cuò)，還是早點(diǎn)對(duì)項(xiàng)目時(shí)間做新的估計(jì)吧。
網(wǎng)頁(yè)名稱：10個(gè)對(duì)開(kāi)發(fā)項(xiàng)目有害的編程習(xí)慣
當(dāng)前路徑：http://www.5511xx.com/article/dpdjsso.html
