Re: [boost] Macros at namespace scope: trailing semicolon?

From: Chris Uzdavinis (chris_at_[hidden])
Date: 2005-07-15 09:05:23

"Paul Mensonides" <pmenso57_at_[hidden]> 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