當產品開發從一個人變成一群人時，就可以從命名的方法看得出來這段程式碼是誰寫的:Henry喜歡用縮寫，Ken的英文一定有錯字，Sammy因為個性的關係每個名稱都非常籠統，Mike只用kebab-case而且會寫註解。在經過很長時間的更迭之後，這些「個性化」的名稱都變成了技術債：沒有人知道strBRID是什麼意思，太過籠統的package讓他變得愈來愈巨大，在一個class裡有camel case還有snake case甚至還有kebab case活像個馬戲團！這種種的跡象都顯示這個團隊並沒有任何的紀律可言。

是的，一個成熟的團隊必需要有紀律，但不是按步就班當keyin monkey那種，而是每個人都有一個標準可以依循，讓所有人的程式都像是一個人寫出來的一樣。

因此，Naming convention這種文件就產生了，這份文件會告訴開發團隊這些事情:

• 變數的命名
• 格式
• 可以允許或不被允許的縮寫

如果團隊裡有這份文件，在開發時應該嚴格的遵循指示執行。

那如果沒有這份文件怎麼辦？

一致性

命名規則應該有一致的規格:如果參數是camel case就應該全部都是camel case。
如果自己是團隊第一個醒悟的那個人，請說服團隊，然後再做統一的改正。
開發是團隊活動，除非有能力可以力排眾議，否則應該要先取得所有人的共識再做改變。每個程式裡有不同的命名規則會造成很大的困擾，無論是自己或者團隊皆然。

明確

如果什麼都沒有，又不想說服團隊，那有幾件事可以從自己做起:
1.命名應該要明確
我知道現在大部份的人應該都還是用i當成迴圈的指標，但這種學生時期留下來的習慣應該要被修正了：有很多更好的名稱可以用在指標上。
命名時也不要靠直覺命名，「覺得」它應該叫什麼名字：在專案裡的每個物件都應該要有一個很明確使用的名稱，或者讓命名跟Solution、Domain或者Project相關：即使他是從一個User new出來的，也應該告訴自己（對，是自己）這個User是誰，把特徵標註在名稱上。
2.減少使用縮寫
在很古老的年代，編輯器還不會聰明到把名稱自動補上時，程式設計師會用各種縮寫在名稱上，當時的要求是高效率而且減少keyin的次數，因此縮寫很常發生。
但現在是廿一世紀了，當編輯器可以在100ms裡找到兩百萬個檔案裡的一個keyword時，請好好的，完整的把命名這件事情做好，縮寫這件事在現在並不是個高效的表現。
3.錯字,big no no
錯字真的很母湯，如果編輯器己經提示有錯字了，改一下好嗎？

查字典

我知道這個提議可能很蠢，但在命名前請查字典，英文有很多字的字義雖然很像，但用起來完全不是那回事，例如:
Avoid
Forbid
Prohibit
Prevent
這些字意連外國人都可能搞錯，使用上可能會造成很大的誤會（特別是開發對外的服務）。現在網路那個方便，花點時間讓名字取得好一點，這無論對誰都是加分項

Code Review

找資深的同事幫你review，詢求專業的建議，必要時多列幾個名字討論看看那個比較好：特別是專案和檔案名稱，有太多因為命名導致一步錯步步錯的專案或檔案名稱了。

Coding Convention

現在這個時代，什麼東西都可以在網路上找到一份，coding standard也是，各家語言都會有標準建議的指南可以參考，例如:
C#
Java
Javascript
Golang
Python
Vue.js
Typescript
and more...

你們公司也有Coding standard嗎?有沒有什麼很奇怪的規定?歡迎分享給大家知道.