主要是基於最近Quora上的跟帖討論,根據你們的反響和投票結果,有一項投票遙遙領先,穩居第一。對於軟件開發人員來講,最大的難題是:如何命名(例如:給變量,類,函數和過程命名等等)。html
對於這個結果,我多少有點意外,由於做爲一個多年的開發人員,我不會投給這一項(我想我會投給「修改或維護別人的代碼」)。可是真正讓我驚訝的是,看起來好像不怎麼重要的命名竟然排列第一,跟期待的結果實在差太遠了。下面是投票結果的分佈圖。git
該結果是來自Quora問答網站和更早的Ubuntu論壇跟帖的4500個開發者的投票。如何命名一項的選票幾乎是其它八項的投票結果的總和,哇!程序員
的確,這些基於自我篩選的羣體的投票結果是徹底不科學的。可是我認爲這個結果仍是有必定意義的,換句話說,如何命名的確是個很棘手的問題,許多非編程人員可能會意識不到。
Don’t go into programming if you don’t have a good thesaurus 比較舊以前的調查,能夠對比看看github
「一般,若是你沒法想出一個合適的名字,意味着你的設計可能有問題。你的一個方法裏是否是實現了太多的功能?或者你的類的封裝,凝聚性不夠強?」 編程
「個人經驗是若是沒法給你的類想出一個合適的名字,大多數狀況都是你的類有問題:你可能不須要這個類,它有點多餘了」 數組
「命名難也不見得是壞事兒,它能夠迫使你去認真思考你的類到底想要實現什麼功能。」bash
List定義的變量應該 List 做爲後綴結尾。
Map定義的變量應該 Map 做爲後綴結尾。
數組定義的變量應該 s 做爲後綴結尾。
類成員變量是用 m打頭。微信
遵循當前語言的變量命名規則,不要不統一(inconsistently)地使用大/小寫字母。例如:userName, UserName, USER_NAME, m_userName, username, …。
以Java爲例:ide
在同一個類不一樣的場景(contexts)中不要複用變量名。例如在方法、初始化方法和類中。這樣作能夠提升可讀性和可維護性。函數
不要對不一樣使用目的的變量使用同一個變量名,而是賦予它們不一樣的名字。這一樣對保持可讀性和可維護性很重要。
變量名不要使用非ASCII字符(non-ASCII chars)。這樣作可能會在跨平臺使用時產生問題。
不要使用過長的變量名(例如50個字符)。過長的變量名會致使代碼醜陋(ugly)和難以閱讀(hard-to-read),還可能由於字符限制在某些編譯器上存在兼容性問題。
僅使用一種天然語言(natural language)來命名變量。例如,同時使用德語和英語來命名變量會致使(理解)不一致和下降可讀性。
使用有意義的方法名。方法名必須準確表達該方法的行爲,在多數狀況下以動詞(verb)開頭。(例如:createPasswordHash)
遵循公司的方法命名規則,在項目中堅持使用同一種方法命名方式。例如 getTxtUserName(), getLblUserName(), isStudentApproved(),不然會對可讀性形成影響,並且會令查找/替換工具不可用。
遵循當前語言的變量命名規則,不要不統一地使用大/小寫字母。例如:getUserName, GetUserName, getusername, …。
以Java爲例:
使用有意義的方法參數命名,這樣作能夠在沒有文檔的狀況下儘可能作到「自解釋(documentate itself)」
更多詳情能夠了解:命名約定:zh-google-styleguide.readthedocs.io/en/latest/g…
老手應該都知道codeif了吧,新手能夠收藏一下。
支持直接搜索中文,當你查中文的時候,Codelf 會直接查好單詞和單詞的近義詞給你,而後再搜索Github, Bitbucket, Google Code, Codeplex, Sourceforge, Fedora Project上的開源項目的源碼匹配出與這些詞彙相關的變量名和函數名。Codelf 能夠選擇開發語言進行搜索,結果會把同個源碼文件裏匹配的變量名排在一塊兒,如你選擇「PHP」而後搜索「支付時間」
Codelf: unbug.github.io/codelf/
微信掃描二維碼,歡迎關注個人我的公衆號:daimajiqiao
分享技術文章,代碼技巧複製代碼