命名图案的大写字母

Mathematica内置符号以大写字母开头。因此，不接受以大写字母开始用户创建的符号名称的惯例。命名图案的大写字母

这个限制应该延伸到语法的其他方面多远？良好做法是否要求大写字母不用于SetDelayed或RuleDelayed表达式（其中这些名称已本地化）中的命名模式？

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

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

如果使用现有名称（如N和D），则con是不明确的，但我觉得使用上下文和FrontEnd语法突出显示可以缓解这种情况。

2011-11-05 Mr.Wizard

+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'。 –

这是我接受的一种被接受的做法！

我指的是个人或第三方使用的软件包。一般而言，我希望完成的作品尽可能与理想（WRI）质量，外观无差别。这包括我的命令的长描述性名称，以及WRI使用的所有大写约定。

当然，我的软件包目前还远没有WRI质量，但至少我试图尽可能地将它们与标准MMA功能集成在一起。这包括拥有大写命令。

在开发过程中，语法突出显示提醒我可能与标准MMA功能发生冲突，因此我可以采取适当的措施。当然，我的命令和包可能会与将来的MMA版本相冲突，但是没有东西会永远持续下去，如果将来的MMA命令在名称和功能上与我的命令和功能类似，我将简单地切换到标准函数，命名。

除此之外，我觉得在视觉上更吸引人的是使用大写字母来区分软件包命令和更适度的临时变量。如果你想看到一些视觉不透明/不吸引人的代码，只要看看任何平均枫叶代码。

关于模式变量，我尝试给出有意义的，大部分都是短的，没有大写的模式名称，所以用户可以通过查看Ctrl/Cmd-K模板来猜测我的包命令中需要什么类型的输入。

来源

2011-11-05 15:50:19 magma

我会说在交互式工作/笔记本中不使用大写字母的名字是很有用的，以避免*意外*与内置符号*或包符号冲突。如果包裹符号大写，这将有助于在这个用户，而不是阻碍她。所以是的，我也更喜欢包含大写符号名称的包。 – Szabolcs

根据Roman Maeder的说法，在软件包*中使用公用函数的大写名称是一种公认的做法。对于包，大写的名字没有问题，因为完整的（长）名称是不同的，因为上下文是不同的（“System”与任何包的上下文都是不同的），所以冲突将自己表现为阴影的实例。避免阴影是一个不同的问题。 –

命名图案的大写字母

回答

相关问题