在 Mathematica 中，内置符号以大写字母开头。因此，不以大写字母开头用户创建的符号名称是公认的做法。
这种限制应该在多大程度上扩展到语法的其他方面？好的做法是否要求不将大写字母用于 SetDelayed 中的命名模式？或 RuleDelayed表达式(此类名称已本地化)？
例如，我认为大写字母以一种有用的方式扩展了命名空间，并在视觉上区分了小写的 L 和 1。它们还允许以教科书的方式命名参数。
如果在 future 版本中引入新符号，命名模式应取代这些，并且现有代码不应中断。
如果存在诸如 N 之类的名称，则 con 是不明确的。和 D使用过，但我觉得使用上下文和前端语法突出显示都可以缓解这种情况。
最佳答案
这是我不接受的公认做法!
我指的是个人或第三方使用的包。
总的来说，我希望我完成的作品尽可能与理想 (WRI) 的质量、外观和感觉没有区别。
这包括我的命令的长描述性名称，以及 WRI 使用的所有大写约定。
当然，我的软件包 - 目前 - 远不及 WRI 质量，但至少我正在尝试将它们尽可能与标准 MMA 功能集成。这包括使用大写的命令。
在开发过程中，语法高亮提醒我可能与标准 MMA 函数发生冲突，因此我可以采取适当的措施。
当然，我的命令和包可能与 MMA 的 future 版本发生冲突，但没有什么是永远的，如果 future 的 MMA 命令在名称和功能上与我的命令相似，我将简单地切换到标准功能，命名更改最少或不更改.
除此之外，我发现使用大写字母来区分包命令和更普通的临时变量在视觉上更具吸引力。
如果您想查看一些视觉上不透明/不吸引人的代码，只需查看任何平均 Maple 代码即可。
关于模式变量，我尝试给出有意义的、主要是简短的、没有大写的模式名称，这样用户就可以通过查看 Ctrl/Cmd-K 模板来猜测我的包命令中需要什么样的输入。
关于wolfram-mathematica - 命名模式的大写字母，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/8018668/