[edgyswingset]

There's a happy middle ground there. At the call site is where it matters a lot more. If you have a function that's basically nothing but a pattern matching expression, the name of a parameter matters a lot less than the name of the input when you call that function. Same goes for what you name the result.

If you do this:

    let r = f x

Then you might be a fucker. But most good F# code I've seen is more reasonable:

    let res = getResult input 

Granted there's some exception, such as defining your own operators. F# does this itself, where "|>" is "let (|>) f g = g f". I don't think you gain much from adding verbosity to that.

[nv-vn]

In general, short names tend to be used for the most generic variables. Renaming "g" to "theFunction" in the (|>) one-liner doesn't really clear up anything. Just seeing it applied to something makes it clear enough that it's a function, etc. For something less generic the identifier can introduce the relevance of the variable better. But the thing about functional programming is that much of the code is written to be very generic, and so there's not much room to use longer names.

Also, another thing that I've noticed is that it becomes much easier to deal with short variable names in functional programming, because you know the value of the variable isn't about to change out of the blue. By restricting mutable state and side effects, it's possible to just substitute the values for variables wherever they exist. So for example,

    let r = getResult input
    let s = "abc" + r
    let t = doSomethingWith s
    printfn "%d" t

is known ahead of time to be exactly identical to

  "abc" + getResult input |> doSomethingWith |> printfn "%d"

Once you start introducing mutable state, something like that becomes a whole lot harder to read because you can never be sure if the values of those variables are changing, so you can't substitute in the declaration site.