编码数学算法 - 我应该使用书中的变量还是更具描述性的变量?
我正在维护来自一本书的数学算法的代码,并在评论中引用。变量名最好能够描述变量所代表的内容,还是变量应该与书中的内容相匹配?
举个简单的例子,我可能会看到这段代码,它反映了书中的变量。
A_c = v*v/r
我可以将其重写为
centripetal_acceleration = velocity*velocity/radius
后者的优点是任何查看代码的人都可以理解它。不过,前者的优点是更容易将代码与书上的进行比较。我这样做可能是为了仔细检查算法的实现,或者我可能想添加额外的计算。
也许我想得太多了,应该简单地使用注释来描述变量是什么。然而,我倾向于支持自记录代码(使用描述性变量名称而不是添加注释来描述它们是什么),但也许在这种情况下注释会非常有帮助。
我知道这个问题可能是主观的,但我想知道是否有人有任何指导原则来做出决定,或者有数学算法编码指南的链接。
I'm maintaining code for a mathematical algorithm that came from a book, with references in the comments. Is it better to have variable names that are descriptive of what the variables represent, or should the variables match what is in the book?
For a simple example, I may see this code, which reflects the variable in the book.
A_c = v*v/r
I could rewrite it as
centripetal_acceleration = velocity*velocity/radius
The advantage of the latter is that anyone looking at the code could understand it. However, the advantage of the former is that it is easier to compare the code with what is in the book. I may do this in order to double check the implementation of the algorithms, or I may want to add additional calculations.
Perhaps I am over-thinking this, and should simply use comments to describe what the variables are. I tend to favor self-documenting code however (use descriptive variable names instead of adding comments to describe what they are), but maybe this is a case where comments would be very helpful.
I know this question can be subjective, but I wondered if anyone had any guiding principles in order to make a decision, or had links to guidelines for coding math algorithms.
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(7)
我更喜欢使用更具描述性的变量名称。您不能保证每个要查看代码的人都可以访问“这本书”。您可以离开并拿走您的副本,它可能会绝版,等等。在我看来,最好是描述性的。
我们在工作中使用了大量的数学参考书,并在注释中引用它们,但我们很少使用相同的数学缩写变量名。
I would prefer to use the more descriptive variable names. You can't guarantee everyone that is going to look at the code has access to "the book". You may leave and take your copy, it may go out of print, etc. In my opinion it's better to be descriptive.
We use a lot of mathematical reference books in our work, and we reference them in comments, but we rarely use the same mathematically abbreviated variable names.
常见的做法是在开始编写代码之前在注释标题中总结所有变量、索引和描述。例如。
A common practise is to summarise all your variables, indexes and descriptions in a comment header before starting the code proper. eg.
我编写了很多数学软件。如果我可以在评论中插入对书籍或论文或(最佳)网站的非常具体的引用来解释算法并定义变量名称,那么我将使用 a = v * v / r 这样的简短名称,因为它使公式更易于阅读、书写和视觉验证。
如果没有,那么我将编写非常冗长的代码,其中包含大量注释和长描述性变量名称。从本质上讲,我的代码变成了一篇描述算法的论文(有人还记得多年前 Knuth 的“文学编程”努力吗?虽然它的技术从未起飞,但我效仿了这项努力的精神)。我在评论中使用了大量的 ASCII 艺术,包括方框图和箭头图以及其他描述性图形。我使用 Jave.de——Java Ascii Vmumble 编辑器。
有时我会用简短、愤怒的小变量名称来写我的数学,因为我知道数学,所以更容易阅读和编写,然后使用 REFACTOR 在最后用更长、更具描述性的名称替换名称,但仅限于以下代码更加非正式。
I write a lot of mathematical software. IF I can insert in the comments a very specific reference to a book or a paper or (best) web site that explains the algorithm and defines the variable names, then I will use the SHORT names like a = v * v / r because it makes the formulas easier to read and write and verify visually.
IF not, then I will write very verbose code with lots of comments and long descriptive variable names. Essentially, my code becomes a paper that describes the algorithm (anyone remember Knuth's "Literate Programming" efforts, years ago? Though the technology for it never took off, I emulate the spirit of that effort). I use a LOT of ascii art in my comments, with box-and-arrow diagrams and other descriptive graphics. I use Jave.de -- the Java Ascii Vmumble Editor.
I will sometimes write my math with short, angry little variable names, easier to read and write for ME because I know the math, then use REFACTOR to replace the names with longer, more descriptive ones at the end, but only for code that is much more informal.
我认为这几乎完全取决于你所写的读者——并且也不要将编译器误认为是读者。如果您的代码可能由或多或少的“通用”程序员维护,他们可能不太了解物理,因此他们不会识别
v
和r< /code> 的意思是,那么最好将它们扩展为非物理学家也能识别。如果他们将成为物理学家(或者,再例如,游戏程序员),教科书中的缩写对于他们来说是清晰可见的,那么就使用缩写。如果您不知道/无法猜出哪个,那么最好选择更长且更具描述性的名称。
I think it depends almost entirely upon the audience for whom you're writing -- and don't ever mistake the compiler for the audience either. If your code is likely to be maintained by more or less "general purpose" programmers who may not/probably won't know much about physics so they won't recognize what
v
andr
mean, then it's probably better to expand them to be recognizable for non-physicists. If they're going to be physicists (or, for another example, game programmers) for whom the textbook abbreviations are clear and obvious, then use the abbreviations. If you don't know/can't guess which, it's probably safer to err on the side of the names being longer and more descriptive.我投票给“书”版。 “v”和“r”等很好理解为速度和半径的缩写,并且更紧凑。
I vote for the "book" version. 'v' and 'r' etc are pretty well understood as acronymns for velocity and radius and is more compact.
你会走多远?
大多数(非希腊语:-))键盘无法轻松访问 Δ,但它在某些语言(例如 C#)中作为标识符的一部分是有效的:
后来维护代码的任何人可能每天都会诅咒你。数学中使用的许多其他符号也是如此。因此,如果您不打算使用这些实际符号(我鼓励您不要这样做),我认为您应该翻译其余的符号,这样不会导致代码过于冗长。
此外,如果您需要组合算法,并且这些算法的变量使用存在冲突怎么办?
How far would you take it?
Most (non-greek :-)) keyboards don't provide easy access to Δ, but it's valid as part of an identifier in some languages (e.g. C#):
Anyone coming afterwards and maintaining the code may curse you every day. Similarly for a lot of other symbols used in maths. So if you're not going to use those actual symbols (and I'd encourage you not to), I'd argue you ought to translate the rest, where it doesn't make for code that's too verbose.
In addition, what if you need to combine algorithms, and those algorithms have conflicting usage of variables?
一种折衷的办法是按照书中的内容进行编码和调试,然后在开发结束时执行全局搜索并替换所有变量,以便更容易阅读。如果您这样做,我会稍微更改变量的名称,以便以后更容易更改它们。
例如 A_c@ = v@*v@/r@
A compromise could be to code and debug as contained in the book, and then perform a global search and replace for all of your variables towards the end of your development, so that it is easier to read. If you do this I would change the names of the variables slightly so that it is easier to change them later.
e.g A_c@ = v@*v@/r@