3 ms·

> "MutexLock l" seems like a perfectly reasonable variable declaration to me Not to me. I use short variable names a lot, but I never, EVER name a variable "l

by csense 14y ago

> "MutexLock l" seems like a perfectly reasonable variable declaration to me Not to me. I use short variable names a lot, but I never, EVER name a variable "l" -- for the good and simple reason that "l" = chr(0x6c) looks too much like "1" = chr(0x31). I would call this particular variable MutexLock lock. If I must name a variable "l", I'll spell out the letter name: MutexLock ell. If I ever make my own language, maybe I'll make "l" a keyword that causes a compile error if it's ever used, to discourage others from this folly.

herge 14y ago
Also, one character variable names are much harder to search for in code review tools and source diffs. I saw code that always used ii, aa, etc. to make searching easier.
haberman 14y ago
Do you avoid using the number 1 for the same reason, falling back on 2/2? "l" and "1" don't look alike in any reasonable programming font.
- csense 14y ago
  > "l" and "1" don't look alike They look quite similar in this form submission field. (I'm using Chromium on Ubuntu.) > Do you avoid using the number 1 for the same reason Of course not. If you never use ell's, then anything that looks like it might be an ell is actually a one. The fact that these two characters look similar doesn't mean you can't use either of them; rather, you have to pick which one you'll allow yourself to use, and don't use the other one. Note that I only forgo using the token "l", not the character. So with my convetion, it's fine to call a variable "lock", or to use required names like the keyword "yield" or the "__call__" class method.
  - haberman 14y ago
    > Of course not. If you never use ell's, then anything that looks like it might be an ell is actually a one. Code is not just for your own eyes, it is for the eyes of future readers and maintainers. Though you might be aware of your "no bare l" rule, your readers are not. Besides the fact that "1" and "l" are intentionally made to look different in fonts used for programming, syntax highlighting usually makes numbers stand out from everything else. In my editor, "1" is red and "l" is black.
zerostar07 14y ago
Agree, one letter variables are only justified in fortran

by csense 14y ago

herge 14y ago

Also, one character variable names are much harder to search for in code review tools and source diffs. I saw code that always used ii, aa, etc. to make searching easier.

haberman 14y ago

Do you avoid using the number 1 for the same reason, falling back on 2/2? "l" and "1" don't look alike in any reasonable programming font.

csense 14y ago
> "l" and "1" don't look alike They look quite similar in this form submission field. (I'm using Chromium on Ubuntu.) > Do you avoid using the number 1 for the same reason Of course not. If you never use ell's, then anything that looks like it might be an ell is actually a one. The fact that these two characters look similar doesn't mean you can't use either of them; rather, you have to pick which one you'll allow yourself to use, and don't use the other one. Note that I only forgo using the token "l", not the character. So with my convetion, it's fine to call a variable "lock", or to use required names like the keyword "yield" or the "__call__" class method.
- haberman 14y ago
  > Of course not. If you never use ell's, then anything that looks like it might be an ell is actually a one. Code is not just for your own eyes, it is for the eyes of future readers and maintainers. Though you might be aware of your "no bare l" rule, your readers are not. Besides the fact that "1" and "l" are intentionally made to look different in fonts used for programming, syntax highlighting usually makes numbers stand out from everything else. In my editor, "1" is red and "l" is black.

zerostar07 14y ago

Agree, one letter variables are only justified in fortran