3 ms·

bool productPricingUpdatedAfterDeliveryFailedButEmailSent = false; I've seen variables with names like the above. It would have been better explained in a com

by snarfy 10y ago

bool productPricingUpdatedAfterDeliveryFailedButEmailSent = false; I've seen variables with names like the above. It would have been better explained in a comment and used a short variable name. Unless you like typing it forces you to use an editor with autocomplete (which you are crazy not to use one), and IMO pollutes the code. Variables should be easy to type and read. It's a trade off.

psylence519 10y ago
If you need that much information about a variable, I would expect, in general, that the context it lives in is doing waaaay too much and should be broken up.
- lgunsch 10y ago
  100% agree! I always try and remember the Single-Responsibility-Principle.
krylon 10y ago
Well, there is a middle ground between 'c' and writing a novel in a variable's name. Single letter variable names are okay for loop iteration variables, or e.g. x and y when dealing with 2D coordinates (i.e. if within the context a single letter name has useful meaning - I suspect physicists and the like find themselves in that situation often). But trying to give variables short names (which is a good thing) should not be an excuse to give them obscure names. As an extreme example, think of Perl, which has a "default variable", that has basically no name at all ($_). When used properly, one can, I guess, write marvelously succinct code, but I try to avoid it and use explicit names. The older I get, the more I tend to agree with Aristotle's general approach to ethics: Avoid extremes, seek a middle ground/moderation. I am not sure if it is a good ethical principle, but in many cases where ethics don't matter, it is a good guideline. So for Identifiers: Be short, but clear. When in doubt, choose clarity over brevity, but keep in mind that what might be clear to you could be highly obscure to somebody else. If at that point I was still in doubt, I would pick a name based on how the variable is used: The more rarely it used, and the more significant it is to the program, the more reasonable it becomes to use a verbose name, especially when it is a global variable. For locals, one can always use a short name and a comment to explain what role it plays.
kazinator 10y ago
Firstly, there are noise words in there. If there is no other kind of pricing in that context beside product pricing, "product" is useless. If the order of operations is perfectly clear from the program flow, "After" is useless. "But" is a useless conjunction which doesn't add any information to "EmailSent". This kind of thing can be broken into multiple Booelan variables: bool pricingUpdated; bool deliverySucceeded; bool emailSent; These can be initialized or assigned at various points in the flow. Then later we can have: if (pricingUpdated && !deliverySucceeded && emailSent) ...
- snarfy 10y ago
  I totally agree, and this is a good example of how I would refactor that noise.

by snarfy 10y ago

psylence519 10y ago

If you need that much information about a variable, I would expect, in general, that the context it lives in is doing waaaay too much and should be broken up.

lgunsch 10y ago
100% agree! I always try and remember the Single-Responsibility-Principle.

krylon 10y ago

Well, there is a middle ground between 'c' and writing a novel in a variable's name. Single letter variable names are okay for loop iteration variables, or e.g. x and y when dealing with 2D coordinates (i.e. if within the context a single letter name has useful meaning - I suspect physicists and the like find themselves in that situation often). But trying to give variables short names (which is a good thing) should not be an excuse to give them obscure names. As an extreme example, think of Perl, which has a "default variable", that has basically no name at all ($_). When used properly, one can, I guess, write marvelously succinct code, but I try to avoid it and use explicit names. The older I get, the more I tend to agree with Aristotle's general approach to ethics: Avoid extremes, seek a middle ground/moderation. I am not sure if it is a good ethical principle, but in many cases where ethics don't matter, it is a good guideline. So for Identifiers: Be short, but clear. When in doubt, choose clarity over brevity, but keep in mind that what might be clear to you could be highly obscure to somebody else. If at that point I was still in doubt, I would pick a name based on how the variable is used: The more rarely it used, and the more significant it is to the program, the more reasonable it becomes to use a verbose name, especially when it is a global variable. For locals, one can always use a short name and a comment to explain what role it plays.

kazinator 10y ago

Firstly, there are noise words in there. If there is no other kind of pricing in that context beside product pricing, "product" is useless. If the order of operations is perfectly clear from the program flow, "After" is useless. "But" is a useless conjunction which doesn't add any information to "EmailSent". This kind of thing can be broken into multiple Booelan variables: bool pricingUpdated; bool deliverySucceeded; bool emailSent; These can be initialized or assigned at various points in the flow. Then later we can have: if (pricingUpdated && !deliverySucceeded && emailSent) ...

snarfy 10y ago
I totally agree, and this is a good example of how I would refactor that noise.