Question

I see a lot of objective-c code that just #defines local constants it needs, and then proceeds on its merry way. The problem is that, as far as I know, #defines aren’t scoped. Many of this is in Apple’s own example code. For example, in the TableViewSuite example 5, the drawRect function in TimeZoneView.m contains the following block:

#define LEFT_COLUMN_OFFSET 10
#define LEFT_COLUMN_WIDTH 130

#define MIDDLE_COLUMN_OFFSET 140
#define MIDDLE_COLUMN_WIDTH 110

#define RIGHT_COLUMN_OFFSET 270

#define UPPER_ROW_TOP 8
#define LOWER_ROW_TOP 34

#define MAIN_FONT_SIZE 18
#define MIN_MAIN_FONT_SIZE 16
#define SECONDARY_FONT_SIZE 12
#define MIN_SECONDARY_FONT_SIZE 10

Is there some reason I don’t understand that this is not absurdly dangerous? At a very minimum, shouldn’t we #undef these constants at the end of the function?

That’s my question I suppose:

Is it a better practice to define what you need in the file you need it, and un-define it at the end? Or do you think it’s better to just use static consts for this type of thing? Is there any performance penalty to using static consts, or is the compiler able to handle them just as efficiently as #define?

Answer 1

#defines in implementation files (.m) are by definition scoped to the file they’re in, since no one else #includes a .m file. (You do want to think carefully about this in common header files, where the scoping issue you mention is real, and SO_QUESTION_2345197_NAMESPACE_YOUR_CONSTANTS_APPROPRIATELY.)

For local constants in implementation files which is what you seem to be asking about, #define is more efficient to compile, but you don’t get the symbols when you debug. Local consts have that benefit, and in some cases (string constants? maybe? depends) prevent duplication of constant data in the binary, although at this point in the world, size and compile efficiency (and runtime efficiency to look them up) is basically noise unless you profile some tight loop and find an issue with it.