Hacker News Reader

Comment by acqq | Hacker News Reader

My "between" implementation would be like this:

    def between( a, low, high ):
        r = []
        for x in a:
            if low < x < high:
                r.append( x )
        return r

or even

   def between( a, low, high ):
       return [ x for x in a if  low < x < high ]

instead of their:

    def between(numbers, low, high):
        winners = []
        for num in numbers:
            if (low < num) and (num < high):
                winners.append(num)
        return winners

The more variable is local the shorter it should be. Also by using mathematical notation you display "functionality" instead of distracting readers with the terms you coined. "Winners"?

View on HN

Yes, I thought so too times ago, but when your numbers become more complex things, and one has overridden gt(), and you need to debug in a hurry, because what you are trying to do is not even remotely related, then the verbose version if much easier.

If the code is small, than short variables are easier to debug, because they are easier to manipulate, have less visual clutter, and are short scoped enough that you do not get a benefit from using a longer name. Not to mention the fact that you do not have the descriptive name obscuring what the code is actually doing.

> descriptive name obscuring what the code is actually doing.

Sorry but descriptive names are clarifying what the code is doing, or are not descriptive.

>Sorry but descriptive names are clarifying what the code is doing

Generally speaking this is true. However, when you are debugging, this no longer is true. When variables say what they are supposed to be, then it is more difficult to see that they are something else.

Descriptive names clarify what the code is supposed to be doing. Sometimes there's a world of difference between that and what it's actually doing.

> The more variable is local the shorter it should be.

I disagree, as someone with low experience with python, I found their example much more understandable than both of your examples.

It's a tradeoff between readability for novices and readability for experts.

I don't agree with that either, even in the languages I am well versed in not having to guess intentions or deduce variables is much easier. I think the tradeoff is really just keystrokes and laziness.

Even if I'm wrong, how often is it an expert, that is not yourself, left to maintain your old code?

Well, that's the beauty: however you define "between", once you have it, you can just say "if between(...)" and it becomes very readable.

If you want, you can subdivide this further and more clearly define the concepts used in the between function. But we don't generally choose to do that if the result is already a scant 5 lines.

Point: you should also take into account good modular design, something you have control over.

For me, the middle one is the most readable, but it's the hardest to figure out what data structure is being returned.

I agree with the middle one being the most readable (assuming you have python experience).

But isn't it obviously returning a list? It's a list comprehension!

Ahh, that's what it's doing! Yeah, I have no python expirence.

Honest question, why? What do you think you gained? Why use short variable names in this day and age given text editor auto-completion, refactoring tools, etc.

The very plurality of `numbers` conveys so much more meaning than `a` in the method signature. Is that a Python idiom, to use `a` to mean array as a parameter? What happens if you don't use `a` until line 23 of the function, far from its original declaration?

Being someone who likes reading random code in random languages, I find single or 2 letter variable names a horrible curse to the uninitiated of a problem domain. It means you have an extra step figuring out a program, what the abbreviations even mean in that particular domain.

The only exception being when it's the standard way of using the syntax of a language (i in a for loop for example).

Obviously these code examples are trivial, but when you start getting a slightly longer function, it starts becoming hard to remember what's what half-way down a function or where they even came from if they're just virtually meaningless single or dual letters.

What happens if you don't use `a` until line 23 of the function, far from its original declaration?

Then you have horribly violated the previous poster's note that the more local a variable is, the shorter its name should be.

I find single or 2 letter variable names a horrible curse to the uninitiated of a problem domain. It means you have an extra step figuring out a program, what the abbreviations even mean in that particular domain.

It is a trade-off. If you master that domain, you'll be using that all the time, and you'll get the savings all the time.

You need to amortize the cost of memorizing the notation over the expected usage of that notation. Programmers, by profession, have to use a lot of notations from a lot of fields, and therefore benefit from using notations that require a minimum of memorization. But that is not always the right trade-off.

As I pointed out in https://news.ycombinator.com/item?id=5157539, The rule is not that you need long or short variables. You need meaningful ones. A short variable name is inherently ambiguous, which can lead to confusion and mistakes. Thinking through anything with a long-variable name abuses your working memory, limiting how complex your thoughts can be.

I felt the same way about short variables names until I started using Haskel (which tends to have extremely local scopes). The idea is that if a variable is only used in 2 lines, it is not much mental effort to keep in your head what the variable is doing, but it is a relatively large amount to read the long name. However, most languages make it almost impossible to use variables with small scopes (in terms of spacing), so we only see good use of short variables in idiomatic places, such as for(i=0; i<10; i++).

For example, consider the parents original code: def between( a, low, high ): r = [] for x in a: if low < x < high: r.append( x ) return r Even as someone who 'likes' small variable names, the r make that difficult because of the all distance between its definition and use.

Compare that to this haskel implentation

between a low high = filter f a

where f x = x>low && x < high

(Actually, I would probably use 'as' instead of 'a')

In the given program "a" doesn't have to be an array, just something that can be iterated with "for x in a". So whenever you name it something definite you degrade the quality of your expression and obscure the potential for more uses. It goes so far that I actually time and again observe the projects where the same constructs are copy and pasted and the variables renamed once as "cows" an another time as "horses."(It's even worse people introduce different classes or types or whatever). Just like when you'd write:

2 * cows ^ 2 + 3 * cows = 48

instead of 2 * x ^ 2 + 3 * x = 48. In the history of the mathematics there was a time when x didn't exist, just "cows" - you weren't able to write an expression involving "the one unknown, no matter what it's supposed to represent." That was very long ago, still a lot of programmers today don't recognize the power of abstraction.

Reply on news.ycombinator.com