[dchapp]

> Long verbose names don't cost anything

They absolutely do have a cost. The question is whether the benefit they bring in implicit documentation is worth their cost.

> Even beyond the DX of readable names, it also acts like a type-checker. By reading the code, you can verify at least the semantics make sense.

I would strongly prefer that the actual type system do this job instead. As a toy example, if a function is only meant to operate on "lengths" (i.e., non-negative scalar values) then that should be modeled in the types of its arguments, not in its name.

[edflsafoiewq]

Modelling in the type system has a cost too. You have to digest a lot of text (wrapping & unwrapping, etc.) just to understand that you're passing a length. Comparatively some extra characters in an identifier are basically free and can tossed in anywhere.

[dchapp]

That may be a fair criticism in some cases.

For my toy example I don't think it is because it's generally easy (in the languages I work in) to overload arithmetic operators on types that are basically constrained scalars so there's no explicit wrapping/unwrapping to do when you want to operate on them as if they were plain scalars.

Maybe you could give me an example of the kind of pathological situation you're alluding to?

[shepherdjerred]

> I would strongly prefer that the actual type system do this job instead. As a toy example, if a function is only meant to operate on "lengths" (i.e., non-negative scalar values) then that should be modeled in the types of its arguments, not in its name.

Have you never worked in a dynamically typed language?

[dchapp]

I have. I prefer statically typed languages.

[plonk]

Python is only palatable with strict type checking everywhere. I don't see how unchecked dynamic typing can bring anything else than chaos in a large project.

[__Parfait__]

What's the cost?

[dchapp]

Readability. In particular, an increase in the rate at which long, verbose names which are mostly the same are confused with one another.

[nnnnico]

>They absolutely do have a cost.

what cost? aesthetics?

[patrick451]

Long, verbose variables are hard too read (it literally takes more time to read more characters), cause excessive line breaks, are harder to remember, and in general hurt readability more than they help.

[purplerabbit]

Cognitive overload. Storing 3-4 succinct variable names in your head takes the same energy as storing 1-2 verbose variable names in your head.

[Jcampuzano2]

I think there's some nuance though. If I'm the one writing the code, sure I can keep 3-4+ succint names of things I came up with in my head.

But then somebody else needs to look at this code in the future, and they're scratching their head as to what these names represent. Or somebody didn't really put enough thought into what the variables are, or gave them a name that only half represents what they actually mean.

I basically threw away all care for how long a variable name is long ago and have never had a problem. I just name it with enough words it needs to describe what it represents and don't fuss with making it smaller. With a decent IDE you don't even have to remember the whole name for things half the time, only parts of it.

[__Parfait__]

Cognitive overload.. Perhaps it'd be best to provide and example of a "verbose" variable name as compared to a "succinct"

Personally I'm thinking more along the lines of

Succinct ->KEY

Verbose -> MAIL_SERVICE_API_KEY