命名模式的大写字母答案

【问题标题】：Capital letters for named patterns命名模式的大写字母
【发布时间】：2011-11-05 06:49:37
【问题描述】：

在Mathematica 内置符号以大写字母开头。因此，用户创建的符号名称不以大写字母开头是公认的做法。

这个限制应该扩展到语法的其他方面到什么程度？良好做法是否要求SetDelayed 或RuleDelayed 表达式（此类名称已本地化）中的命名模式不使用大写字母？

例如，我认为大写字母以一种有用的方式扩展了命名空间，并在视觉上区分了小写 L 和 1。它们还允许以教科书的方式命名参数。

如果在未来版本中引入了新符号，命名模式应取代这些，现有代码不应中断。

如果使用现有的名称，例如 N 和 D，则会产生歧义，但我认为使用上下文和前端语法突出显示都可以缓解这种情况。

【问题讨论】：

+1 但是 1 认为 1owercase L 很容易与 1 区分开来，如果你的名字足够描述的话。此外，命名空间扩展的使用应谨慎考虑：命名一个 symbo1 myHome 和另一个 MyHome 是一个 c1assica1 bug 炖菜 ...
@belisarius 因为我喜欢简洁的编码，所以我的大多数模式名称都是单个字符，因此l 和1 非常相似。同样，我怀疑我会混淆f[A_, a_] := ... 中的符号。全球使用我同意你的观点，我让我的全球名称更冗长，但在这种特殊情况下，我想知道我是否可以改变我的做法。
反思“大多数”并不准确，但很多是单个字母，特别是简而言之，封装良好的替换规则。见this answer；我想在该代码中将l : Line[__] 更改为L_Line。
也许您应该使用比 mma 使用的默认 Courier 更好的字体来更好地区分 l 和 1 :)
@yoda content.altfonts.com/img/B/B/BB-Monkey0.png :)

【解决方案1】：

这是一种公认的做法，我不接受！

我指的是供个人或第 3 方使用的软件包。总的来说，我希望我完成的作品与理想的 (WRI) 质量、外观和感觉尽可能没有区别。这包括我的命令的长描述性名称，以及 WRI 使用的所有大写约定。

当然，我的软件包目前还远不及 WRI 质量，但至少我正在尝试尽可能地将它们与标准 MMA 功能集成。这包括使用大写的命令。

在开发过程中，语法突出显示提醒我可能与标准 MMA 函数发生冲突，因此我可以采取适当的措施。当然，我的命令和包可能会与未来的 MMA 版本发生冲突，但没有什么是永远存在的，如果未来的 MMA 命令在名称和功能上与我的一个相似，我将简单地切换到标准功能，而命名的变化很小或没有变化.

除此之外，我发现在视觉上使用大写字母来区分包命令和更普通的临时变量更有吸引力。如果您想查看一些视觉上不透明/不吸引人的代码，只需查看任何普通的 Maple 代码。

关于模式变量，我尝试给出有意义的（主要是简短的）模式名称，不使用大写字母，因此用户可以通过查看 Ctrl/Cmd-K 模板来猜测我的包命令中需要什么样的输入。

【讨论】：

我会说在交互式工作/笔记本中不要使用大写的名称是很有用的，以避免意外与内置或与包冲突符号。如果包装符号大写，这将有助于用户，而不是妨碍她。所以是的，我也更喜欢具有大写符号名称的包。
根据 Roman Maeder 的说法，在包中使用大写的公共函数名称是一种公认的做法。对于包，大写名称没有问题，因为完整（长）名称不同，因为上下文不同（System` 与包的上下文不同），因此冲突表现为阴影实例。避免阴影是另一个问题。