5 ms·

> Structs will have members called p with a comment saying "position". It seems very silly. It does not seem silly to me. Coming from mathematics, single-lett

> Structs will have members called p with a comment saying "position". It seems very silly. It does not seem silly to me. Coming from mathematics, single-letter variable names are the only acceptable possibility, especially in numerical code. I tend to read contiguous letters in a formula as products. Besides, descriptive variable names violate the principle of "don't repeat yourself". It is better to describe the variable only once, in a comment next to its declaration, instead of several times. Programmers should understand that not everybody who programs has a background in computer science, and certainly the traditional conventions of computer science are not universal and not generally reasonable. Many of us have a scientific background, where descriptive variable names are silly. We do not want our numbers to have meaning, that's the whole point of abstraction. Thus, they are named x, y, z, and so on.

v_lisivka 8y ago
If you are doing engineering, then it better to follow engineering best practices, with descriptive names. If you are doing science, it's better to follow science best practices. For example, we have two competing coordinate systems: first is x // width, y // height, z // depth, and second is x // width, y // depth, z // height. With descriptive names we will have no such problem. However, it's much easier to load large and complex algorithm into head if it written concisely: one letter per variable or function, minimum unnecessary separators. When I need to understand someone else codebase, I will often concatenate all files, delete all comments and obvious functions (getters, setters, eq, hash, etc.), abbreviate long names via search and replace, remove unnecessary symbols and convert functions and classes into oneliners, until I will see whole algorithm at once. However, reading of such code requires some additional training. To summarize, it's possible and is easy to convert descriptive names into abbreviations, so, it's better to stick with descriptive naming in public interfaces.
deleted 8y ago
[deleted]
mjburgess 8y ago
Programming languages are not mathematics, better to put your mathematics in the comments, than the reverse. force = (g_constant * mass[0] * mass[1])/(radius 2) Communicates far more than the algebraic alternative. Programming is about solving a particular problem, not providing a general formalism. The art of it, and mastery of it, is how to imbue the program with the problem domain. So that by speaking in its concepts you solve the problem. > violate the principle of "don't repeat yourself" That isnt the principle, that's a literal reading of each word conjoined into something totally different. The principle is "solve the problem once", ie., if you encounter code re-solving a problem already solved before, abstract such that you solve it only once. The principle only makes sense with respect to a problem which reoccurs, it is either incoherent or false when applied to literal fragments of code text. One would then be moved to define replacement macros for anything more than two letters.
- enriquto 8y ago
  > better to put your mathematics in the comments, than the reverse I respectfully, and strongly, disagree. Try to implement the conjugate gradient algorithm (or a variation of it) https://en.wikipedia.org/wiki/Conjugate_gradient_method https://en.wikipedia.org/wiki/Conjugate_gradient_method Using your style, you will obtain an unreadable mess. Better make your code isomorphic to your math, and then explain the meaning of everything in the comments. > force = (g_constant * mass[0] * mass[1])/(radius 2) > Communicates far more than the algebraic alternative. I don't see how this is clearer than something like this // Newton's law of gravitation // // m : mass of first body // M : mass of second body // G : universal gravitational constant // r : distance between the two bodies // F : force between the two bodies F = G * m * M / (r^2)
  - mjburgess 8y ago
    The problem arises at the 1000-line program level and above.
ddebernardy 8y ago
Assuming you have been writing code with single letter variables for long enough, try opening a medium to large sized project you wrote a few years ago and no longer use or maintain. See if you still understand your own code. Descriptive variables are about maintainability. And when it comes to the latter, the guiding principle is: > Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live. ^ https://stackoverflow.com/q/876089/417194 https://stackoverflow.com/q/876089/417194
- jjoonathan 8y ago
  I have had success using long names to good effect in non-mathematical code, but in mathematical code, I have never gotten them to work very well. I've tried many times over the years, but I just never seem to be able to squeeze all the relevant information into the names without making them excessively long, and even then I usually find upon rediscovery that I have omitted an important detail. Mathematics seems to thrive on a kaleidoscopic abundance of subtle but important variations on similar themes and this really frustrates the ability to encode information in the names. Also, the necessity of building an abstract-mathematical mental picture separate from the code obviates the need. The value proposition of verbose naming conventions entirely falls apart under these conditions, and once it does, the benefits of concision rule the day.

v_lisivka 8y ago

If you are doing engineering, then it better to follow engineering best practices, with descriptive names. If you are doing science, it's better to follow science best practices. For example, we have two competing coordinate systems: first is x // width, y // height, z // depth, and second is x // width, y // depth, z // height. With descriptive names we will have no such problem. However, it's much easier to load large and complex algorithm into head if it written concisely: one letter per variable or function, minimum unnecessary separators. When I need to understand someone else codebase, I will often concatenate all files, delete all comments and obvious functions (getters, setters, eq, hash, etc.), abbreviate long names via search and replace, remove unnecessary symbols and convert functions and classes into oneliners, until I will see whole algorithm at once. However, reading of such code requires some additional training. To summarize, it's possible and is easy to convert descriptive names into abbreviations, so, it's better to stick with descriptive naming in public interfaces.

deleted 8y ago

[deleted]

mjburgess 8y ago

Programming languages are not mathematics, better to put your mathematics in the comments, than the reverse. force = (g_constant * mass[0] * mass[1])/(radius 2) Communicates far more than the algebraic alternative. Programming is about solving a particular problem, not providing a general formalism. The art of it, and mastery of it, is how to imbue the program with the problem domain. So that by speaking in its concepts you solve the problem. > violate the principle of "don't repeat yourself" That isnt the principle, that's a literal reading of each word conjoined into something totally different. The principle is "solve the problem once", ie., if you encounter code re-solving a problem already solved before, abstract such that you solve it only once. The principle only makes sense with respect to a problem which reoccurs, it is either incoherent or false when applied to literal fragments of code text. One would then be moved to define replacement macros for anything more than two letters.

enriquto 8y ago
> better to put your mathematics in the comments, than the reverse I respectfully, and strongly, disagree. Try to implement the conjugate gradient algorithm (or a variation of it) https://en.wikipedia.org/wiki/Conjugate_gradient_method https://en.wikipedia.org/wiki/Conjugate_gradient_method Using your style, you will obtain an unreadable mess. Better make your code isomorphic to your math, and then explain the meaning of everything in the comments. > force = (g_constant * mass[0] * mass[1])/(radius 2) > Communicates far more than the algebraic alternative. I don't see how this is clearer than something like this // Newton's law of gravitation // // m : mass of first body // M : mass of second body // G : universal gravitational constant // r : distance between the two bodies // F : force between the two bodies F = G * m * M / (r^2)
- mjburgess 8y ago
  The problem arises at the 1000-line program level and above.

ddebernardy 8y ago

Assuming you have been writing code with single letter variables for long enough, try opening a medium to large sized project you wrote a few years ago and no longer use or maintain. See if you still understand your own code. Descriptive variables are about maintainability. And when it comes to the latter, the guiding principle is: > Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live. ^ https://stackoverflow.com/q/876089/417194 https://stackoverflow.com/q/876089/417194

jjoonathan 8y ago
I have had success using long names to good effect in non-mathematical code, but in mathematical code, I have never gotten them to work very well. I've tried many times over the years, but I just never seem to be able to squeeze all the relevant information into the names without making them excessively long, and even then I usually find upon rediscovery that I have omitted an important detail. Mathematics seems to thrive on a kaleidoscopic abundance of subtle but important variations on similar themes and this really frustrates the ability to encode information in the names. Also, the necessity of building an abstract-mathematical mental picture separate from the code obviates the need. The value proposition of verbose naming conventions entirely falls apart under these conditions, and once it does, the benefits of concision rule the day.