作為程式設計開發來說，每個人都有自己的編碼習慣。拋開設計和專案結構來說，我覺得特別爛的程式碼有以下這些特點：

不寫註釋。不光是方法和常量等沒註釋，連檔案頭都沒註釋！這樣的程式碼估計很多人都很頭疼吧。

命令混亂。檔名、方法名、常量、變數您起碼起個有點含義的名字啊，你以為你是在做加密混淆嗎。遇到程式碼沒寫註釋還命名不規範的程式碼，估計打死對方的心都有了吧。

臃腫的程式碼。寫文章人家還講究個分段和排版呢，寫個方法幾百行程式碼的人是要鬧哪樣，什麼東西都往裡面扔，你當你是收破爛呢？

工作也十多年了，爛程式碼見過不少，也寫過不少（慚愧慚愧），那就盤點一下這些年我見過的爛程式碼。

變數命名沒有含義的：String a;int b;

不寫註釋的

改了程式碼不改註釋的，比上一點更過分

一個類/方法能寫幾千行的，跟蹤程式碼那叫一個累

使用版本控制工具，提交的時候亂寫提交日誌的

功能實現了不見得就是好程式碼，常見問題：

最常見的問題：寫sql的時候不考慮效率，測試環境一跑沒有問題，上了生產，資料量一大就跑不出來結果了

為了保險起見，做兩次update的（見過麼？看到那段程式碼的時候我都服了）

還有莫名其妙sleep(3000)，難道是為了下一次改成sleep(2000)，就說自己最佳化程式了？

功能實現了，效率也沒問題，也不見得是好程式碼：

該抽象的不抽象出來，明明可以只改一行程式碼，但是需要改動很多地方

程式碼分層不明確，或者明明是controller層非要寫點兒業務邏輯

過度耦合

見沒見過一種很神的程式碼：很重要，執行的很穩定，但是你看不懂，稍微改動一小處，整個程式碼就不能用了。

還有一種“爛程式碼”相信大多數人都寫過，就是剛學到一個演算法/設計模式/新技術什麼的，非得想方設法寫到程式碼裡面，並沒有考慮合適不合適。

謝邀！ 這個問題要吐槽的內容太多，說一點吧，關於命名的。 程式碼首先是給人看的，其次才是給機器看的。 爛程式碼特徵：可讀性差、邏輯混亂、效能低下。 1.奇葩專案(模組)名 專案(模組)名稱使用漢語拼音、英漢雙拼、超長的字母集。 專案(模組)名稱應該使用言簡意賅的英文單詞或短語，可代表專案(模組)意圖即可。 2.奇葩包名 包名稱使用毫無意義的單個字母或另類的單詞。 正常的包結構名稱應該以官網或產品域名的倒序為基礎包，然後細分service、dao等。基本上常用的包名也就那幾個，沒必要為了體現出自己的不同而新創包名，如果真的有必要建新包名，應該使用名詞性質的單詞。 3.奇葩介面名 介面名命名規則不統一，千奇百怪，使用非名詞性單詞。 一般情況下，根據團隊編碼習慣，介面名稱規則需要統一。最好不要使用以字母I為字首或以interface為字尾，你不覺得這樣很多此一舉嗎？名稱命名需要使用名詞性的單詞或短語。 4.奇葩類名和物件名 類名或物件名使用動詞，使用非名詞或非名詞短語。 類名和物件名是一個標識，所以不要使用動詞，應該使用名詞或名詞性的短語，而且最好不要使用以Data和Info為字尾，這樣的字尾給人感覺很累贅。 5.奇葩屬性名 類的屬性名為了和表的欄位名稱一致，名稱中的單詞使用下劃線連線；屬性名使用非駝峰式命名；使用無意義的字母或單詞縮寫。 類的屬性名應該使用有意義的名詞或名詞性的短語，名稱的首字母要小寫，名稱中包含多個單詞的需要使用駝峰式的命名規則，一定不要使用無明確意義的字母或單詞縮寫。如果為了表達多個數據的集合，避免使用List結尾，可以使用對應單詞的複數形式，如students，而不是studentList。推薦使用一些可讀的出來或可搜尋到的單詞或短語，易於理解。對於一些boolean型別的屬性名，推薦在名稱前加上is字首，這樣容易理解其值的含義。 6.奇葩方法名 方法名以非動詞開頭；方法名不能表達出方法體的意圖；方法名使用以get為字首；方法名使用單詞或短語的字母縮寫；方法名不遵循駝峰式命名規則。 方法名應該以動詞開頭，使用動詞短語；動詞短語應該可以表達出本方法體的意圖，做到可以根據方法名看出方法做了什麼；除了屬性的getter方法，避免使用以get作為方法名的字首，因為get無法說清方法的意圖，有偷懶的嫌疑，而且這樣命名說明寫程式碼的人真的很low；最不能忍的是方法名使用單詞的字母縮寫，誰能知道這是幹啥的，就是程式碼作者自己，一段時間後也不能保證記得這是作什麼的；方法名應該遵循首字母小寫的駝峰式命名規則；對於返回值型別為布林值型別的方法，推薦方法名字首使用is、has、can。 7.奇葩變數名 變數名使用單個字母。 除了用於迴圈的臨時變數名，其它變數都不要使用單個字母命名，且變數名要能表達出其真正意圖，遵循駝峰式命名規則。 8.奇葩常量名 常量名使用非大寫的單詞或短語；常量名中的多個單詞間不使用下劃線連線。 常量名應該全部使用大寫的字母，而且單詞與單詞間使用下劃線連線。對於方法裡用於比較或計算的“0”、“1”之類的常量，最好定義成常量，使用常量名標識這些資料的意思，否則誰能理解“0”代表什麼，“1”代表什麼。 命名可以透過總結的方式，歸納出屬於自己的一套命名規則。 我喜歡研究技術原理，有一個圈子，關注我私信，邀你進群一起交流技術。

我是上班自學軟體後剛轉入行的程式設計師，在一家幾個人小公司，主要做機械裝置的軟體，現在接手一個10萬行的上位機程式，vb.net寫的，這程式碼看的我醉了，定義了一個模組，裡面放了1000個全域性變數，然後幾十個form各種呼叫全域性變數，噁心的是一半的變數沒寫註釋，更噁心的是整個程式每幾百行才有一行註釋，最噁心的是還定義了幾百個定時器，n個定時器同時修改全域性變數，有的定時器裡兩千行程式碼，有幾百個if else，已經連續盯著這個程式碼看了一個禮拜，而且整個公司就我一個搞軟體的，都沒有人問，怎麼破

爛程式碼不是很正常嗎，我也寫過不少爛程式碼...寫windows核心驅動也是爛程式碼，改一點一不小心就藍色畫面...

記得以前剛接手一個專案維護的時候，其中一個核心的類庫原始碼被刪了(總是有原因的，反正找不回來了)，當時心想反正是C#的而且其他程式碼都有，應該問題不大，但當真正接手了，老闆需要我改功能了，忙活一下午，看到開啟的那一堆反混淆後又反編譯出來的程式碼，就知道風中凌亂是什麼樣的感覺了

簡單點說就是單純為了實現功能而實現功能

1.把所有東西寫到一個類裡面

2.不使用任何設計模式

3.命名隨便猜不懂意思

4.基礎不牢固原本很簡單的邏輯卻要寫的很複雜

5.大量重複程式碼

6.沒有註釋

目前為止，我見過最爛的程式碼是這樣的。

主要需要實現的功能一個沒有實現，但是程式碼200多號行。點編輯執行的時候又佔記憶體，什麼都沒有反應。

好的程式碼，用最省記憶體的函式，直接實現實際想要的功能，連空格都不用直接用tab。高效快捷省地兒。

我沒見過什麼太爛的，倒是我的老師和我說過一個他以前工作時看到的程式碼。

登入系統中，先 select * from t_user，然後for迴圈遍歷每一個元素，判斷user.getName === name

本人做了十多年軟體開發，爛程式碼和神程式碼都見過不少，這裡分享一個印象比較深刻的爛程式碼的經歷。

有一次部門重組，接手了一個由印度團隊開發的專案。拿到手後，我和我的小夥伴們都驚呆了，心想他們一定是按程式碼行數發工資的，寫得繁瑣無比，資料庫裡的儲存過程各個都上千行，質量非常低下。

但令人驚訝的是，這一堆在我們眼裡看來隨便拎起一個片段都到處是bug程式碼，雖然效能極差，但執行結果居然總是對的…這就讓人百撕不得其姐(解)了 。然後我們嘗試仔細去分析，發現往往一個地方犯了錯，後面某個地方會有一段程式碼把中間結果強制修正一下，藍翔挖掘機般的神技能。

一段時間後，一個數據庫儲存過程突然執行時開始報錯，我不得不一臉厭惡的深入去研究。毫無例外，這個上千行的儲存過程，程式碼質量也是非常差，讀取多個數據表，用迴圈的方式一行一行計算，根據結果進行增刪改查。一般而言，在儲存過程中，應該儘量透過表關聯和集合操作來批次處理資料，避免CPU密集性的計算。雖然寫得爛、效能差，但仔細研究邏輯，貌似也沒錯。一番除錯後，發現居然兩個迴圈塊共用了一個迴圈變數，反覆加一之後，迴圈變數溢位了?!!! 這種事情通常只發生在傳說裡，居然在有生之年被我碰到了!

看懂了資料處理邏輯後，我把儲存過程的程式碼直接全刪掉，一條SQL語句搞定(是的，他們的上千行程式碼，價值就等同於一條語句!!!…)，執行速度也由半個小時縮短到了幾秒鐘…幾秒鐘…幾秒鐘…， 而這家公司居然是…微軟!微軟!微軟!(雖然程式碼是外包員工寫的)。