I think the conventions in "Long Names are Long" are a pretty good balance between descriptive names and readability. You shouldn't try to completely describe a variable in its name, but it should...
I think the conventions in "Long Names are Long" are a pretty good balance between descriptive names and readability. You shouldn't try to completely describe a variable in its name, but it should be a hint.
Fortunately this isn't a major problem anymore, most languages have a very good LSP that allows you to replace all references of a selected name in the codebase, so it only affected related items....
If you invoke this name in many places, or the name is chosen such that a find-and-replace operation will return many irrelevant matches, it might be a pain to refactor the logic that depends thereupon.
Fortunately this isn't a major problem anymore, most languages have a very good LSP that allows you to replace all references of a selected name in the codebase, so it only affected related items.
If you have a server that you use to host a database, do not name the server “UserInformationDatabaseServer.”
Agreed given the context- we have a soft "rule" where I work that teams shouldn't be named after a particular component they work on because eventually the team may not actually be working on that component (it could be farmed off to another team, or they could be responsible for something else that wouldn't be intuitively included under that component). Instead, the team should have a name that unifies anything under them, now and into the future.
I wouldn't apply this principle to variables, and for physical systems like servers you can usually find a balance between something descriptive and prescriptive to name them. For example, a name that incorporates the server's placement and role without saying "this one runs the database."
I really dislike naming variables. It's probly the least fun part of programming for me. Different languages have different rules for naming variables vs properties of a class and method names,...
I really dislike naming variables. It's probly the least fun part of programming for me. Different languages have different rules for naming variables vs properties of a class and method names, and it's hard to remember them all. Nowdays I just let AI do it. Sometimes I go through a whole code file and change all the variable names to aaa bbb ccc whatever, and then I just have AI give me proper names for everything. This might seem wrong at first, but remember, Its not writing code, just giving my variables proper names, and usually they are really good, especially if you use one of the 'thinking' models.
Hah, I've never considered anything like that. That's really cool, actually. I don't see myself picking it up as common practice, but that's a really creative application of AI.
Hah, I've never considered anything like that. That's really cool, actually. I don't see myself picking it up as common practice, but that's a really creative application of AI.
The best article I've read on naming things yet is still Against Names where the advice is: don't. Obviously there are still plenty of places there it's necessary, but trying to change the framing...
The best article I've read on naming things yet is still Against Names where the advice is: don't. Obviously there are still plenty of places there it's necessary, but trying to change the framing to "can I just avoid giving this thing a name?" is a really useful thought process.
I don't know if I'm just not knowledgeable enough to read the advice in this article properly (I code but I'm not a professional software engineer), but this reminds me of a common type of comment...
I don't know if I'm just not knowledgeable enough to read the advice in this article properly (I code but I'm not a professional software engineer), but this reminds me of a common type of comment on deal websites. They'll say that a deal is no good because you can find many other better products at the same price or similar products for a lower price, but when asked to provide examples there's no response. So in this article there are a few examples of what not to do, but I'm not seeing any examples of what the author proposes is a better way. I feel like "lean objects with atomic purposes" sounds good, but what does the author think that would look like, practically? Or with "make things up" how does the author propose balancing silliness with practicality? I guess I just feel like I don't know what to do with these suggestions.
You make a perfectly fair point, I could definitely have been more illustrative of what I mean here. I apologize, this is one of the first things I've written with the intent to actually shove it...
You make a perfectly fair point, I could definitely have been more illustrative of what I mean here. I apologize, this is one of the first things I've written with the intent to actually shove it in faces :3
My intent in writing here is to try and make the strengths and weaknesses of using descriptive names and pet names clear. I'm not trying to say that one way is necessarily always better than the other, just that there are some situations which warrant one approach, and others that are best met with another.
So, in the case of a variable that will only ever store data on one specific thing, we would benefit from a descriptive name, because its purpose is as simple as it gets, and it doesn't depend on another function or library or what-have-you.
In situations where we expect things to change relatively quickly, or where we are trying to name things that are made up of a bunch of things, pet names might be better. So, take a website meant to convert GIFs into PNGs. We could name that GIFtoPNG.lol, but that name will become somewhat inaccurate if our service offering expands, or something (imaginary and unrealistic, in this case) happens that fundamentally changes that service offering.
Another commenter also linked to an excellent post that suggests naming on a spectrum over the binary I've been thinking about, which I think is probably the best way to go about this now. As best as I remember, the writer there kind-of suggests descriptive names that get more ambiguous as it gets harder to be descriptive, so as to avoid huge names whilst still providing at least hints as to what is actually going on. I maintain that it is still probably best to try to minimize the amount of situations wherein you need to do this, though.
///
Just checked, the comment and post I'm referring to is the one by skybrian linking to this
I think the conventions in "Long Names are Long" are a pretty good balance between descriptive names and readability. You shouldn't try to completely describe a variable in its name, but it should be a hint.
Fortunately this isn't a major problem anymore, most languages have a very good LSP that allows you to replace all references of a selected name in the codebase, so it only affected related items.
Agreed given the context- we have a soft "rule" where I work that teams shouldn't be named after a particular component they work on because eventually the team may not actually be working on that component (it could be farmed off to another team, or they could be responsible for something else that wouldn't be intuitively included under that component). Instead, the team should have a name that unifies anything under them, now and into the future.
I wouldn't apply this principle to variables, and for physical systems like servers you can usually find a balance between something descriptive and prescriptive to name them. For example, a name that incorporates the server's placement and role without saying "this one runs the database."
I really dislike naming variables. It's probly the least fun part of programming for me. Different languages have different rules for naming variables vs properties of a class and method names, and it's hard to remember them all. Nowdays I just let AI do it. Sometimes I go through a whole code file and change all the variable names to aaa bbb ccc whatever, and then I just have AI give me proper names for everything. This might seem wrong at first, but remember, Its not writing code, just giving my variables proper names, and usually they are really good, especially if you use one of the 'thinking' models.
Hah, I've never considered anything like that. That's really cool, actually. I don't see myself picking it up as common practice, but that's a really creative application of AI.
The best article I've read on naming things yet is still Against Names where the advice is: don't. Obviously there are still plenty of places there it's necessary, but trying to change the framing to "can I just avoid giving this thing a name?" is a really useful thought process.
I don't know if I'm just not knowledgeable enough to read the advice in this article properly (I code but I'm not a professional software engineer), but this reminds me of a common type of comment on deal websites. They'll say that a deal is no good because you can find many other better products at the same price or similar products for a lower price, but when asked to provide examples there's no response. So in this article there are a few examples of what not to do, but I'm not seeing any examples of what the author proposes is a better way. I feel like "lean objects with atomic purposes" sounds good, but what does the author think that would look like, practically? Or with "make things up" how does the author propose balancing silliness with practicality? I guess I just feel like I don't know what to do with these suggestions.
You make a perfectly fair point, I could definitely have been more illustrative of what I mean here. I apologize, this is one of the first things I've written with the intent to actually shove it in faces :3
My intent in writing here is to try and make the strengths and weaknesses of using descriptive names and pet names clear. I'm not trying to say that one way is necessarily always better than the other, just that there are some situations which warrant one approach, and others that are best met with another.
So, in the case of a variable that will only ever store data on one specific thing, we would benefit from a descriptive name, because its purpose is as simple as it gets, and it doesn't depend on another function or library or what-have-you.
In situations where we expect things to change relatively quickly, or where we are trying to name things that are made up of a bunch of things, pet names might be better. So, take a website meant to convert GIFs into PNGs. We could name that GIFtoPNG.lol, but that name will become somewhat inaccurate if our service offering expands, or something (imaginary and unrealistic, in this case) happens that fundamentally changes that service offering.
Another commenter also linked to an excellent post that suggests naming on a spectrum over the binary I've been thinking about, which I think is probably the best way to go about this now. As best as I remember, the writer there kind-of suggests descriptive names that get more ambiguous as it gets harder to be descriptive, so as to avoid huge names whilst still providing at least hints as to what is actually going on. I maintain that it is still probably best to try to minimize the amount of situations wherein you need to do this, though.
///
Just checked, the comment and post I'm referring to is the one by skybrian linking to this