Mathematica組み込み記号は大文字で始まります。したがって、大文字でユーザが作成したシンボル名を開始しないことが慣例として認められています。名前付きパターンの大文字
構文の他の側面にこの制限をどのくらいまで拡張する必要がありますか？グッドプラクティスでは、SetDelayedまたはRuleDelayedという表現（名前がローカライズされている）の名前付きパターンには大文字を使用しないことを要求していますか？
大文字はネームスペースを有効に拡張し、たとえば小文字のLと1を視覚的に区別すると思います。また、引数はテキストブック形式で名前を付けることができます。
新しいシンボルが将来のバージョンで導入された場合、名前付きのパターンはこれらのシンボルに取って代わり、既存のコードは中断されません。
NやDなどの既存の名前を使用すると、曖昧さがありますが、使用のコンテキストとFrontEnd構文の強調表示の両方がこれを軽減すると感じています。
これは受け入れられない慣行です！
私は個人的または第三者の使用のために、パッケージを参照しています。 一般的に、完成した作品は理想的な（WRI）品質、ルック・アンド・フィールからできるだけ区別できないようにしたいと思います。 これには、WRIで使用されているすべての大文字の表記規則を使用して、わかりやすいコマンド名が含まれています。
私のパッケージは現時点ではWRI品質には至っていませんが、少なくとも私は標準のMMA機能でできる限り最善の方法でそれらを統合しようとしています。これには大文字のコマンドが含まれています。
開発中、構文の強調表示は、標準的なMMA機能との競合の可能性があることを警告するので、適切な処置を取ることができます。 私のコマンドとパッケージは将来のMMAのリリースと競合するかもしれませんが、何も永遠に続くことはありません。将来のMMAコマンドの名前と機能が私のものと似ているならば、ネーミング。
これ以外にも、大文字を使用してパッケージコマンドをより控えめな一時変数と区別することは、視覚的にははるかに魅力的です。 視覚的に不透明な/魅力的でないコードを見たい場合は、平均的なMapleコードを見てください。
パターン変数については、大文字ではなく、意味のある大部分の短いパターン名を使用しようとしています。そのため、ユーザーはCtrl/Cmd-Kテンプレートを見て、パッケージコマンドでどのような入力が期待できますか。
インタラクティブな仕事/ノートブックで大文字の名前を使用しないで、組み込みの*や*のパッケージシンボルでの偶発的な競合を避けると便利です。パッケージシンボルが大文字で表記されていれば、ユーザを助け、彼女を邪魔することはありません。だから、私はまた、パッケージが大文字のシンボル名を持つことを好みます。 – Szabolcs
Roman Maederによると、パッケージ内の公開関数に大文字の名前を使用する*は容認された方法です。パッケージの場合、文脈が異なる（ '' System''とパッケージのコンテキストが何であれ）ので、完全な（長い）名前は異なるので、大文字の名前は問題ありません。したがって、衝突はシャドーイングのインスタンスとして現れます。シャドーイングを避けることは別の問題です。 –
+1しかし、あなたの名前が説明力があれば、1のケースLは1と区別しやすいと思います。さらに、名前空間拡張の使用法は注意深く考慮する必要があります。シンボリックmyHomeと別のMyHomeという名前は、c1assica1バグのシチューレシピです。 –
@belisarius私は簡潔なコーディングが好きなので、パターン名のほとんどは1文字ですが、したがって、lとlは非常に似ています。同様に、 'f [A_、a_]：= ...'の中のシンボルを混同することは疑わしいです。グローバルに使用私はあなたに同意し、私はグローバル名をより冗長にしますが、この特定のケースで私は私の練習を変更できるかどうか疑問に思っています。 –
リフレクションでは、 "most"は正確ではありませんが、多くは1文字です。 [この回答]（http://stackoverflow.com/questions/5644801/tweaking-style-attributes-of-existing-graphics-objects-in-mathematica/5645482#5645482）を参照してください。そのコードで 'l：Line [__]'を 'L_Line'に変更したいと思います。 –