"Paul Mensonides" <pmenso57@comcast.net> writes:
To humans, yes. To editors, well, that's a hard problem.
Not if editors can see through macro expansions, but I was referring to re-indenting by hand.
True, but that would require an editor to also be a project manager, or at least to be able to parse and understand (correctly) a makefile. Otherwise, it wouldn't know what preprocessor macros are defined or not from the command line, wouldn't know include paths, etc. That is hard enough to implement, but even harder to get fast enough to be acceptible.
I don't think that is an onerous task to split a line that is too long manually.
Well, I was thinking that if a variable name gets longer, it would likely be changed in all places it's used, and for that a search/replace may be applied. Then a followup indentation might be more convenient.
Also, in addition to reading code, one of the main purposes of indentation is to keep track of where you are when writing code. If you format code as you go along, there is no need to re-indent the buffer.
That's assuming no automated editing techniques are being used (editor macros, search/replace, IDE functionality to auto-refactor code into its own function, etc.)
Likewise, removing trailing whitespace can be done without any formatting changes.
True, but re-indenting is a convenient way to get all this done at once en masse, if you so prefer. (Well, it seems you don't prefer, but I do.)
This is what plain old block identing is for. You don't need a code formatter to do this.
It may make lines too long, and so you may wish to split a line, etc.
I don't worry too much if the whole file is generated, since I probably wouldn't be editing it anyway, but instead would be editing the spec file that was used to generate it. Or perhaps I'd edit the generator itself.
That's true, but you might be reading it to verify what the generator is doing.
You're right. I've written a few code generators and spent a lot of time making them format generated code cleanly, for precisely that reason. It also makes it easier to figure out precisely what's going on or how to use the code if you sometimes take a peek.
By using the word "logically", I meant that "X becomes Y" can quite reasonably be described as being Y.
I understand that, and that's what I'm disagreeing with. There is a different degree of indirection that is important.
Ok, I'm willing to listen and try to be open minded. What is it that I'm missing? Please consider this simple example: void log(char const * msg, char const * file, int lineno); #define LOG(X) log((X), __FILE, __LINE__) I have a few questions for you because I am kind of stubborn but if I feel convinced I'm wrong I'm willing to change. 1) Do you think that the LOG() macro should contain a trailing semicolon? 2) I'm pretty sure you'll say #1, but which of the following examples do you prefer? int foo() { LOG("NO SEMICOLON HERE?") // 1 stuff(); LOG("OR does this seem better?"); // 2 more_stuff(); } 3) Do you see harm if the macro does not contain the trailing semicolon? If so, what harm is it? Specifically, how does usage #2 above re-enforce bad understanding of macros? (Or am I misconstruing the nature of your objection?) 4) What is the important degree of indirection that I would be missing by talking about the usage of the LOG macro as a call to the log function? I understand that I could call it "a macro that expands to a call to the log function" but I don't think that anyone would be more enlightened by that. Other than being more detailed about what's really happening, it's not clear to me what important mistake is being made that bothers you. If our coding convention states that macros are uppercase, then we already know it's a macro, so simply repeating that is unnecessary, IMHO.
When you throw extra parenthesis after it and do other things to change how the preprocessor expands macros, then it blurs things up. But for the typical, standard usages of macros, this indistinction is not a problem.
I totally disagree. In fact, (if you're referring to something like full scale preprocessor metaprogramming) I'd go so far as to say the opposite. In that case, any indistinction is far less of a problem than it is with "standard usages of macros". Preprocessor metaprogramming is so obviously different than normal code that it hardly matters. It is the normal, relatively simple, uses that can cause the most damage.
Could you apply this to my LOG macro above, to put it into a concrete example of what's so bad? ... (snip a lot of interesting commentary) ... -- Chris