Hacker News Reader

Comment by flohofwoe | Hacker News Reader

IMHO most of those are not general "C++ anti-patterns", but instead define a personal C++ coding style (e.g. another C++ subset). It's important for teams to have such a coding style / C++ subset, but that doesn't mean that others are better or worse.

View on HN

I'd say it's a mix, but most of the anti-patterns listed seem to be pretty 'objectively' wrong, and not sensitive to house style. They generally aren't just subjective preferences. My thoughts on the first few:

Lowercase preprocessor constants. Doing this contradicts an established convention in C and C++, even used by the standard libraries. You simply shouldn't deviate from this convention, all you will do is introduce confusion. It's hard to think of a good reason to ever do this.

Preprocessor over scopes. This generally confuses and complicates things, but makes sense in rare circumstances. BOOST_SCOPE_EXIT does something like this, for instance.

Including source files (from a header file). Yep, that's a bad idea. I don't see why template specializations would be an exception.

Unnamed #if 0 branches. This doesn't strike me as obviously terrible. Using meaningful indentation would help here. Introducing a macro constant strikes me as introducing a new kind of complexity, given that the goal is just to comment out code. If the goal isn't to just comment out code, but to do 'conditional compilation', then that's different.

Standalone header files. Yes, a header file should include all the other headers it needs. Doing otherwise is sloppy, and no-one will thank you for wasting their time having to fix your headers.

Assuming that unconditionally enabled or disabled #if 0 and #if 1 sections imply some implicit flags or logic relating them to one another is particularly illogic. Unless the author has been exposed to someone who used them in complex ways as a poor man's version control system, of course.

> Unnamed #if 0 branches. This doesn't strike me as obviously terrible.

Your editor has a key command to comment/uncomment a block of code with line comments, use it. Similarly, C++ has syntax for comments, use it...

As the article mentions, unlike D [0], C++ block comments can't be nested, which is a point in favour of the #if 0 trick.

I agree it's generally better to use line comments using a good editor. This has the advantage that it plays nice with git diff, which will faithfully show every affected line. If you use block comments or #if 0, it will only show the 2 new lines that start and end the new comment block.

Trivia: Opposite to C, which originally had block comments and not line comments, the Ada language only supports line comments, with the reasoning that it's clearer at a glance whether a line has been commented out (especially in the absence of syntax highlighting).

[0] https://wiki.dlang.org/Commenting_out_code#Nested_comments

I know the reason why its done, and again, this is not a problem if you know how to use your editor.

The real anti-pattern is commenting out code to remove it. Delete it if not necessary, line comment anything else.

I think "template specializations" might have been the wrong term, and what was meant was "template implementations".

Perhaps I'm missing something I still don't see why you'd ever #include a .cpp file from a .hpp header file.

You can't separately compile and link in templates. The compiler needs to see the definition to instantiate it.

Meanwhile you might not want to put that definition in the header file so the header just contains the interface. Ergo you #include the implementation at the bottom of the header file.

That isn't an 'implementation file' in the relevant sense.

If the file is intended to be used with #include, it's a header file, and should be given the .h or .hpp extension. If the file corresponds to an object file in the build, it should be given the .cpp extension (or .cxx).

If you want to break apart your template metaprogramming into several .hpp files, you can do so.

Reply on news.ycombinator.com