3 ms·
The selected answer from the OP has a reasonable explanation. The code is written by someone who knows the domain, and is using variable names which are commonl
by irahul 14y ago
The selected answer from the OP has a reasonable explanation. The code is written by someone who knows the domain, and is using variable names which are commonly used to describe equations in textbooks. I think if the programmer used the short, canonical names but made a top level comment explaining what he is implementing and where to refer for the equation and theory, that should be good enough.
Generally, if the variable is short lived, I prefer short variable names.
persons.each do |p|
p.activate
p.send_notification_mail
end
In fact, I think if you renamed the p to person, you convoluted the code. persons and person look the same if you aren't looking carefully. Iterators are definitely one case where short variable names are not only ok, but desired.
Another scenario is where the convention is to use a particular name for a particular type. As another commenter pointed out, golang conventionally calls ResponseWriter as w, and *Request as req. As a general case, if writer are w, it should be all right to name them w. This holds true for Go more than it does for Ruby. Being statically typed, you can make sure that w is indeed io.Writer and that's all the information you need.
Another tip from golang is if you have namespaces/modules, you need not repeat the same information twice. file.Writer(not go; an example) is better than file.FileWriter.
- gus_massa 14y agoAn important thing to teach to the students is that when they are solving a (physics) problem with pen and paper and create a new variable they must explain clearly what the variable is. So in this case I agree that it's ok to have short variable names, but wit a comment that explains the meaning of each one.