7 ms·

>so "x::xs" looks alien and very unapproachable And how is head::tail any better? That's like insisting for loops use "counter" instead of "i".

klibertp 14y ago
It's better - in so many ways that I will necessarily offer you just a short summary of some of them. Being able to figure out a meaning of something is crucial in programming. We spend much more time reading the code than writing it and most of the time during reading is spent on resolving the meaning of symbols. To be able to tell what a symbol means, one needs to take into account many things - from OS it's running on to language it's written in to declared variables in the scope. And much more, of course. Now back to your example: to be able to understand `x::xs` I need to know that `::` is a cons operator. Or more precisely, to understand the meaning of `x` symbol I need to take into account another symbol. On the other hand of the spectrum is something like this: `first_element_of_list :: rest_of_list`. To understand the meaning of the first symbol in this expression you need to know exactly one symbol - itself. That's one benefit. The second is that someone who doesn't know what consing is, let alone how it's written in OCaml, can still understand this expression. So that's the second benefit. It's worth remembering that we do not write the code for ourselves nor for the computers. We write the code to be read by other humans (always - don't argue). As with any kind of writing, then, it's helpful to know the audience. If I was writing a tutorial on constructing lists in OCaml (for beginners), I would use the second example above. But if I was writing production code (so for me and my team to read) I would use something shorter, like `head :: tail` for example. And if I was writing a quick and dirty script for my personal use, or if I was contributing to the work of hardcore OCaml hackers I would probably write `x :: xs` - because in case of script I'd be convinced that readability doesn't matter and in second case I would be certain that everyone reading and working with the code I wrote would be already so used to the construction that they would read it without problems. That's another thing to consider: after using a language for a long enough time we tend to internalize its idioms; when this happens we are able to treat bigger constructs as one symbol. This ability helps in reading the code quickly, but it's worth remembering that not everyone developed it. Also, because longer names do not hinder quick-reading of idioms for those who know them, that's not a counterargument to longer names. As for loops... Well, I do - sometimes - use `i` as a variable name, but I tend not to. Most often, after a while I come back to the code and replace `i` with `idx`. But to even use `i` as a name in the first place it needs to refer to the nonnegative integer value. In Python you generally iterate over collection directly, so you write `for what_is_it in a_collection:` instead of for example: `for i in 1 to 10: an_element = a_collection[i]`. Anyway, I use single letter variables very sparingly and in the smallest scope possible. What I want to say, I guess, is that descriptive names are important in good programming and that there is really no argument for using non-descriptive ones.
- papsosouid 14y ago
  You write bad code. If you are using anything other than a single letter for a simple for loop iteration, then you are making your code less readable, not more. Adding cognitive load to a trivial process is bad, not good. You summarize your argument by saying descriptive names are important, but your examples do not support that at all. Descriptive names are important for things that need to be described. If I write a function "reverse_string" with a single string argument, that argument had damn well better be named "s". There is no longer name that can convey any useful additional information. Many longer names will be distracting, and make the code harder to read.
  - klibertp 14y ago
    "Many longer names will be distracting, and make the code harder to read." Do you have any source for this? I really can't imagine this happening, seriously. "You write bad code." I see, it's one of those days when you just have to be a dick to someone. Ok, no problem, moving on... To reiterate without needless things involved: can you prove that a) words between 1 and 6 letters of length are significantly harder to read for higher letter counts and b) having longer names, regardless of a, is not beneficial at all? If you can - please do.
    - papsosouid 14y ago
      Given that 90% of experienced programmers fall on the side of "i or gtfo", the onus is on you to prove that "counter" is beneficial. Any time I see a long variable name, I naturally assume it is important, and has a large scope. When you lie to me with your code, that makes it harder to read, not easier.
      - klibertp 14y ago
        "Given that 90% of experienced programmers" Is this your proof? Nice... "is on you to prove that "counter" is beneficial" And why not on you to prove that it's harmful? Because you don't have arguments? "Any time I see a long variable name, I naturally assume it is important" Very good habit, keep at it - and please define 'long' by the way. For me it means 14-20 characters; and short means 3 to 6 characters. "experienced programmers fall on the side of "i or gtfo"," Well, these are probably the same people who claim that comments in code are bad. Both claims are simply stupid. Anyone experienced enough - and not dyslectic... - will tell you that readability counts, that you should never or almost never use any name shorter than 3 characters and that you should comment your code heavily. Whoever tells you otherwise - to put it simply - writes bad code or wants you to write bad code. I find it amusing to see so many people mistaking familiarity for readability. Just because something is very familiar to you it doesn't mean that it's readable. It's a shame that people are unable to look at the matter objectively and hence they write bad, unreadable, hard to change and extend code.

klibertp 14y ago

It's better - in so many ways that I will necessarily offer you just a short summary of some of them. Being able to figure out a meaning of something is crucial in programming. We spend much more time reading the code than writing it and most of the time during reading is spent on resolving the meaning of symbols. To be able to tell what a symbol means, one needs to take into account many things - from OS it's running on to language it's written in to declared variables in the scope. And much more, of course. Now back to your example: to be able to understand `x::xs` I need to know that `::` is a cons operator. Or more precisely, to understand the meaning of `x` symbol I need to take into account another symbol. On the other hand of the spectrum is something like this: `first_element_of_list :: rest_of_list`. To understand the meaning of the first symbol in this expression you need to know exactly one symbol - itself. That's one benefit. The second is that someone who doesn't know what consing is, let alone how it's written in OCaml, can still understand this expression. So that's the second benefit. It's worth remembering that we do not write the code for ourselves nor for the computers. We write the code to be read by other humans (always - don't argue). As with any kind of writing, then, it's helpful to know the audience. If I was writing a tutorial on constructing lists in OCaml (for beginners), I would use the second example above. But if I was writing production code (so for me and my team to read) I would use something shorter, like `head :: tail` for example. And if I was writing a quick and dirty script for my personal use, or if I was contributing to the work of hardcore OCaml hackers I would probably write `x :: xs` - because in case of script I'd be convinced that readability doesn't matter and in second case I would be certain that everyone reading and working with the code I wrote would be already so used to the construction that they would read it without problems. That's another thing to consider: after using a language for a long enough time we tend to internalize its idioms; when this happens we are able to treat bigger constructs as one symbol. This ability helps in reading the code quickly, but it's worth remembering that not everyone developed it. Also, because longer names do not hinder quick-reading of idioms for those who know them, that's not a counterargument to longer names. As for loops... Well, I do - sometimes - use `i` as a variable name, but I tend not to. Most often, after a while I come back to the code and replace `i` with `idx`. But to even use `i` as a name in the first place it needs to refer to the nonnegative integer value. In Python you generally iterate over collection directly, so you write `for what_is_it in a_collection:` instead of for example: `for i in 1 to 10: an_element = a_collection[i]`. Anyway, I use single letter variables very sparingly and in the smallest scope possible. What I want to say, I guess, is that descriptive names are important in good programming and that there is really no argument for using non-descriptive ones.

papsosouid 14y ago
You write bad code. If you are using anything other than a single letter for a simple for loop iteration, then you are making your code less readable, not more. Adding cognitive load to a trivial process is bad, not good. You summarize your argument by saying descriptive names are important, but your examples do not support that at all. Descriptive names are important for things that need to be described. If I write a function "reverse_string" with a single string argument, that argument had damn well better be named "s". There is no longer name that can convey any useful additional information. Many longer names will be distracting, and make the code harder to read.
- klibertp 14y ago
  "Many longer names will be distracting, and make the code harder to read." Do you have any source for this? I really can't imagine this happening, seriously. "You write bad code." I see, it's one of those days when you just have to be a dick to someone. Ok, no problem, moving on... To reiterate without needless things involved: can you prove that a) words between 1 and 6 letters of length are significantly harder to read for higher letter counts and b) having longer names, regardless of a, is not beneficial at all? If you can - please do.
  - papsosouid 14y ago
    Given that 90% of experienced programmers fall on the side of "i or gtfo", the onus is on you to prove that "counter" is beneficial. Any time I see a long variable name, I naturally assume it is important, and has a large scope. When you lie to me with your code, that makes it harder to read, not easier.
    - klibertp 14y ago
      "Given that 90% of experienced programmers" Is this your proof? Nice... "is on you to prove that "counter" is beneficial" And why not on you to prove that it's harmful? Because you don't have arguments? "Any time I see a long variable name, I naturally assume it is important" Very good habit, keep at it - and please define 'long' by the way. For me it means 14-20 characters; and short means 3 to 6 characters. "experienced programmers fall on the side of "i or gtfo"," Well, these are probably the same people who claim that comments in code are bad. Both claims are simply stupid. Anyone experienced enough - and not dyslectic... - will tell you that readability counts, that you should never or almost never use any name shorter than 3 characters and that you should comment your code heavily. Whoever tells you otherwise - to put it simply - writes bad code or wants you to write bad code. I find it amusing to see so many people mistaking familiarity for readability. Just because something is very familiar to you it doesn't mean that it's readable. It's a shame that people are unable to look at the matter objectively and hence they write bad, unreadable, hard to change and extend code.