如何看待 Golang 用首字母的大小寫來確定訪問許可權？

01-26

是否侵犯了程序員的變數命名自由權？
相似問題：
如何看待Python用下劃線來確定訪問許可權？

沒聽過那句話么

「福瑞多不福瑞」

py沒有訪問許可權的限制，大家按照約定用下劃線區分。

java有限制，然後100行代碼里50行的getter 和setter。

軟體開發本來就是trade off的產物，編程語言作為特殊的軟體產品也不例外。

靈活容易濫用，嚴格導致繁瑣。

比起最後讓項目團隊自己再去制定編程規範，提供語言級別的規範其實是在吸取了以前的經驗教訓的出來的明智之舉。

題外話：

順著題主的思路，IT行業應該是泯滅個性，專制統治典型了。

代碼格式要統一格式化，毫無個性

結對編程，互相監督

自己寫測試，自我審查、自我閹割

反饋bug，鼓勵舉報

藥丸，藥丸

Haskell還通過字母大小寫來區分是類型還是類型的模板參數呢，怎麼不見大家提意見（逃，不過我對此沒有意見，因為我是大寫字母開頭愛好者。

啥？變數命名自由權？你啥時候有過？不還得根據約定或規範走嗎？

Golang這種做法，其實提升了代碼的可讀性。使用public之類的關鍵字，只能在定義時看到其可見性。大小寫就不一樣了，代碼隨處可以表示其可見性。說實話，比用下劃線好多了。

感覺題主的問法容易招噴誒，呵呵

先說權利的問題吧，語言是一個工具，使用工具自然有使用方法，權力也是在一個規定範圍之內的，工具給你提供功能，你遵循工具的規則，並沒有什麼問題

而且，工具並沒有限制你在工具之外的自由，我也不喜歡go這個特性（更不喜歡的還有其他一些語法），所以做一個符合我習慣的語法的語言，然後編譯到go，又可以利用到go的優點，又不用成天看它折磨自己眼睛，豈不是很好，這就是自由的權力

再說說關於這個技術設計的問題，這事分兩塊看：

1 是否需要一種新的區分訪問許可權的設計

我認為是需要的，go的出發點是對的，譬如java和C++，到處寫public private關鍵字的確很繁瑣，這是一方面，另一方面是許可權控制有點太死，所以go的「私有」元素的應用範圍放到package級別，我認為是相對比較合適的

2 具體做法，用大小寫確定訪問許可權是否合適

這個問題我投反對票，我認為或者說我的習慣，在看代碼的時候看到一個name，首先想知道它是什麼，至於許可權則是後面的事情，在這方面慣例做法似乎是：全大寫+下劃線是常量或宏，大寫開頭的駝峰是類或介面等（非基礎的類型），小寫開頭的駝峰或者全小寫+下劃線是變數，而函數和方法則可能是大寫開頭駝峰或小寫開頭駝峰，go的這個做法給已有習慣造成混亂（不管以前的好不好，但它已經是一個慣例了），一個name是什麼就扔給這個name本身的單詞含義來決定，但如何給變數取合適的名字這個問題……哎，不說也罷，也許我的圈子裡英語都比較差把

我個人不太喜歡這個特性。雖然相比輸入關鍵字省力還能規範代碼風格，但是在申明 orm struct 的時候還要注釋存儲欄位名轉成小寫就感覺無比蛋疼。

大括弧還不能換行呢，Golang 這是在悄無聲息地幫你形成良好的編碼規範吧。

你有權不用GoLang

各種語言中的 reserved word 是否侵犯了程序員的變數命名自由權？

不喜歡 Golang 就自己寫一門語言懟它唄。

我覺得用大小寫確定許可權不太好。但原因並不是「命名自由權」，畢竟無規矩不成方圓。

這種方法可能的缺點：

對重構不友好。把public方法改為private，或者把private改為public的時候，需要修改大量代碼。
沒有隱藏實現細節。有點像臭名昭著的匈牙利命名法問題。是否public作為次要屬性，屬於實現細節。開發者只管調用，不應該care這些實現細節來分散注意力。
不能指定更多的訪問許可權。只能支持兩種，Java中有internal，private, protected, public四種。將來沒法擴展。
大寫單詞看起來不符合英文習慣。

變數就不該是public的。

不太想回答，畢竟一回答我自己都覺得可能在黑Golang。

試想一下public的變數到處用，然後你想更改它（無論是名字，還是去掉他，還是用另外的方式表達他）得多麻煩？信息和細節就應該隱藏。（另外還有名稱和訪問許可權耦合？）

所以還是getter比較好。

那麼，再回頭看用大小寫表示訪問許可權有意思么？別出心裁！

頭一次聽說程序員還有這麼個權利的……

我更希望維護我的代碼編譯通過權！

C++給你最大的自由！

python還建議你把私有變數用下劃線開頭呢，比強制你頭字小寫還噁心。蛇老腔們還把這東西叫做「the pythonic way」呢

這個問題總要有人解決的，語法層面上解決也是方案之一語法不規範的，代碼規範會替你規範；代碼規範不解決的，最佳實踐會推薦你；最佳實踐不解決的，代碼風格檢查器會幫你解決

你不放在語法裡面，無非就是額外增加學習負擔，到時候你得再找一篇文章介紹怎麼寫罷了。沒有區別的，還不如大家最開始都約定好，然後有法必究執法必嚴的好。

你看javascript自由不？一大堆程序員還不是開eslint？

所有編程語言都侵犯了我用頭打字就能編出程序的自由