Descriptive Variable Names: A Code Smell

[[)roi(]]

in opposition to "Self-documenting code"

More precisely, if you can name your variables after more descriptive things than f, a, b, and so on, then your code is probably monomorphic.
Monomorphic code is much more likely to be incorrect than polymorphic code, because for every type signature, there are many more possible implementations.
Thus, descriptive variable names are a code smell, indicating your code is overly monomorphic and more likely to be broken.
Fortunately, you can turn this around with a little refactoring process I call, extract polymorphism from monomorphism. While this refactoring does not always eliminate monomorphism, it can defer it, which is an overriding theme of functional programming (defer all the things!).
...
Introducing polymorphism can constrain the space of possible implementations and make it simpler to mentally verify correctness of a piece of code. Completely polymorphic type signatures don’t permit descriptive variable names, but they do vastly constrain the space of implementations.

:wtf:

Generic parameters can be a desirable quality in something like a reusable library or collection function where the input / outputs are known (e.g. map, reduce, ...), but using generics throughout an application codebase is certainly not going to help maintainability -- for that alone I'd call his advice an anti-pattern.

http://degoes.net/articles/insufficiently-polymorphic

 

[Batista]

Articles like this are dumb and remind me of all the dumb things they tried to teach you in CS101 that you will never ever use in the real world.

 

[Gnome]

I thought, jeez this article is total BS.
But let's see what else this guy writes, maybe he isn't just really bad at programming without knowing it.
Then he proposes in another article to replace if statements with Lambdas.

/closes tab

Guess that answered that question

 

[Hamster]

People should talk less and code more.

 

[Spacerat]

People should talk less and code more.

ppl like that should not be coding. pity the poor bastard having to maintain his code

 

[konfab]

in opposition to "Self-documenting code"
:wtf:

Generic parameters can be a desirable quality in something like a reusable library or collection function where the input / outputs are known (e.g. map, reduce, ...), but using generics throughout an application codebase is certainly not going to help maintainability -- for that alone I'd call his advice an anti-pattern.

http://degoes.net/articles/insufficiently-polymorphic

From a purely functional point of view, it makes sense. So for actual functions that you implement (like a maths function). The varable names should be as simplistic as possible to make things easier to read.

However when it comes to abstraction (describing the real world with objects), it simply does not make sense. If I have a class that describes a computer, how would it help having the variable holding the name of the computer being described as "a" as opposed to "name"?

 

[Kosmik]

I only learnt the term code smell this week. Where do they find these things?

 

[Hamster]

I only learnt the term code smell this week. Where do they find these things?

Any code base older than 6 months...

 

[Kosmik]

Any code base older than 6 months...

Lol, I meant the phrase but point taken

 

[[)roi(]]

From a purely functional point of view, it makes sense. So for actual functions that you implement (like a maths function). The varable names should be as simplistic as possible to make things easier to read.

However when it comes to abstraction (describing the real world with objects), it simply does not make sense. If I have a class that describes a computer, how would it help having the variable holding the name of the computer being described as "a" as opposed to "name"?

Agreed.

I especially like to use shortened variables names and/or sugar syntax within function closures; when the input is clearly defined there is no need to be also explicit within the closure, for example:

...dictionaryVar.map((k, v) => ...

With an associate array as the input: it should be obvious that k refers to the key, and v to the value; beyond functional closures, loop indexes, simple counters and pointers; I can't think of any other place where single character name is obvious.

Code should never be cryptic; plus the compiler won't reward you more for a shorter name vs. a more descriptive one.

 

[zippy]

we have programs with names like B8A05.o

After 7+ years at the company I still need to look the f***ing thing up ......

 

[[)roi(]]

we have programs with names like B8A05.o

After 7+ years at the company I still need to look the f***ing thing up ......

Picking the next one should be easy...

• B8A06
• B8A07
• B8A08
• ...

 

[BSoD]

I only learnt the term code smell this week. Where do they find these things?

It basically means that it is an indicator that there is a larger problem lurking. Like when you walk into a room and you catch a whiff and see your dog looking guilty.

 

[Kosmik]

It basically means that it is an indicator that there is a larger problem lurking. Like when you walk into a room and you catch a whiff and see your dog looking guilty.

I follow what it means, just was a phrase haven't heard before.