命名模式的大写字母

发布于 2024-12-13 23:31:18 字数 371 浏览 0 评论 0原文

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

这种限制应该在多大程度上扩展到语法的其他方面?良好实践是否要求在 SetDelayed 或 RuleDelayed 表达式(此类名称已本地化)中的命名模式不使用大写字母?

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

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

如果使用诸如 ND 之类的现有名称,缺点就是不明确,但我认为使用上下文和前端语法突出显示都可以缓解这种情况。

In Mathematica built-in Symbols start with capital letters. Therefore it is accepted practice to not start user created symbol names with capital letters.

How far should this restriction be extended to other aspects of syntax? Does good practice demand that a capital letter not be used for a named pattern in a SetDelayed or RuleDelayed expression (where such names are localized)?

I think that capitals expand the namespace in a useful way and visually distinguish between lowercase L and 1, for example. They also allow arguments to be named in a textbook fashion.

If new symbols are introduced in future versions, the named patters should supersede these, and existing code should not break.

A con is ambiguity if existing names such as N and D are used, but I feel that both the context of use and FrontEnd syntax highlighting mitigate this.

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(1

灯角 2024-12-20 23:31:19

这是我不接受的公认做法!

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

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

在开发过程中,语法突出显示会提醒我可能与标准 MMA 函数发生冲突,以便我可以采取适当的操作。
当然,我的命令和包可能会与 MMA 的未来版本发生冲突,但没有什么是永恒的,如果未来的 MMA 命令在名称和功能上与我的命令和功能类似,我将简单地切换到标准功能,而对命名进行最小或不进行更改。

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

关于模式变量,我尝试给出有意义的、大多是短的、不带大写的模式名称,以便用户可以通过查看 Ctrl/Cmd-K 模板来猜测我的包命令中需要什么样的输入。

This is an accepted practice that I do not accept!

I am referring to packages, for personal or 3rd party use.
In general I want my finished work to be as indistinguishable as possible from the ideal (WRI) quality,look and feel.
This includes long descriptive names for my commands, with all the capitalization conventions used by WRI.

Of course my packages are - at the moment - nowhere near WRI quality, but at least I am trying to integrate them as best as I can with standard MMA functionality. And this includes having capitalized commands.

During development, syntax highlighting alerts me of possible conflicts with standard MMA functions, so I can take appropriate actions.
Of course my commands and packages may conflict with future releases of MMA, but nothing lasts forever and if a future MMA command is similar in name and functionality to one of mine, I will simply switch to the standard function with minimal or no change in naming.

Besides this, I find visually much more appealing to use capital letters to distinguish package commands from more modest temporary variables.
If you want to see some visually opaque/unappealing code, just look at any average Maple code.

Regarding pattern variables, I try to give meaningful, mostly short, pattern names with no capitals, so the user can guess by looking at the Ctrl/Cmd-K template what kind of input is expected in my package commands.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文