I disagree. I don’t want to have to hunt around for the definition of users to know how to use it. Yes the compiler will throw an error, but that doesn’t help me when I’m typing code.
"If there is more that one *Config in scope at any one time, calling them config1 and config2 is less descriptive than calling them original and updated ."
The correct naming is of course "originalConfig" and "updatedConfig".
I think your proposals are still missing some sort of indication or description on what type of configurations those variables might hold. After all, we don't want to have any unnecessary confusion, do we?
Yeah, just 'original' and 'updated' are probably a better choice.
Were my domestic pets actually amorphous blobs of text, damned straight I'd prefix or suffix their names with "dog" or "cat" just so I could keep them straight. "Honey, where's the header file for the blue one? Can't remember if it gets dog food or cat food."
To torture the metaphor a bit more, of course I'd eventually remember which one is which because they live with me. A better metaphor is the feral cat that shows up on my doorstep once a week looking for a handout. I've slept since then, what are you again?
My first girlfriend named our cat named Kitty; my first spouse named our truck Trucky and wouldn't let me name our snake Fluffy. Sometimes my variable names reference types, but typically in dynamically typed languages. Didn't read past the title because it's wrong about me and wrong about my code
Agreed. I think the article is wrong to imply that the type adds no value. Even if you have typechecking, the names of variables help you understand code. Also, why should we compare variables to pets versus the many other things in our life that we do refer to by their type? I don't have proper names for my filing cabinet or office chair.
That's good style. The important thing you will get out of the map is at the front of the variable name, and there's a less important little qualifier "byId" to help you understand how the data is structured.
I highly disagree with this advice. I understand the intent of the advice, I just think the proposed rule (in the body of the post) is a bad implementation of the intent because it is overly general.
Name your variable in a way that makes as clear as possible what the variable is used for.
He uses the example of "userMap". I think its mistake is not saying what the mapping is for. Names to users? Phone numbers to users? Emails to users? Its mistake is not calling it a map, which tells the reader that a variable behaves as a mapping. (And if it's not actually a map, then don't call it a map.)
> Name your variable in a way that makes as clear as possible what the variable is used for.
This is my consideration as well. It's like "documentation for free" or "commenting without comments".
When I get hit by a bus tomorrow, you will be able to look at my variables and have an easy, viable clue about what is going on. Reading my mind will be that much easier when figuring my code.
>Don't name your variables after types: you wouldn’t name your pets “dog” or “cat”
I would if I could not tell just by looking at them what species they are (and thus what I can do with them, what to feed them, etc) among 200 other animals in my house.
I completely agree--having inherited a few applications worth of .NET code in which the last (younger, right out of college) developer named all the variables for things from Norse Mythologies.
I also inherited a bunch of circa-2005 ColdFusion with aptly named variables in CamelCase which are much easier to understand.
varUsersTableID > pointer*Freya any day of the week.
Firstly, I have known several people to name their animals some variation of their type, but barring that.
I see it as a courtesy to myself than those that come after me to provide relevant context to a variable name. If the type in the scope of the variable is meaningful to its use then I will include it.
Good or bad code tells me what it does, rarely does it tell me what its supposed to do.
32 comments
[ 3.1 ms ] story [ 83.0 ms ] threadThe correct naming is of course "originalConfig" and "updatedConfig".
Yeah, just 'original' and 'updated' are probably a better choice.
“He’s the only one. He knows I’m talking to him.”
To torture the metaphor a bit more, of course I'd eventually remember which one is which because they live with me. A better metaphor is the feral cat that shows up on my doorstep once a week looking for a handout. I've slept since then, what are you again?
"UsersMap": doesn't add much value, what are you mapping?
"UsersById": now this is my style
Name your variable in a way that makes as clear as possible what the variable is used for.
He uses the example of "userMap". I think its mistake is not saying what the mapping is for. Names to users? Phone numbers to users? Emails to users? Its mistake is not calling it a map, which tells the reader that a variable behaves as a mapping. (And if it's not actually a map, then don't call it a map.)
This is my consideration as well. It's like "documentation for free" or "commenting without comments".
When I get hit by a bus tomorrow, you will be able to look at my variables and have an easy, viable clue about what is going on. Reading my mind will be that much easier when figuring my code.
犬 = Inu = Dog
I would if I could not tell just by looking at them what species they are (and thus what I can do with them, what to feed them, etc) among 200 other animals in my house.
My cat has a name, but I just call him "cat" most of the time.
The point being - if the name is not ambiguous, it's fine.
I also inherited a bunch of circa-2005 ColdFusion with aptly named variables in CamelCase which are much easier to understand.
varUsersTableID > pointer*Freya any day of the week.
this is hilarious.
I see it as a courtesy to myself than those that come after me to provide relevant context to a variable name. If the type in the scope of the variable is meaningful to its use then I will include it.
Good or bad code tells me what it does, rarely does it tell me what its supposed to do.