Article Discussion
C++ Coding Standards
Summary: The C++ Source is pleased to present an excerpt from Herb and Andrei's new book, C++ Coding Standards: 101 Rules, Guidelines, and Best Practices (Addison-Wesley, 2005). More than just style guidelines and "gotcha" warnings, this book clarifies the idioms and practices that pertain specifically to successful C++ software. Even better, you can't avoid deepening your mastery of the finer points of C++ as you read. This is the singularly authoritative Writ of Common Wisdom for the entire C++ development experience.
1 post.
The ability to add new comments in this discussion is temporarily disabled.
Most recent reply: November 19, 2004 9:09 PM by Matthew
    Posts: 32 / Nickname: cda / Registered: February 11, 2003 0:06 PM
    C++ Coding Standards
    November 19, 2004 3:00 PM      
    Two leading C++ experts present hard-won wisdom for the entire C++ development experience.

    Read this excerpt form their new book:
    • Matthew
      Posts: 20 / Nickname: bigboy / Registered: June 14, 2004 10:43 AM
      Re: C++ Coding Standards
      November 19, 2004 9:09 PM      

      As I mentioned in the review phase, I disagree with the monotonicity of the unused parameter item. I can now avail myself of the underhanded option of repeating myself in this public forum, and I find myself unable to resist. ;)

      Many developers are diligently using automatic documentation tools, which can be stymied by an anonymous function parameter, and produce warnings of their absence. Since documentation tools may form an important part of an automated build process, it behooves us to get no warnings in that phase, as in any other. Hence, I believe the best, although perhaps not the most beautiful, approach is to do the following:

      /// \param name Blah blah blah name blah blah
      /// \param code Blah blah blah code blah blah
      int func1(char const *name, int code = 0)
      STLSOFT_SUPPRESS_UNUSED(code); // or whatever your macro of choice may be

      ... // Use "name" and do our stuff ...

      In this way, we placate the compiler and the documentation generator, and also provide what I'd argue is a more obvious mnemonic to maintainers of the code that we know the argument is unused and we're ok with that.