"Paul Mensonides" <pmenso57@comcast.net> writes:
It takes very little effort to manually format the code that you write, and any
I agree, but from that point on, you then have to remember to not re-indent a region of code from the editor. Sprinkling such problems throughout code simply adds to the burdon of maintaining code. It is a pain to keep having to go back through the code and re-hand-indent certain lines after auto-indenting a whole file or a region of it.
decent C++ programmer should be able to read the code formatted according to another's preferences--without reformatting it.
I can read the following code, but it says the wrong thing to anyone who doesn't have familiarity with the internals of the macro. Assuming that SOME_MACRO1 is really a stand-alone statement and has its semicolon provided by the macro: statement1; SOME_MACRO1() // misleading lack of visible semicolon statement2; // (this auto-indented by editor) statement3; This is more than a problem of just indenting statement2. It also gives the impression that SOME_MACRO1's expansion somehow bleeds into statement2. A bad macro written the other extreme: #define SOME_MACRO(X) if(X) int main() { SOME_MACRO2(5); // misleading semicolon statement2; } However, I'd call this a poorly designed macro because it's misleading and error prone. My personal guidelines are: 1) when a macro is logically its own statement, then the user should provide the semicolon to aide in readability. This makes it clear that the macro is "done". Therefore, I'd write SOME_MACRO1 to have the user provide the semicolon. This requires that the macro actually be done and its effect doesn't spill into the following code. 2) when a macro is intended to modify the code that follows it, then it should not have visible trailing semicolons or they will mislead the user. It should be obvious from indentation that the macro is being applied as a prefix to the code that follows, rather than a self-contained statement.
I don't have a problem with tools like these, BTW. I have a problem with altering the purity of a code base when it isn't absolutely necessary.
I consider myself somewhat of a language purist, but fail to see how a semicolon affects "purity" in any way. It's a seperator. It seems clear to me how the semicolon's presence (or lack thereof) can confuse maintence programmers, cause code to be formatted in a misleading way, and consequently impress a wrong mental view to people reading the code what is happening, however. -- Chris