I've faced a situation whereby a report format was called something like the "42 Line" format. This is because 42 categories have been designed for it. These 42 categories are a higher-level classification than the "raw" categories, which number in the hundreds. Thus, there are two formats: "42 line" and the "long" (raw) format. I ended up making a boolean variable "is_42_line". However, 42 seems kind of arbitrary. What if they changed it to 43 next year? I could call them "long format" and "short format", but that is not descriptive either. Everyone in the biz knows it by "42 line". Thus, do I stick with industry lingo for clarity, or go for more general names, but risk it not being recognized?

Dealing with a new application gizmo, I initially unpacked it to an "unpack" folder to study it. After fiddling with the configurations I finally got it working. At that point I decided rename "unpack" to something more relevant. However, it stopped working when I renamed it. Something hard-wired that path in in the course of fiddling with configuration; so I am now stuck with that name.
----
''Thus, do I stick with industry lingo for clarity, or go for more general names, but risk it not being recognized?''

When presented with a problem like this, a CodeChangeImpactAnalysis proves helpful.  You must evaluate the costs involved with renaming the variable versus the costs involved with the long-term effects of ''not'' altering names.  Assuming you decide the former path less expensive, you then need to architect a roll-out plan.  Basically, you can do everything all at once or you can roll out the change over time.  Try to prefer the latter approach, as you'll find incremental changes easier to debug than all-or-nothing changes.

''I rarely go back and fix poor internal names unless I'm doing extensive rework for other purposes. Otherwise, it risks introducing new bugs. The more you study old code, the more stylistic problems you can find. One would never get anything done if they focused on all the imperfections that can turn up.''
-----
EditHint:  MeaningfulName, GoodVariableNames, BadVariableNames (''StuckWithBadVariableNames is needlessly verbose and topic happy'')

-----
CategoryNaming