Hacker News Reader

Comment by enriquto | Hacker News Reader

I do that. Then people hate me because all my variable names are single letters...

At least, for functions use self-documenting names instead of "f", "g", as in math.

I do that. Then people hate me because all my variable names are single letters...

Then you're thinking in math and also writing in math, so you're getting the second bit wrong. You need to write in code, and code should be optimized for readability.

I think single letter variable names are fine within the scope of a single function. Especially if I'm doing something with a lot of math, like a lighting calculation, the computations are often more readable with short variable names. I'll also usually give a detailed description of what the variable is in comments for clarity.

I think single letter variable names are fine within the scope of a single function.

I don't. One of the things I like most about eslint is the id-length rule - https://eslint.org/docs/rules/id-length

I think it depends. In the context of a complex mathematical formula, where you have many intermediate results with very abstract meanings, I think it's more clear to use a single character name than to try to be descriptive with something like: `productOfLuminanceAndDotProductOfSurfaceNormalAndLightDirectionDividedByScatteringConstant`.

I think there are a lot of advantages to abiding by styling conventions and using linters to set a baseline, but there are always exceptions to the rule.

* productOfLuminanceAndDotProductOfSurfaceNormalAndLightDirectionDividedByScatteringConstant*

Note that the id-length rule also allows you to limit the maximum length of a variable name. This is why.

I understand that, but what in your mind would be a good replacement to name such a complex, abstract value? A long acronym perhaps? I don't see how that's any more clear or less arbitrary than a single character name.

Agreed. I'd much prefer something along these lines as opposed to using an overly long name:

/* product of luminance and dot product of surface normal and light direction divided by scattering constant */

const prod = ...

I find that I can reason about code more effectively the shorter the variable names are. Rob Pike writes the same thing in the Practice of Programming.

I thought the point of code is to make it more difficult for the non-initiate to read it...

Actually, I think a good, justly polymorphic function should probably have a word of a reasonable length and parameters that are called `a`, `x`, `f`, since the parameters convey almost no information. If they have any greater length, it's just a restatement of the known information about the type.

The more unique information a name conveys, the less information the types convey and the bigger a chance you have of bugs or coding yourself into a hole.

But also, if you've called it `x` hopefully there's only one thing it can be and its scope is just one or two lines so you've written a single unit. If there's anything else `x` could be, then you've got a problem - your unit is too much.

Not every piece of code should be written this way, but your vocabulary should be built up of pieces like this.

For that matter, use self-documenting names in math, too. And please don't recycle notation for completely unrelated concepts, even if they are in different fields.

Coming to math from computing, the only explanation I can come up with for the disaster that is mathematical notation is that mathematicians are universally sadomasochists.

names work well in programs because the variable typically models something in the world we understand. company.name, NetworkConnection, etc.

In math and in programming this isn't always the case. Often you have a variable "epislon" that means "the tiny amount of space between this circle and the other circle that is shrinking".

In these cases there is no good name to give the variable. The meaning comes from the context.

In programming I follow the practice of using longer identifiers for more global scope, and shorter ones for smaller scope.

Which do you prefer?

(define (sqr x)(* x x))

(define (sqr number_to_square) (* number_to_square number_to_suqare))

Either over this:

(define (s x) (* x x))

Which is effectively what the OP does when they write their example. Their simple example quickly becomes unreadable after a few definitions.

Even for loop variables like I and J and using x, y and z for dimensions ?

Mathematical notation is a primitive notation, and will go the way of Roman Numerals. I would recommend the book "Clean Code", which might convince you to lengthen your identifier names :)

we need to make a sml company

Reply on news.ycombinator.com