Mathematica內置符號以大寫字母開頭。因此，不接受以大寫字母開始用戶創建的符號名稱的慣例。命名圖案的大寫字母
這個限制應該延伸到語法的其他方面多遠？良好做法是否要求大寫字母不用於SetDelayed或RuleDelayed表達式（其中這些名稱已本地化）中的命名模式？
例如，我認爲資本以一種有用的方式擴展命名空間，並在視覺上區分小寫的L和1。他們還允許以教科書的方式命名參數。
如果未來版本中引入了新的符號，則命名的模式應該取代這些符號，並且現有的代碼不應該中斷。
如果使用現有名稱（如N和D），則con是不明確的，但我覺得使用上下文和FrontEnd語法突出顯示可以緩解這種情況。
這是我接受的一種被接受的做法！
我指的是個人或第三方使用的軟件包。 一般而言，我希望完成的作品儘可能與理想（WRI）質量，外觀無差別。 這包括我的命令的長描述性名稱，以及WRI使用的所有大寫約定。
當然，我的軟件包目前還遠沒有WRI質量，但至少我試圖儘可能地將它們與標準MMA功能集成在一起。這包括擁有大寫命令。
在開發過程中，語法突出顯示提醒我可能與標準MMA功能發生衝突，因此我可以採取適當的措施。 當然，我的命令和包可能會與將來的MMA版本相沖突，但是沒有東西會永遠持續下去，如果將來的MMA命令在名稱和功能上與我的命令和功能類似，我將簡單地切換到標準函數，命名。
除此之外，我覺得在視覺上更吸引人的是使用大寫字母來區分軟件包命令和更適度的臨時變量。 如果你想看到一些視覺不透明/不吸引人的代碼，只要看看任何平均楓葉代碼。
關於模式變量，我嘗試給出有意義的，大部分都是短的，沒有大寫的模式名稱，所以用戶可以通過查看Ctrl/Cmd-K模板來猜測我的包命令中需要什麼類型的輸入。
我會說在交互式工作/筆記本中不使用大寫字母的名字是很有用的，以避免*意外*與內置符號*或包符號衝突。如果包裹符號大寫，這將有助於在這個用戶，而不是阻礙她。所以是的，我也更喜歡包含大寫符號名稱的包。 – Szabolcs
根據Roman Maeder的說法，在軟件包*中使用公用函數的大寫名稱是一種公認的做法。對於包，大寫的名字沒有問題，因爲完整的（長）名稱是不同的，因爲上下文是不同的（「System」與任何包的上下文都是不同的），所以衝突將自己表現爲陰影的實例。避免陰影是一個不同的問題。 –
+1但是1想想1owercase如果你的名字足夠描述，L很容易與1區分。此外，命名空間的擴展使用應小心考慮：命名一個symbo1 myHome和另一個MyHome是一個c1assica1 bug燉菜配方... –
@belisarius由於我對簡潔編碼有愛好，大多數模式名稱都是單個字符，因此'l'和'1'非常相似。同樣，我懷疑我會混淆'f [A_，a_]：= ...'中的符號。全球使用我同意你的觀點，並且我使我的全球名稱更加冗長，但在這個特定情況下，我想知道我是否可以改變我的練習。 –
反思「大部分」並不準確，但很多都是單個字母，尤其是簡短的封裝好的替換規則。見[這個答案]（http://stackoverflow.com/questions/5644801/tweaking-style-attributes-of-existing-graphics-objects-in-mathematica/5645482#5645482）;我想在該代碼中將'l：Line [__]'更改爲'L_Line'。 –