>>Is there any reason to use a #DEFINEd constant instead of a local var? I've seen it done, but am not aware if the rationale, particularly when trying to debug...
>
>IMHO, JimB gave the best reasons. But here are a couple more. Code Complete states that source could should not ever contain a single string to be used in UI, or any "magic" numbers.
>
>A magic number is say, the number of departments in your company. For 25 years, your company might have had 5 departments, so at design time, you deem that 5 is a stable number for your application's "Department Count". But we all know how that works. Sooner or later, you will be searching your code for the number 5, and replacing it with 6. Instead, you should use a defined constant, so all of these "magic" number live in one place, and are easy to find and modify.

Yes, I can see the wisdom of that. So then, the answer to my local vs #define question would be: "neither" Such values should then go into a common header file even if only used one time in one method, for the sake of maintenance. I can buy that.

My only "conflict" lies, as others have mentioned, with the accessibiltity of these constants during runtime, as well as design, where you may have to constantly (gratuitous pun :) be looking them up in a header file, or else not using a header file, which defeats the purpose...

>
>The UI rule is a good one, but to be honest, I am much too lazy to adhere to it faithfully. The premise states that if you hard code the text for your messagebox MESSAGEBOX("Are you sure", MB_YESNO), you will be searching through source code when you port your app to a Portuguese version. If all of your UI text is kept in a header file, all of these strings live in one place, and you can simply give your header file to a translator, and go home for the evening.

I prefer just using the values here rather than constants - that's not perfect either, but anyone can obtain a list of messagebox values, and you get to have them memorized before long...