Warning: file_get_contents(/data/phpspider/zhask/data//catemap/2/ajax/6.json): failed to open stream: No such file or directory in /data/phpspider/zhask/libs/function.php on line 167

Warning: Invalid argument supplied for foreach() in /data/phpspider/zhask/libs/tag.function.php on line 1116

Notice: Undefined index: in /data/phpspider/zhask/libs/function.php on line 180

Warning: array_chunk() expects parameter 1 to be array, null given in /data/phpspider/zhask/libs/function.php on line 181
Wolfram mathematica 命名模式的大写字母_Wolfram Mathematica_Symbols_Names - Fatal编程技术网

Wolfram mathematica 命名模式的大写字母

Wolfram mathematica 命名模式的大写字母,wolfram-mathematica,symbols,names,Wolfram Mathematica,Symbols,Names,在Mathematica中,内置符号以大写字母开头。因此,不以大写字母开头用户创建的符号名称是公认的做法 这个限制应该扩展到语法的其他方面吗?良好实践是否要求在SetDelayed或RuleDelayed表达式(这些名称是本地化的)中的命名模式不使用大写字母 我认为大写字母以一种有用的方式扩展了名称空间,并在视觉上区分小写字母L和1,例如。它们还允许以教科书的方式命名参数 如果在将来的版本中引入新的符号,则命名的模式应取代这些模式,并且现有代码不应中断 如果使用了N和D等现有名称,则con是不明

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

这个限制应该扩展到语法的其他方面吗?良好实践是否要求在
SetDelayed
RuleDelayed
表达式(这些名称是本地化的)中的命名模式不使用大写字母

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

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


如果使用了
N
D
等现有名称,则con是不明确的,但我觉得使用上下文和前端语法突出显示都会缓解这种情况。

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

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

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

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

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


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

+1但我认为1如果您的名字具有足够的描述性,1 WerCase L很容易与1区分开来。此外,名称空间扩展的使用应该谨慎考虑:命名一个symbo1 myHome和另一个myHome是一个c1assica1 bug炖食谱…@belisarius因为我喜欢简洁的编码,我的大多数模式名称都是一个字符,因此
l
1
非常相似。同样地,我可能会混淆
f[A_u,A_u]:=。全球使用我同意你的观点,我把我的全球名称写得更详细,但在这种情况下,我想知道我是否可以改变我的做法。经过思考,“大多数”并不准确,但许多是单个字母,特别是简而言之,很好地概括了替换规则。看见我想更改
l:Line[\uu]
L\u行
。也许你应该使用比mma使用的默认信使更好的字体来更好地区分
L
1
:)@yoda:)我想说,在交互式工作/笔记本电脑中,不使用大写名称是很有用的,以避免与内置或包装符号发生意外冲突。如果包装符号大写,这将有助于用户,而不是妨碍用户。所以,是的,我也喜欢包有大写的符号名。根据Roman Maeder的说法,在包中使用大写的公共函数名是一种公认的做法。对于包,大写的名称没有问题,因为完整(长)名称不同,因为上下文不同(
System`
vs无论包的上下文是什么),所以冲突显示为阴影实例。避免阴影是另一个问题。