Google C++ Style Guide Is No Good - <AUTHOR> https://eyakubovich.github.io/2018-11-27-google-cpp-style-guide-is-no-good/ <comment><USER2> I disagree with a lot of the Google C++ style guide, but I disagree with many of the complaints in the post.

> Although GSG does not forbid them categoricaly, it says to "Avoid using > forward declarations where possible". However forward declarations are > useful in contexts like the following: ...

Yes, those are the cases where it isn't possible to avoid forward declarations, so it's fine to use them?

> While it's true that initialization/destruction order of globals between > translation units is not defined and can pose problems, this rule is overly > prohibitve. Globals like this are not problematic and very useful:

No, globals like that are _very_ problematic, so much so that there is a clang warning specifically to detect these (-Wexit-time-destructors). exit runs global destructors, so if one thread calls exit while some other thread is still doing stuff, it might destroy an object that's in use, leading to explosions. Also, if you're exiting, why are you paying to deallocate memory when it's all going to be blown away anyway?

> The lynchpin of C++ are value-types. Such types should be copyable and > moveable and the language automatically generates the necessary constructors > and operators by default. "a copyable class should explicitly declare the > copy operations, a move-only class should explicitly declare the move > operations" – this goes against the language philosophy.

It is very non-obvious which constructors will get automatically generated, because it depends on the types of the members. `Foo(Foo&& move) = default;` makes it immediately obvious.

<comment><USER3> > No, globals like that are very problematic

Indeed, they're terrible. What I don't understand is why basically every Google-authored project has loads of these (protobuf, gflags, TensorFlow...)

<comment><USER4> In Chromium they are so widespread that makes the rule showing that complex code cannot avoid them and defeating the rule.

</comment></comment></comment><comment><USER5> It seems to me that the biggest thing that the author does not know about the provenance of Google's style guide is just how _massive_ Google's projects that this guide applies to really are. A lot of the author's complaints may not make sense on their project with a few engineers, but they are absolutely vital in a code base on which thousands of engineers work on every day.

Those engineers often have to touch parts of the monorepo that are far away from what they usually work on, creating changes that need to go through reviews by teams that they have never interacted with before, and in turn need to be understood by future engineers in a similar position.

For example, the author states that "top level/application code" does not need to be in a namespace, but it's often downright absurd to classify what's considered "top level" code in Google's monorepo. I also chuckled at this:

> "Do not define implicit conversions". I would urge the reader to consider > what life would be like if std::string(const char*) constructor was marked > explicit (especially in the absense of user defined literals, which GSG also > outlaws). Nuff said.

At least when I worked with the code (many years ago, parts of Maps specifically), Google had its entirely own string handling routines that followed their conventions, and I did not miss std::string's implicit constructor much. This is a completely different world, where the standard library does not matter, and almost every code comes from Google themselves.

<comment><USER6> > It seems to me that the biggest thing that the author does not know about > the provenance of Google's style guide is just how massive Google's projects > that this guide applies to really are. A lot of the author's complaints may > not make sense on their project with a few engineers, but they are > absolutely vital in a code base on which thousands of engineers work on > every day.

I agree. People work on their small pet projects for school or wherever and think that's how enterprise development really works. Unless they have worked on a major project, it's very difficult for them to understand.

But even more important than sytle, it's consistency. You shouldn't use a coding style/standard because it works for google. You should create a coding style that works for your team or organization and stick to it consistently. Oftentimes, keeping to the style is more important than the style itself.

<comment><USER5> Totally! Consistency in even small things, like "try to order the names of your includes/methods/members alphabetically" take a good significant load of your brain, especially if you are working on a completely different part of the project that you are not fully familiar with.

</comment></comment></comment><comment><USER7> It's ambiguous in the article, and it's not specifically mentioned in the Google C++ Style Guide, but during code review at Google it's likely that a reviewer will object to this code:

      std::vector<int> v;
      v.resize(10, 42);

That form of std::vector::resize is discouraged because nobody can remember which argument is which. A reviewer would probably prefer:

      std::vector<int> v(10);
      std::fill(v.begin(), v.end(), 42);

Or even

      std::vector<int> v{42, 42, 42, 42, 42, 42, 42, 42, 42, 42};

I have some other quibbles with this article

* "Not marking it inline is a sure way to prevent inlining" is totally wrong) * The bit about using-directives is also pretty wrong. See [https://abseil.io/tips/153](https://abseil.io/tips/153) for why. And the example the author gives is terrible:

      void foo() {
        using namespace std::placeholders;
        std::bind(bar, _1, 2);

This doesn't even need a using-directive.

      void foo() {
        using std::placeholders::_1;
        std::bind(bar, _1, 2);

It's shorter, even.

To summarize, the Google C++ Style Guide is there to assist reviewers in reviewing new code. Contrary to what the author thinks, the guide doesn't prescribe anything. At Google decisions are always left to the reviewer. Read the Abseil libraries to see how the style guide applies and when it is ignored.

<comment><USER8> You'd never see `v.resize(10, 42);` because 10 and 42 would be in self- documenting variables, e.g.

```

int kDefaultValue = 42;

size_type kExpectedSize = 10;

v.resize(kExpectedSize, kDefaultValue);

```

<comment><USER9> ...though in this case it's still the reviewers job to help understand what the code does and if the reviewer doesn't know for sure which arg comes first then they still can't easily check that the code does what's intended.

<comment><USER10> The guide should then specify some common instances where arguments may be flipped.

</comment></comment></comment></comment><comment><USER11> I think the author misunderstands the difference between his use of C++ and Google's use, where Google wants to treat thousands of developers are largely exchangeable over billions of lines of code.

<comment><USER12> One problem is that many people fail to make that distinction and then cargo cult whatever google puts forth for style guides

People need to remember that just because Google does something one way does not imply it is correct nor that it is incorrect

</comment></comment><comment><USER13> > I can already hear an argument that there's a difference between "library > writers" and "everyone else". Maybe GSG should be waived for "library > writers" who are expected to be language experts. This is a dangerous world > view. We should not bifurcate developers into two camps as the reality > exists in a continuum between these two extremes. Every developer should be > a "library writer" as it is the only way to decompose the code into > manageable, testable and reusable units.

When I started at Google out of college, I came in writing clever, elegant code, and had to learn that, in large systems that will be touched by lots of people over large periods of time, readability is often more than worth sacrificing the maximally performant, concise, or elegant system. One of the ways to maintain this across a large organization is by limiting the set of available footguns, and granting exceptions when needed (eg, for "library code"). The latter type of code absolutely is bifurcated from generally- accessible and modifiable systems. The cost of doing the latter is increasing the hurdles to requires to modify the code, which already is and should be the case for widely-used library code. This seems obvious enough to me that I'm not sure how the author is misunderstanding it so badly (either that or I am).

Now, the author isn't completely wrong: another thing I've noticed is how much cargo cult, "Google does it" behavior there is among startups. Creating such an large-org-safe subset of C++ usage may not be appropriate for every type of organization, and if you don't understand why you're using GSG, it's probably worth figuring out whether it's a good fit. But the author utterly fails to make the claim that it's "no good", or even that it isn't appropriate in plenty of situations.

</comment><comment><USER14> I don't particularly like the style guide either, but the reasons presented here aren't great:

> GSG prefers #ifndef/#define idiom over the simpler #pragma once. Yes, > #pragma once is non-standard but widely supported.

I mean, it's non-standard. What more do you need?

> Although GSG does not forbid them categoricaly, it says to "Avoid using > forward declarations where possible".

The example provided is like the one place you would use a forward declaration. I'm sure it's fine in this case.

> Marking the function "inline" lets the compiler make the decision. Not > marking it inline is a sure way to prevent inlining, unless Link Time > Optimizations are turned on.

…for external linkage only. Inside your own code base, the compiler has this authority everywhere.

<comment><USER15> it is also less bugprone in the real world. There are cases where it doesn't work, but they amount to stupid things that nobody does outside of contrived examples.

I switched our codebase after finding several variations of #ifdef message_h #define massage_h That potential bug existed in our code base for years (I checked history)

<comment><USER16> The worst thing that happens due to this "potential bug" is that someone introduces a double inclusion of that header, which fails to be suppressed and the build blows up in their face due to duplicate definitions.

The error __could __be diagnosed by the compiler---submit a patch to gcc!

That is to say, if the following pattern occurs around the content of the file:

       #ifndef <whatever0>
       #define <whatever1>

       #endif

the compiler can validate that <whatever0> and <whatever1> are the same symbol, and emit a warning if they aren't.

Note that GCC already looks for this pattern and optimizes it! That has been implemented for ages; probably twenty years if not more. See here:

[https://gcc.gnu.org/onlinedocs/cpp/Once-Only- Headers.html](https://gcc.gnu.org/onlinedocs/cpp/Once-Only-Headers.html)

That optimization _must_ have a check in place that it's the same symbol in both places. And so that piece of code which checks can probably be augmented to emit a warning fairly easily.

A sophisticated version of the warning would only kick in if the symbols appear to be similar (e.g. close by Levenschtein distance) so that one of them is plausibly a typo for the other.

Another solution is to have a commit hook which looks for such a problem: it enforces the include guard on headers, and checks that the symbols match.

<comment><USER15> clang actually does have the warning you want gcc to have - this is how I found our instances of it.

What none of the above can do is two different projects have MESSAGE_H headers that are different can fully compatible to include both. #pragma once handles this correctly.

<comment><USER16> The clash between two different MESSAGE_H can be rendered vanishingly unlikely by having a convention of adding some random digits.

I adopted the following pattern some twenty years ago of affixing a random 32 bit number in hex:

       #ifndef MESSAGE_H_3DF0_9A73
       #define MESSAGE_H_3DF0_9A73

       #endif

<comment><USER17> If only the filesystem would assign some sort of unique, 32- to 64-bit identifier to files that a compiler could use to distinguish one header from another. We could call them inode numbers. Hmm. No, I'm sure no one has ever thought of the problem of identifying unique files before.[0][1]

I guess instead we must embed GUIDs in every file to keep track of uniqueness.

[0]: [https://stackoverflow.com/a/13172784/218830](https://stackoverflow.com/a/13172784/218830)

[1]: [https://stackoverflow.com/a/1866547/218830](https://stackoverflow.com/a/1866547/218830)

<comment><USER16> Copies of a file have different inode numbers.

<comment><USER17> I can agree with this statement of fact. I'm missing the part where it's relevant to the conversation or informs some conclusion.

<comment><USER16> It's relevant if I have a requirement that if a file happens to be duplicated, then the once-include mechanism should treat those copies as one object.

This could arise if the code is originally on a system where some header files are symlinks to a common file. These symlinks happen to break (due to the way the code is archived, or on some system that doesn't have symlinks or whatever); they turn into separate copies.

Exclusion that is keyed to a symbol that is encoded in the file has no problem with this; filesystem-id-based excusion doesn't handle the case.

<comment><USER17> > It's relevant if I have a requirement that if a file happens to be > duplicated, then the once-include mechanism should treat those copies as one > object.

I don't believe that is a reasonable requirement.

</comment></comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER18> There's a lot here, just a few comments:

> Although GSG does not forbid them categoricaly, it says to "Avoid using > forward declarations where possible". However forward declarations are > useful in contexts like the following [...]

Yes, circular data structures are a great reason to use a forward declaration; probably the best one. I think it is a perfect example of why the recommendation against forward declarations is not a prohibition.

Please, please do not forward-declare types you do not own. It constraints the way those types can be refactored. More info here: [https://abseil.io/about/compatibility#what-users-must-and- mu...](https://abseil.io/about/compatibility#what-users-must-and-must-not-do)

> The rule basically says that global/static variables with non-trivial > constructors and destructors are not allowed. While it's true that > initialization/destruction order of globals between translation units is not > defined and can pose problems, this rule is overly prohibitve. Globals like > this are not problematic and very useful:

A safe alternative to this is to use a static object inside a function. This can serve the same purpose without the gotchas.

> Even the inter-translation unit ordering is not a huge problem – Stroustrup > discusses it in his D&E book.

Experience says otherwise. In the protobuf code-base we have to put a thread- safe initialization check in all of our constructors because we have to statically initialize our default instances, but we can't guarantee these static initializers will run before other static initializers that use them. Static initialization ordering is a real and difficult problem.

</comment><comment><USER19> > Exceptions vs error codes debate is much like space-vs-tabs so I will sit > this one out. GSG forbids exceptions on the ground of "Google's existing > code is not exception-tolerant". I'm not sure what that refers to.

Read "Exceptional C++". It isn't worth trying to support them. It is an exercise in masochism. It isn't at all like tabs-vs-spaces.

<comment><USER20> it really isn't that hard if you practice RAII properly. I've used C++ exceptions on several large C++ codebases and not run in to major issues.

<comment><USER7> It results in slower generated code and much larger binaries, neither of which would be acceptable to Google (some of their binaries are already on the brink of being unbuildable, so a bunch of junk to enable exceptions is not possible.)

<comment><USER20> the slower generated code is an academic concern. Show me a realistic/non- contrived benchmark where not keeping the stack unwindable actually helps give a useful performance increase. Error codes force people to litter the code with branches and put error handling code in the hot path of the instruction stream.

<comment><USER19> Using 'likely/unlikely' compiler directives, the instructions in the unlikely error branch can be hoisted out to another area and not significantly affect instruction cache. It still is a branch though.

<comment><USER21> and exception-based code can have much less branches since you don't need to check every function call for error but instead let the exception propagate from where they can be thrown. e.g. in a hypothetic case where you load a settings file five layers deep, in an error-code-based solution you have potentially 5 branches while in an exception-based solution you only have one

<comment><USER22> At the cost of predictable performance though. With current implementations, the exceptional path will be several magnitudes (!) slower for cheap functions.

</comment></comment></comment></comment></comment></comment></comment><comment><USER23> >We should not bifurcate developers into two camps as the reality exists in a continuum between these two extremes.

This is presented without justification as if it must be true. But is it?

My view is that you absolutely should have different worlds. You can then limit the number of people and the amount of code using foot gun prone constructs to a very small minority, and instead provide higher level abstractions. I'd absolutely hate to see code that looks like Boost on the business layer of an application.

</comment><comment><USER24> > At the same time, every feature that went into the language was vetted for > being useful. It was deemed that without the said feature, the code was > significantly worse

Talk about an appeal to authority!

Cppcon had an entire talk titled "The Nightmare of Initialization in C++". C++ initialization is indeed a total clusterfuck. And that's not a controversial statement!

I'm sure each thing was added to solve a problem. But now there are too many things, and that's the new problem.

</comment><comment><USER25> There are some super boneheaded comments in here.

* "Don't use forward declarations unless necessary" with the counter example of why it's bad, being a case we're they're necessary?

* The complaint against "inline" is nonsense. The _only_ thing inline impacts is function linkage. Literally nothing else. If the compiler thinks a function is profitable to inline, it will inline it. If it does not think inlining is profitable it won't, the fact that you say "inline" means nothing.

* Complaining about complex globals initialisers: they directly impact library load time, they _do_ cause breakages on ordering. Yes you could structure your code to avoid ordering issues, but then every developer needs to work for all time to avoid breaking it. Or you could just not use them, and it's not a problem.

* Restricting copies: It should be super easy to tell at a glance if code is going to be needlessly inefficient. Easiest way to ensure that is to make your code fail to compile.

* Exceptions: they add significantly to code size and launch time. The failure modes are hard to reason about. The standard idiom everyone is move to is option<> or result<> types. It means you _have_ to handle errors, or be explicit in ignoring them.

* Template meta programming is extremely slow to compile, and very difficult for people to understand. constexpr is easier to read and understand, more efficient to compile, and can also be reused for non-constant cases.

* Boost: if you're using boost then you're requiring all your developers to install boost. Then you need to also ensure that they're all using the same version, and then people can end up requiring multiple versions. Again, super large company, with many many engineers and many projects mean the chances of multiple projects depending on different versions of libraries will cause misery.

* C++11 - Cool, it's 2018, guess what: many machines are running versions of an OS that has a 2018 edition of the C++ standard library. If you compile targeting newer versions of the standard library then you can't ship to those systems, unless you include a copy of the standard library in your binary. Then you have to hope your copy of the standard library doesn't conflict with any loaded by the system's own libraries.

<comment><USER26> Or even:

C++11 - Cool, it's 2018, guess what: Migrating a codebase as large as Google's from C++11 to C++1x is a bunch of work. And a lot of the C++1x goodies are library additions, available in Abseil <[https://github.com/abseil/abseil- cpp>](https://github.com/abseil/abseil-cpp>).

<comment><USER27> This attitude leads to companies to maintain COBOL codebases on the obscure mainframe for decades.

<comment><USER28> Yes,it motivates companies not to do expensive, unnecessary, high-risk complete replacements.

This may be less fun for developers, but it's not usually a bad decision.

<comment><USER27> High-risk complete replacements happen because some risk-averse developers/management resisted change for decades and now the company cannot gradually modernize.

[https://en.wikipedia.org/wiki/Phoenix_pay_system](https://en.wikipedia.org/wiki/Phoenix_pay_system)

</comment></comment></comment></comment></comment><comment><USER29> It seems like the author didn't read the guidelines very well. Especially this part:

"The intent of this document is to provide maximal guidance with reasonable restriction. As always, common sense and good taste should prevail."

There are good arguments for deriving from the guidelines in lots of situations, guidelines merely establish the default style, but don't prohibit code that does not follow the guidelines _if_ there is a good reason to. What the guidelines establish is a duty to justify deviations.

<comment><USER30> The author is complaining about the use of these guidelines in other places outside Google, especially for people who take these guidelines more seriously than Google itself.

<comment><USER29> I don't work at google, but do use the guidelines for github.com/jupp0r/prometheus-cpp. Why? because it's reasonable subset of C++ and it establishes a consistent style that I can point people to in PRs.

</comment></comment></comment><comment><USER31> It's very interesting to me that the author writes a critique of a style guide, but doesn't seem to have tried to understand the perspective of those who created it or what their goals were (they basically give this lip service)

They don't really try and understand the rationale in detail and then argue that that rationale would be better served through a different set of features, they mostly just say "hey I think Google is wrong and these features are pretty cool"

</comment><comment><USER32> I can't believe we still have developers who are completely against defensive language design/style. Foot guns are real and deadly. The lack of a restrictive style guide in C++ is how you end up with one of these projects: [https://news.ycombinator.com/item?id=18554272](https://news.ycombinator.com/item?id=18554272)

</comment><comment><USER33> Style guide is not meant for agreement, it's a general guideline to ensure that when developers come and go, the style and readability doesn't undergo a massive change. I've found it very useful. One can nitpick each style guide to death.

</comment><comment><USER34> The thing that bothers me about GSG is that it seems to be enforced across Google no matter what team you're in or what project you work on. Think about it: somebody who thinks that he knows better than you decided how you and other 10000s developers at Google should use C++. I think such approach is incredibly inflexible and shortsighted. Even if that somebody is a well- renowned C++ expert I would still doubt he can come up with the C++ style guide applicable to the whole Google. If I lead a project at Google I don't want someone unrelated to my project or some committee higher up to make decisions for my team. I want my team to decide how to use C++ (or any other language or technology for that matter) based on the project needs and the team developer skills. One coding style for everyone reduces the skill level of everyone to the lowest common denominator. Even if you have better skilled developers around you, if they can't use their skills professionally, they either quit or lose their skills. Soon you'll be surrounded by developers with only poor skills who you can learn nothing from. I remember a story told by Sean Parent (if you don't know him, look him up) about the time he worked at Google and he was told that his code is hard to understand because it uses concepts and ideas nobody at Google is familiar with (because they are likely not part of the GSG). I find that story quite instructive.

</comment><comment><USER35> I'm not a huge fan of the GSG, at least the C++ one. It seems to be less about style and more about forbidding scary language features. A language feature only becomes a "foot gun" in the hands of a careless developer. Maybe it's too idealistic but IMO it's better to fix the "careless developer" problem at the interview stage, not in a style guideline.

Hire developers who voluntarily follow best practices and use good judgment...don't try to mandate it with an arbitrary list of forbidden practices.

</comment><comment><USER16> > _GSG prefers #ifndef /#define idiom over the simpler #pragma once. Yes, > #pragma once is non-standard but widely supported._

Google is right here; a purely build-time issue, like avoiding including a header file twice, should be solved without having to resort to nonstandard language features.

The generated code doesn't change in any way, so it is gratuitous.

Save the language extensions for doing something that is inherently nonportable, like gaining access to some platform feature.

<comment><USER17> Meh. C and C++ should just standardize on #pragma once. Everything supports it. It's trivial for new compilers to implement. There's no reason a stupid preprocessor hack should still be required in order to prevent double- inclusion.

<comment><USER22> You could say that there's no reason we're still using a stupid preprocessor hack of textual inclusion to import interfaces.

As usual, the devil lies in the detail. If you want to make pragma once robust you need to checksum files, which in the end will be slower than include guards.

<comment><USER17> > You could say that there's no reason we're still using a stupid preprocessor > hack of textual inclusion to import interfaces.

You could say that. I didn't. Bolting on some sort of module system is just a totally different scope of enhancement than my modest proposal.

> As usual, the devil lies in the detail. If you want to make pragma once > robust you need to checksum files, which in the end will be slower than > include guards.

That's just not true. It doesn't need to be robust against byzantine source trees and/or build systems to be defined in the C standard or to be useful. The standard can leave the concept of "the same file" implementation-defined, as it does many other concepts.

On Unix system _C implementations_ , it is sufficient to use stat() and compare st_ino and st_dev against previously observed values for a given compilation unit. You do not need to checksum files. You _especially_ do not need to write the specific behavior of checksumming header files into the C standard.

<comment><USER16> > _It doesn 't need to be robust against byzantine source trees_

A locally developed hack, or even a compiler extension, doesn't have to be; an ISO-standard feature should be well specified.

If something is specified in such a way that it is less robust than the #ifndef trick, then any programmer worth their salt will use the #ifndef trick.

An acceptable pragma-once would look like this:

      #pragma once 9DF9-C3D9-BDF0

Basically it should take an argument string which specifies an ID for the file, intended to be unique.

<comment><USER17> > ISO-standard feature should be well specified.

That claim doesn't match up with the C standard I've read. I.e., this is an "isolated demand for rigor." Are we looking at the same document? Quite a lot is underspecified or implementation defined to accommodate differences in architectures and systems.

The 2018 C standard doesn't specify whether NULL is a pointer or integer; what a null pointer's representation is; nor the representation of negative (signed) integers. The C standard defines some _loose_ requirements around observable behavior and leaves the specific details to the implementation.

> Basically it should take an argument string which specifies an ID for the > file, intended to be unique.

Or the standard could leave it up to the implementation to identify file uniqueness without this additional, incompatible argument. Like I said before, all you have to do for Unix _implementations_ to be as robust as the stupid ifndef trick is to check st_ino and st_dev.

It's important to recognize that implementations and implementation details are distinct from the standard.

Also note that the ifndef hack is non-robust in its own way — false positive exclusions due to accidental identifier conflicts. #pragma once does not have this problem.

<comment><USER16> The #ifndef trick is highly portable and has clear semantics that is under the program's control. Nobody needs a platform-specific, underspecified alternative that saves two lines of code compared to the robust, portable solution. If I am paying with nonportability, I want "bang for the buck": like faster or smaller code on the target, or detailed control of its hardware or host platform features. I don't need unspecified _build machine_ behavior so much. I am not programming the build machine.

</comment></comment></comment></comment></comment></comment></comment><comment><USER36> Fun piece of trivia for you: The C++ Core Guidelines referenced in this article are longer than the language spec for Go.

</comment><comment><USER37> > GSG prohibits the use of static definitions and annonymous namespaces in > header files. How else do we declare constants?

Uhm… what?

1) I would challenge the author to produce any useful use of anonymous namespaces in header files that doesn't violate ODR. I'd also challenge them to not break ODR with constants in header files in the way they seem to mean.

I should add: without UB, plz.

2) How else do we declare constants? Uhm, how about: extern const int foo; or just "inline constexpr int foo = 1" in header but non-static and not in anonymous namespace?

> Globals like this are not problematic and very useful: [example of > nontrivially destructible global]

It doesn't _look_ dangerous, but allowing it does not scale to a billion lines of code. Code easier to reason about is less buggy code.

In general though: Author spends 1 SWE-year per year on coding, Google spends what, 100 SWE-millenia per year? It's optimizing for that use case.

</comment><comment><USER38> This article is so full of misconceptions.

> Unlike C++ Core Guidelines that try to explain how to use the language > effectively, GSG is about forbidding the use of certain features.

They aren't meant to accomplish the same thing. The GSG's goal is to standardize both style and feature set across the mono repo so that thousands of engineers can effectively contribute.

> We should not bifurcate developers into two camps as the reality exists in a > continuum between these two extremes.

It's a style guide, not an unwavering book of law. Library writers use some features that aren't necessary in non-library code. In fact, some language features are written specifically to the benefit of the implementers.

> GSG prefers #ifndef/#define idiom over the simpler #pragma once. Yes, > #pragma once is non-standard but widely supported.

When the difference is a 2 lines of code that you probably have tooling to generate anyways, why not default to the thing that's standard?

> Yes, both of these forward declarations are possible to avoid by type- > punning through a void* but it is not a good pattern.

The point of "Avoid using fwd-declarations where possible" is exactly that: reason about the code and whether the declaration is necessary. It's not "dogmatically avoid forward declarations". I'm sure no-one at Google is punning through void* for those examples.

> Marking the function "inline" lets the compiler make the decision. Not > marking it inline is a sure way to prevent inlining, unless Link Time > Optimizations are turned on.

That's simply not true. The compiler can inline a function if it can infer that it doesn't alter the program's behavior. Generally, tools make good decisions. Override them when you've measured that something else is better.

> Library code should always be placed in a namespace. Top level/application > code has questionable value being placed in a namespace.

It's easier to be diligent about placing everything in a namespace because application code doesn't always remain so. Especially not in a gigantic mono repo like Google's.

> GSG prohibits the use of static definitions and annonymous namespaces in > header files. How else do we declare constants?

I mean, you declare your constants in the header and define them in the implementation file. First example I can find in Chromium: [https://cs.chromium.org/chromium/src/ios/chrome/browser/pref...](https://cs.chromium.org/chromium/src/ios/chrome/browser/pref_names.h?rcl=82d8ee1e070100260963c8d76f23dcd2884099c9&l=11)

> The rule basically says that global/static variables with non-trivial > constructors and destructors are not allowed. While it's true that > initialization/destruction order of globals between translation units is not > defined and can pose problems, this rule is overly prohibitve.

This rule isn't overly prohibitive in the context of large applications that require clean startups/shutdowns and contain objects that are sensitive to construction/destruction order.

> "Do not define implicit conversions". I would urge the reader to consider > what life would be like if std::string(const char) constructor was marked > explicit (especially in the absense of user defined literals, which GSG also > outlaws). Nuff said.

The issue with implicit conversions is that they're not explicit to callers. Honestly, having to wrap a few const char* into std::string() calls wouldn't be as bad as you seem to think it would be. Explicit code is easier to read and reason about.

> "a copyable class should explicitly declare the copy operations, a move-only > class should explicitly declare the move operations" – this goes against the > language philosophy.

Again, this is about being explicit, and using safe defaults. It's not prohibited to make things copyable and movable but defaulting to the most restrictive set up and adding things as needed ensures that developers thought about the implications of those properties.

> In this pattern the private base cannot be replaced by a data member because > the base is constructed before the members.

I've never seen code with private inheritance that made sense and couldn't be refactored to something clearer.

> Operator Overloading

See my point about implicit conversion above because it's the same thing here. Operator Overloading tends to obfuscate code.

> I think this rule mixes together two ideas for no good reason. C++ has a > clear way to denote mutability – the const qualifier. Using pointer vs > reference to signal mutability goes against the language.

The const qualifier isn't visible from the call site. This rule makes it so that you can reason about what will happen to the values you're passing to a function based on whether you pass them by pointer, or by reference/value. It also prevents a library from changing an argument from const T& to T&, introduce mutations, and break callers as a result.

> Exceptions

Google's code is just setup to std::terminate instead of throwing. It's a minor performance gain AFAIK but it also avoids littering the code with try {} catch {} blocks. It forces developers to handle errors instead of propagating them whenever possible too.

> "Use lambda expressions where appropriate." – probably a cheap shot, but > what is the alternative? – use them where it's not appropriate?

This point seems counter-productive considering the author claims the guide is written in too much of a prohibitive fashion.

> Avoid complicated template programming.

TMP is hard, increases compilation times, and is difficult to reason about. The Guide recognizes its usefulness but suggests avoiding it where possible. This is similar to the library writer vs application writers argument: not everyone needs it, avoid it if possible.

All in all I think the author just doesn't have the same requirements, constraints, and sheer amount of developers/lines of code Google has. Nothing is forcing them to use the Guide. In fact, it's public but it was written for Google, by Google. It works for Google, and it's a great tool in that kind of organization.

Disclaimer: I work on Chrome, which has its own guide derived from the GSG.

</comment><comment><USER39> Perhaps it's a matter of rule-based versus principle-based view of the world. Generally speaking, in a principle-based system, there is room for different interpretations of the stated principles. Edge cases usually don't require special mention. In a rule-based system, rules are strictly defined and enforced with little room for interpretation. Anything not explicitly mentioned is a grey area and edge cases often end up amending the rules so they are covered as well.

Sounds to me like the author prefers the rule-based approach and/or is assuming these rules are strictly enforced.

</comment><comment><USER40> Having written C++ at Google using these (strictly enforced) style guidelines, I actually kind of likes Google's subset of C++.

It should be noted that any reasonably sized shop uses a subset of C++. It's insanity not to. It's just a question of what to allow and what not to.

Google C++ uses a style of error-handling that's akin to how Go handles errors. Many functions return a util::Status (which would be OK or an error) or, when you needed to return a value, return a util::StatusOr<T>.

Some people who write Go rail against the verbosity of this. I actually like it because it makes it pretty easy to reason about what your code is doing without the flow control you can get from exceptions.

There are definite warts in the codebase. One big one I remember was that one of the early developers (which might've been Craig Silverstein) didn't believe in unsigned types so there are a bunch of size functions that return an int and this has caused no end of problems.

I'm no C++ expert so I can't speak to some of the author's gripes (eg pragma- once vs #define/#ifndef) but a lot of the criticisms suggest that the author hasn't worked on large codebases.

Take operator overloading. This is fine, in theory, if used judiciously. The problem is engineers differ on what's reasonable and this may lead to unexpected behaviour, particularly when you start factoring in automatic type conversions. You see this in Scala, for example, where people go nuts, basically because they can and for no other reason.

There's a certain type of engineer who gets trapped in a mindset where they start considering complexity a virtue. I once got into a discussion with someone where he was shocked that I didn't know what perfect forwarding was. After looking it up I was like "why do I need to know this (unless I'm writing a templated library)?" and the answer is I don't.

Google's C++ style guide is largely about avoiding these flights of fancy making it into codebases that other people rely on, may need to debug, etc. And it achieves that goal as I found Google C++ code quite readable on the whole.

There's still a lot of code that doesn't, say, use smart pointers, so you can get dereferencing errors if you're not careful or if you don't understand who owns what. And this isn't something that C++11/14/17 smart pointers are perfect at anyway (something I'm quite bullish about for Rust, in comparison).

Another example: the complaint about no reference arguments. The point of this is so you can't tell what function arguments might be mutated if you allow non-const reference function arguments whereas with pointers it's obvious. To be clear:

        foo(c); // could be pass by value or reference (const or non-const)
        foo(&c); // clearly mutable

I also believe the C++11 thing is outdated. Even when I still worked there some features were allowed from C++14 and some code was obviously going to be migrated to the C++14 equivalent once the issues with that were resolved (IIRC std::make_shared had an equivalent).

<comment><USER22> There's a very big C inherited footgun you can avoid with signed sizes: implicit conversions to unsigned on comparison.

<comment><USER17> GCC has had -Wsign-compare:

           -Wsign-compare
               Warn when a comparison between signed and unsigned values could
               produce an incorrect result when the signed value is converted to
               unsigned.  In C++, this warning is also enabled by -Wall.  In C, it
               is also enabled by -Wextra.

Since 1996. [https://github.com/gcc- mirror/gcc/commit/de9554eb8ae74764555...](https://github.com/gcc- mirror/gcc/commit/de9554eb8ae74764555178fc8bdf04cad9f3aa82)

(And prior to that explicit option, it was just enabled as part of -Wextra/-W, from 1995: [https://github.com/gcc- mirror/gcc/commit/7030c69607d547b3227...](https://github.com/gcc- mirror/gcc/commit/7030c69607d547b3227ad0aa3842bf7864c690f3) . For comparison, Google was founded in 1996.)

I buy that some of the integer promotion rules really suck, and Google's founders learned C prior to 1996. But the compiler has been able to warn us about this particular footgun for a _long_ time.

</comment></comment></comment><comment><USER41> Similar but unrelated topic... Does anyone have a good C style guide they like?

</comment><comment><USER42> Regarding the advice on globals, and the comments here regarding destructors, how does `constexpr` interact with RAII?

Are `constexpr` values destructed when they go out of scope? Or is it simply not possible to `constexpr` them?

<comment><USER43> constexpr variables must have a literal type, which requires a trivial destructor.

</comment></comment><comment><USER44> "Unnamed Namespaces and Static Variables GSG prohibits the use of static definitions and annonymous namespaces in header files. How else do we declare constants?"

A constant is not a static variable.

</comment><comment><USER45> If you find them no good then you haven't worked for a big company. These docs are standards are your complaints have been heard before and shaped the doc.

</comment><comment><USER46> The Python one is particularly offensive.

</comment><comment><USER47> _Laughs in gofmt_

</comment><comment><USER48> Does it work for them?

<comment><USER49> Yes; it enables tens of thousands of developers to work on a monorepo with billions of lines of code across over a billion files and generally be able to move between parts of that codebase without surprises. It promotes re-use, and simplifies refactoring useful utilities from one-shots into general libraries.

Speaking for myself as an engineer who works in that codebase, I rarely find it gets in my way, and when I've felt exceptions were the clearest/best approach, I've not found it burdensome or difficult to justify them.

</comment></comment><comment><USER50> Google's

</comment><comment><USER51> > The #define Guard. GSG prefers #ifndef/#define idiom over the simpler > #pragma once. Yes, #pragma once is non-standard but widely supported.

What? I cannot read more after this.</comment>


Google's secret interview process - <AUTHOR> http://www.businessinsider.com/i-was-invited-by-google-to-its-secret-interview-process-2015-8 <comment><USER2> Leaking secret company recruitment policy, fire him! :-)</comment>


Mandelbrot set - zoom x1e185 - <AUTHOR> http://fractaljourney.blogspot.com.es/

<comment><AUTHOR> How is this king of simulation handled numerically? This is out of the scope of floating points..</comment>


Tesla P85D – 3,5s acceleration and autopilot demo - <AUTHOR> https://www.youtube.com/watch?v=lgTDQGGigjc

<comment><USER2> No comments? The video is only 93 second long, so it's easy to watch.

The car does 0-60 in 3.6 seconds with 3 people on board. That's impressive.

I'd think owning a Tesla would be an "aspirational goal" here on HN. I know that if I were in a startup and got a 7-figure exit from being acquired or acqui-hired, this car would be high on my list of toys to buy.</comment>


In Hong Kong Protests, Faces Become Weapons - <AUTHOR> https://www.nytimes.com/2019/07/26/technology/hong-kong-protests-facial-recognition-surveillance.html <comment><USER2> Just a heads up - the US gov't has complete access to your iphone with the fusion centers and such. They do not need to you to unlock your phone.

If you are participating in a protest and are afraid you will end up on a list, just leave your cellphone home and cover your face up. The US gov't are not above using the same tactics as the chinese e.g. going after you where you work and breaking into your home etc.</comment>


The Number of New Bitcoin Accounts Is Skyrocketing - <AUTHOR> https://www.bloomberg.com/news/articles/2017-11-27/new-crypto-accounts-proliferate-as-bitcoin-flirts-with-10-000 <comment><USER2> At what point does it become speculation? Perhaps someone with more knowledge can shed some light on what exactly people are buying when they buy a bitcoin.</comment>


Show HN: WhipUps - A Faster, Simpler Blogging Platform - <AUTHOR> https://www.whipups.com/

<comment><AUTHOR> Hey HN, creator here. If you have any questions or feedback let me know!</comment>


Arduino Burglar Alarm Sends SMS - <AUTHOR> https://github.com/mattwilliamson/arduino-sms-alarm <comment><USER2> This is really cool. I've actually been working on something really similar.

Early last year, we built a a breadboard with a Teensy microcontroller (instead of an Arduino) to decode signals from off-the-shelf door and window sensors. At the time, we had to reverse engineer the protocol using a oscilloscope. :) The breadboard was tethered to an Android device, which was the brain of the system (and this let us do other cool stuff, like video, networking etc).

We're much further along now (with working prototype units). If you're interesting in this kind of thing, we ARE hiring. :) (<http://elarm.com>)

</comment><comment><USER3> Both an Elk M1: [http://www.elkproducts.com/product-catalog/m1-gold-cross- pla...](http://www.elkproducts.com/product-catalog/m1-gold-cross-platform- control) and a HAI Omni:[http://www.homeauto.com/Products/HAISystems/OmniPro2/omnipro...](http://www.homeauto.com/Products/HAISystems/OmniPro2/omnipro2_tech.asp) can do this via email and can call your cell phone and speak the alarm to you and are UL listed fire/burglar system as well as fully programmable automation controllers.

They cost significantly more (about as much as a decent PC) but I would not trust my property or life to anything less honestly. My Omni has been running without reboot for years and does security/fire/hvac/irrigation/lighting/garage door control and has an iPhone app for control.

</comment><comment><USER4> I know it's "just" an arduino talking to another PC .. but after doing some drilling, soldering, glueing, screwing and general arduino-ing myself ( <http://www.youtube.com/watch?v=N9Rj-NegE6E> ) well done on actually getting something designed, done and "ready". If you inspire one person to pick up an arduino then that's compliment enough !

</comment><comment><USER5> I have been told that Burglar alarms that send SMS alerts are vulnerable to blocking devices. These are allegedly available on ebay and are already being used for this purpose.

<comment><USER6> This isn't sending SMS over the radio network, it's hitting TelAPI over (presumably) the land line. A jammer would prevent the reception of the SMS at the site, which wouldn't harm this application because the whole point is that the owner is not present and needs an alarm.

It is, however, vulnerable to the outrageous latency problems (minutes, often) the unofficial messaging gateways have. I send my wife texts to her company blackberry because it's convenient, but ultimately had to duplicate them to her gmail address to ensure that she got them fast enough.

<comment><AUTHOR> You're right there about the jammer. But in testing, it hasn't taken more than 20 seconds so far.

</comment></comment></comment><comment><USER7> I know a lot of people like the Arduino Uno but IMHO the Nano has a better layout. Bread board friendly with the same ATMega328 as the Uno.

Nice job aimatt. Good learning project.

</comment><comment><USER8> Really cool. It reminds me of a project my brother-in-law did to receive an SMS when the Ph levels in his salt water aquarium change.

</comment><comment><USER9> I built something similar. I used a PCEngines Alix (x86, 5w, $100ish) and the serial port on my home security system. Fun stuff!

</comment><comment><USER10> This seems to need a computer to actually send the SMS. Would've been far more flexible to buy a cheap AT GSM modem.

<comment><AUTHOR> But a lot more expensive

<comment> excuse-me Does anyone know of a cheap and simple SMS only GSM modem?

All the ones I have used were expensive industrial spec units with complex data channels.

<comment><USER11> Huawei GTM900

Has serial port which takes AT commands. Easy enough to drive it.

Costs $20 a shot.

<comment><USER12> Have you tried one of these out? Where can you buy one?

<comment><USER11> <http://www.rfsolutions.co.uk/acatalog/RFS_GSM_Modules.html>

I have tried out. Well documented and you can get the breakout boards for $5 but I forget precisely where. Managed to get it working in UK on O2 pay as you go. Now in junk box :(

Watch out - you need a level shifter if you're using an Arduino or something as it has 3v3 operation. I used an old(er than me) HP lab PSU and a crudely hacked up set of BC548 switches as a level shifter. You need an antenna and a sim socket (my sim was cruely soldered onto 1/0.2 solid wire and plugged into the breakout board header).

</comment></comment></comment></comment></comment></comment><comment><USER13> Anyone know a good source to get Arduino stuff (sensors, boards, etc.) in the USA?

<comment><USER14> Adafruit, Sparkfun, Pololu, Seeed Studios, Leaf Labs Also see Mouser, Digikey, Allied, et al <http://leaflabs.com/distributors/> Radio Shack carries Arduino now, some do anyway. My personal favorite is Adafruit because this one time, I whined to her about her webform not accepting my firstname.lastname@example.com and she fixed it and wrote me back in like five minutes, no joke. I do not know her personally and that was the first time I had ordered anything from her.

tl;dr Limor Fried is a bad ass, buy things from her store.

</comment></comment><comment><USER15> So what's the total cost?

\- What's the cheapest Arduino board that would work with this sensor? Wouldn't it be cheaper to get a Raspberry Pi?

\- How much is the power supply?

\- It would also be cool if there was a way to send SMS over the regular wireless, like with one of those cheap emergency cell phone plans. That would make it a really nice alarm, no need for the internet, and it can work off a PSU even if burglars shut down the power/internet.

<comment><USER16> He shows it on a teensy, which if you're decent with a soldering iron can be done for as little as $16 + shipping. power supply is usb so no extra cost there. not sure how well talking to a phone would do directly but worth checking into.

<comment><AUTHOR> That's right on the money, but technically I'm using a nano. Any Arduino will work though. There are knockoff Arduinos out there too, but I like to give back to the Arduino organization by buying an official board.</comment></comment></comment>


Ask HN: Denied Individual Health Insurance, Now What? - <AUTHOR>

I have applied to two health insurance companies, both denied me and have ruined my plans for starting my company. Currently dealing with a stable but chronic auto-immune disease. Any advice for picking up insurance besides a full time position? <comment><USER2> Too late for this query, but for anyone else, I've read that when you apply for individual health insurance you should do it with all of your candidate companies at once so that you can truthfully say "I have not been denied" to as many companies as possible.

I think you'll be able to get some kind of health insurance in 2014 when Obama-care kicks in. Maybe work a job just until then? You might be able to work/start/research your own company in the meantime, and you'll be free to "build one to throw away."

You might talk to all the health insurance brokers you can find. Small companies with health insurance might lead you to them. Also talk to your life/auto/home insurance broker, they might point you to options.

EDIT: Is there an association, and/or forums or other groups for you condition? They may have found ways to get insurance. Does your condition have some sort of government fallback support?

</comment><comment><USER3> Are you starting your company solo or with a co-founder? If you have a co- founder then your new company can purchase group health insurance. If solo, then there are a few states(I forget off the top of my head which) where solo person companies can purchase group coverage.

<comment><USER4> And just to add: you can't be denied for coverage in a group plan (AFAIK)

</comment></comment><comment><USER5> If you are in the US and currently employed with a group health plan, COBRA will cover you for 18 months after you leave. You pay the full cost, so it's not cheap, but it's there. You have to elect to do this within 60 days of leaving I think.

This might tide you over until Obama-care helps you.

You could get a group plan through your new company as well. I'm not sure what the minimums are, but there are benefits administration companies you can talk to about it.</comment>


Amazon data center on fire in Virginia - <AUTHOR> http://finance.yahoo.com/news/amazon-data-center-fire-virginia-180300909.html

<comment><USER2> Fortunately, nobody was hurt and this won't affect AWS.

> A large fire lit up the roof of an Amazon data center that's still under > construction in a Virginia suburb outside Washington, D.C.

> No one was hurt in the blaze, according to the local fire department, which > was able to put out the fire in under an hour.</comment>


The McMansion Scale, Explained - <AUTHOR> http://www.mcmansionhell.com/post/151896249151/the-mcmansion-scale-explained <comment><USER2> This article is best juxtaposed with articles about image synthesis:

* Wave Function Collapse image generator [https://github.com/mxgmn/WaveFunctionCollapse](https://github.com/mxgmn/WaveFunctionCollapse)

* Image Synthesis from Yahoo's open_nsfw: [https://open_nsfw.gitlab.io](https://open_nsfw.gitlab.io)

* Generative Adversarial Text to Image Synthesis: [https://arxiv.org/abs/1605.05396](https://arxiv.org/abs/1605.05396)

Put another way, when I look at the McMansions at 10 on the scale, it looks to me like the kind of output you get when you just feed a bunch of pictures of houses into a neural network without feeding in any of the cultural or aesthetic context. Things like the large garages and roofs look like the efforts of constraint solvers working with inputs that are out of bounds.

In a sense, that is exactly what happened.

<comment><USER3> Coming from an art background, I tend to think of those as Cubist in nature, like a Picasso painting. You see just one roof, but from many different perspectives, making it look like many roofs.

<comment><USER4> I like the Picasso reference. The line between art and "a bunch of crap put together" is sometime difficult to pin down. And it takes a Picasso to navigate that boundary without stepping over.

<comment><USER3> Cascading gables are _totally_ Cubist in nature. It's a gable partly obscured by a smaller version of itself! And a gable is itself sort of a simplified outline of a house plastered onto an actual house.

</comment></comment></comment></comment><comment><USER5> I was recently struck by this house, offered by Sears in 1921:

[https://oklahomahousesbymail.files.wordpress.com/2012/10/sea...](https://oklahomahousesbymail.files.wordpress.com/2012/10/sears- saratoga-1921.jpg)

What's crazy is the price: $47,085.20 in todays dollars. This is with all finishing materials (including stained glass) & delivered (no cement or bricks).

It's an amazing house, and any old schlub could order it from good ol' Sears.

Something very bad happened in architecture around world war 2.

<comment><USER6> > What's crazy is the price: $47,085.20 in todays dollars.

You're not crazy. Houses really were more affordable for your grandparents. The same with mine.

Today for I or you to purchase the same thing would cost many multiples. At lowest I'd say 150k, but most likely 350 and in what the middle class today euphemistically call a "good school distinct" it would be about over a million dollars.

So many educated people in 'modern days' have beliefs about the present and past which are in complete opposition to the facts.

> Something very bad happened in architecture around world war 2.

Thank you for noticing. The answer is literally a conspiracy against traditional building. I won't 'go on'. I'll demonstrate with images.

Here I'll insert a former comment I made related to this subject.

[http://farm4.staticflickr.com/3641/3546348607_d60d612554_z.j...](http://farm4.staticflickr.com/3641/3546348607_d60d612554_z.jpg)

The first thought that struck me when I saw it was "that is a visual expression of Orwellian thought".

Deep down a majority of people prefer to live in houses that look like this:

[http://media-cache- ec0.pinimg.com/736x/2e/40/a4/2e40a4bf4e33...](http://media-cache- ec0.pinimg.com/736x/2e/40/a4/2e40a4bf4e335a68f7c721cf622f7601.jpg)

[http://s0.geograph.org.uk/geophotos/02/74/71/2747107_896ab24...](http://s0.geograph.org.uk/geophotos/02/74/71/2747107_896ab244.jpg)

Do you remember the Shire in the Lord of the Rings? That is a synopsis of what people feel when they think of 'home'. Honest, humble but well crafted dwellings affordable by the average hobbit. As master Bilbo is keen to tell us:

"In a hole in the ground there lived a hobbit. Not a nasty, dirty, wet hole, filled with the ends of worms and an oozy smell, nor yet a dry, bare, sandy hole with nothing in it to sit down on or to eat: it was a hobbit-hole, and that means comfort."

Brutalism is quite obviously something that came out of Minas Morghul.

[https://i.ytimg.com/vi/enbLZaUyr3s/maxresdefault.jpg](https://i.ytimg.com/vi/enbLZaUyr3s/maxresdefault.jpg)

It is an architectural anti-thesis.

Mr Wtbob on HN made the most apropos remark that:

There is little more care for the inhabitants inside than there is for the ants, the ivy, the birds, the earthworms which could live on & around a homier structure. A Brutalist building spares no more thought for its inhabitants than does an abbatoir for those who enter its confines: they are a necessary nuisance, but mustn't be permitted to intrude upon the happiness of the architect anymore than absolutely required.

Brutalism is a kind of totalitarianism of architecture, a demand that those who build, those who inhabit and those who maintain must constantly bend their wills to the will of the Great Man (the architect), bend without love, without understanding, without hope, without fear, without joy, just mute, abject obedience to a cold and uncaring plan.

No thanks. Give me ivy, give me bricks, give me marble, give me dirt and grass and trees; give me men and women and children; give me sheep and dogs and horses; give me colours and light and ornament; give me emotion and delight; give me, in short, life.

It's clear to internaut and probably wtbob, that so called modern architecture is actually an attempt to erase the past, which is all the more amazing because all the users _want_ traditional architecture to be built.

When all the end users want one thing, and most of the designers are wanting another thing we have to seriously ask what is doing on.

Of course it's not just architecture, it's in the art world too and the music world.

Nothing remarkable has come out of those for many decades now. The public is unable to name a 'masterwork' from those fields of endeavor.

<comment><USER5> I'm sorry to see you get down voted, but I share your sentiments and agree that it was something that could be reasonably called a conspiracy. Unfortunately it has become part of the intellectual furniture of left-wing ideology, which makes a lot of otherwise perfectly nice people support extremely inhumane building patterns.

Some books on the topic that I have read, if you haven't are:

[https://www.amazon.com/Bauhaus-Our-House-Tom- Wolfe/dp/031242...](https://www.amazon.com/Bauhaus-Our-House-Tom- Wolfe/dp/0312429142)

[https://www.amazon.com/Old-Way-Seeing-Architecture- Magic/dp/...](https://www.amazon.com/Old-Way-Seeing-Architecture- Magic/dp/0395605733/ref=sr_1_1?s=books&ie=UTF8&qid=1477025600&sr=1-1&keywords=the+old+way+of+seeing)

[https://www.amazon.com/Geography-Nowhere-Americas-Man- Made-L...](https://www.amazon.com/Geography-Nowhere-Americas-Man-Made- Landscape/dp/0671888250/ref=sr_1_1?s=books&ie=UTF8&qid=1477025615&sr=1-1&keywords=the+geography+of+nowhere)

A funny side story: I realized I was some sort of reactionary my freshman year at Berkeley, when I was standing in the memorial glade, swinging my gaze back and forth between Doe Memorial Library and Evans Hall.

<comment><USER7> It always makes me feel like one of those "I wish I lived in the past!! The present sucks!" people but IMO arts, architecture, city planning, and aesthetics went downhill after WWII. I'm not sure why or how but that's how I feel.

</comment></comment></comment></comment><comment><USER8> I'm not sold on this. Some of the criticisms levied seem valid, and there's /some/ sensibility to the scale -- but the whole thing smacks of a post-hoc attempt to define why McMansions are in poor taste in non-socioeconomic terms. It's sufficient to just say "McMansions are tremendously wasteful symptoms of American decadence" \-- but that might be psychologically hard if you've spent years in architecture school learning how to design status symbols for the upper classes.

<comment><USER9> Architecture has rules of composition like any other craft. McMansions shit all over them. There's nothing post-hoc about calling them shit. A McMansion only look sensible and aesthetically pleasing if you try to imagine one as a well designed house covered in tumors.

The fact that they are an example of American decadence stems from the fact that they are cargo culting opulence.

<comment><USER10> "McMansions shit all over them."

How is it any of your business?

The people who buy them like them. _Their tastes are not yours_ , and they're the ones paying the bills.

<comment><USER9> It's my business in the sense that I can have an opinion about how ugly their house is and I do. There's nothing more to it. It's not like I think McMansions should be illegal because they are ugly, although I don't see what's fundamentally unjust about a community not wanting eyesores in their neighborhoods if enough McMansion haters congregated in one place. There are other reasons why they suck that a sibling comment mentioned.

I don't believe just because aesthetics involve personal preferences that we can't discuss them and come to common conclusions regarding the good and the bad. Aesthetics are very important to me as a programmer, for example, and I am an unhappy programmer if I cannot write pretty code for whatever reason. I certainly wouldn't want to be a programmer if I couldn't write pretty code as often as I do. Crunch time hurts me twice: the extra work, but also the resource constraints that mean I have to satisfy beauty in code. If I didn't care about what is beautiful and what is not, I would feel like a very flat person. If that makes me an asshole then, well, I mean I wouldn't disagree.

</comment></comment></comment></comment><comment><USER11> Thanks for sharing this blog.

She is funny, and this is putting words to feelings I've had. That said, what she constitutes as negative, 'McMansion' traits largely seem to be based on how she feels about the house as a whole.

[http://www.mcmansionhell.com/post/149284377161/mansionvsmcma...](http://www.mcmansionhell.com/post/149284377161/mansionvsmcmansion?is_related_post=1)

>Mansion vs McMansion

Immediately you'll notice the 'mansion' has a faux balcony, useless pillars and void throwup; all traits she claims to despise.

Scroll down to the example of a New Traditional house (which is a beautiful house) and it's clearly a house that, in her terms, has no concept of mass; it's all roof!

I get what she's saying, but still. She should at least be consistent with the individual traits she dislikes.

<comment><USER12> Design and architecture aren't matters of opinion – "disliking roofs" isn't a thing and is not her point. Combinations of various features lead to different dynamics, which can be beneficial or harmful to the overall appearance or impression given by the object.

So when she says the house is "all roof," it's not that she dislikes roofs in general; it's that the roof dwarfs the rest of the house, making it look small and insignificant. Imagine wearing too large of a suit, or putting your TV in front a movie theater screen.

<comment><USER13> The thing with roofs is that if you get substantial snowfall in winter, practicality demands a steep roof pitch, otherwise melted snow will drip through the shingles. A high roof pitch necessary makes the roof more prominent.

From a reverse image search, the two "more roof than house" photos (both in the 8 section) seem to be from Sandy Spring, Maryland and Gaithersburg, Maryland.

In general, the author seems to think that builders should place more value on architectural merit rather than practicality, maintainability and cost. Obviously most homebuyers don't share her priorities.

<comment><USER14> I moved to Norway a few years ago. The average roof pitch is more than when I lived in Indiana. However, the roofs generally don't seem that much more prominent than in Indiana. Many are simply proportional - even in the more mass produced housing of the 50's.

Examples: [https://www.google.no/search?q=typical+norwegian+house&safe=...](https://www.google.no/search?q=typical+norwegian+house&safe=off&tbm=isch&tbo=u&source=univ&sa=X&ved=0ahUKEwiY29mthezPAhXya5oKHWaLANIQsAQIJQ&biw=1382&bih=771)

<comment><USER13> I notice that they're all gable roofs, compared to the hip roofs which the author criticizes. Gable roofs usually look less prominent, since there's less surface area, and it's usually on the sides which you don't see as much as the front of the house. But I think hip roofs are better in harsh environments, partly because they're more stable, and partly because the maximum wall height is shorter, so it takes stronger winds to blow water onto the siding.

Are snowstorms and rainstorms not a big concern in Norway? I looked at some weather data and it sounds like certain parts are quite rainy, but less so in the major cities like Oslo, and with less storms than Maryland. Is that accurate?

<comment><USER14> I'll give the best account this immigrant can give: The weather does vary depending on where you are at. Norway is long - Nearly like the east coast if you take off Florida and Maine. The span and geography makes for somewhat varied whether. A decent swath is above the arctic circle: Much of Norway is thin save for the southern 1/3, which has a wider land mass and therefore, a chunk that is more inland. Oslo shares similar whether with such places, though it isn't as inland (the fjords can make 'inland' a weird thing). Much of the country is mountainous as well. Due to the large coastline, the country gets rainy along the coast, much like the west coast in the US and Canada.

Storms are a weird thing for me here. I don't consider much here a "storm", but I'm from Indiana where a storm meant possible tornado weather. Storms where I am - Trondheim - have heavy rain or snow and a fair amount of wind. As in, as an adult, wind has pushed me along on ice. Many are remnants of hurricanes, and the truth is they seem fairly mild. Even lightning and thunder are somewhat rare - I kinda get excited because I miss a good thunderstorm.

</comment></comment></comment></comment></comment></comment><comment><USER15> There's a long history of this problem. Bletchley Park Manor House[1] meets most of the criteria listed for a 9th or 10th level McMansion. Three or more window styles. Turrets. Bad columns. Faux balcony. Patchwork masonry. Roofline soup. Oversized pediments. Oversized transoms. House is out of scale.

They avoided the two-story entrance. It's not big enough for one.

(I visited before it became a big-time museum, and had a guide who was more into the architecture than the cryptanalysis.)

[1] [https://upload.wikimedia.org/wikipedia/commons/8/82/Bletchle...](https://upload.wikimedia.org/wikipedia/commons/8/82/Bletchley_Park_- _Draco2008.jpg)

<comment><USER16> An even older example: Palacio da Pena, Sintra, Portugal

[http://www.neverendingvoyage.com/the-fairytale-palaces-of- si...](http://www.neverendingvoyage.com/the-fairytale-palaces-of-sintra-a- photo-essay/)

<comment><USER17> But...that's old.

It's almost inevitable that old buildings evolve in strange ways. According to the wikipedia article, it was a monastery, cathedral, and palace. Parts were hit by lightning and rebuilt; I'm sure others also needed repairs from other disasters, wear-and-tear, and changing usage.

The fact that an old building ends up like that doesn't mean that new buildings should _start_ looking like that. Imagine if someone said "this legacy code is an absolute mess, so this new project can be a spaghetti-coded disaster too!".

</comment></comment></comment><comment><USER18> I love this article as social commentary. I grew up in McMansion hell--the DC suburbs. My parents live in a McMansion. The architectural critiques capture not only what I hate about these houses, but about the attitudes of many people here. They have a general air of being better than the rest of the country by virtue of education and an upper middle class income. They're intensely image conscious but don't have exposure to real wealth, so they buy and build houses with features like fake windows. They're bad with money: Median household income in Great Fall VA is about $200k, while the median house price is about $1 million. The owners of most of these McMansions are extremely leveraged.

<comment><USER19> Did you grow up in the McMansion? Were the schools mostly kids that came from these upper-middle class families? I'm curious because I flip back and forth between wanting a good school district for my kids and wanting to expose them to a little more socioeconomic diversity. Just curious your thoughts on growing up in that type of area, particularly around education and socializing with other kids.

<comment><USER18> I moved from Vienna (at the time probably middle class rather than upper middle class) to Mclean (solidly upper middle class, with some rich people). Mclean schools were full of upper middle class kids. The high school parking lot had Lexus/BMW. Lot of smart kids and many who went on to be pretty successful, but also a lot of arrogance and disdain for "the south," "the rest of Virginia," and "flyover country." The attitude was such that I didn't even realize Chicago (a huge city not on the coasts) existed until I was in college.

I can't say I noticed any difference in the schools. Mclean had great test scores, but that's because it has managed to zone out almost all the middle and lower-income people and the working class immigrants. My wife and I have been struggling with where to send our daughter to school. I don't think it's worth it pay a big premium to buy in the higher-ranked school districts. Unless the district has an actual gang problem, it's generic "McEducation" almost everywhere. If our daughter shows tendencies of being a creative thinker we'll likely do private for at least high school. If she shows a high tolerance for petty tyranny we'll likely do public somewhere in Anne Arundel (which is close to DC but far enough away where she might meet some blue collar people).

<comment><USER20> Kids didn't know that Chicago existed? I don't know how to respond

<comment><USER21> I went to a pretty lower-class high school in Brooklyn, NY (lots of kids from Bed-Stuy, Bushwick, etc. before gentrification). There's a prevailing attitude that if it's not in NYC, it's not worth knowing about. I'm not surprised to hear of a well-off kid in a DC school not knowing about Chicago existing.

</comment></comment></comment></comment></comment><comment><USER22> The hate for attached garages.. Doesn't the author realize how incredibly useful, and unsightly, they are at the same time? I have a rented garage a half block away in the city, and a basement full of all my random projects, that I would only dream of being able to stick in a garage next to my house.

<comment><USER23> I have a detached garage facing the alley behind my house. It's about the best possible arrangement for a garage, imho.

<comment><USER24> No necessarily better: if I picture your example correctly, there is a lot of space wasted as road (alley).

<comment><USER25> Alleys "waste" about five feet at the back of everyone's lot, and they are very useful. In a sense, alleys and sidewalks are what differentiate civilization from everywhere else people choose to live.

</comment></comment></comment></comment><comment><USER26> Fun, but I'd find this information more useful if juxtaposed with an analysis of the livability and practicality of the various McMansion species. After all, a person spends a lot more time inhabiting the home as opposed to looking at it, so ultimately the inside is a lot more important than the outside. As a few people already noted, attached garages may be generally ugly but they're useful. Can one say the same about multistorey windows and entryways, lots of dormers, large columns, random multiple window styles, etc.? Do these things add aesthetic or practical value to the house for the people actually residing in them? Or are they mere eyecandy for tasteless consumers but in the end add nothing to the enjoyment of daily living.

<comment><USER27> Individual house dissection do go into detail about how the outside is reflected on the inside, to bad effects.

See this one for example: [http://www.mcmansionhell.com/post/149128564511/mclean- virgin...](http://www.mcmansionhell.com/post/149128564511/mclean-virginia)

It's even more chaotic on the inside than on the outside. The Homer Simpson car without wheels.

</comment></comment><comment><USER28> As a Brit, I'm struck by the size of almost all of those houses; so much money deployed in the service of so little taste. Of course, we're not safe from it either in the UK, but usually on a smaller scale of cheap apartments and faux- Tudor suburbs.

<comment><USER29> I was thinking the same as someone living in London. What do people do with all this space?

<comment><USER14> I both understand your sentiment - as I think there is a spot of "This house is too big for my spouse and I" (we live in a fairly small attic apartment even by Norwegian standards), but I also understand what we'd do with space.

We would have an extra room: We might have seperate sleeping quarters because my snoring wakes him. We (well, more he) would have a room for music - We have a couple of electric guitars, a bass, and an electric cello. We (me!) would have an art space. A guest room would be wonderful if family flies from overseas. We'd have a library. That's 5 bedrooms, or alternate uses of a basement or attic in a smaller 2-3 bedroom house.

I think a lot of folks simply have unused space in these, however. My parents lived in a 3600 sq ft, 6 bedroom, multiple bathroom house (build in the 1860's and renovated later on to include a garage and basement finishing) - and if it wasn't for opening their house to family or friends down on luck, it would have gone mostly unused.

</comment></comment></comment><comment><USER30> I'd like to see a similar blog for the terrible "modern" homes currently being built.

Count the exterior materials! Cinder blocks, fake artisanal barnwood, neon- green door, neon-orange corrugated metal, exposed concrete, yellow windows, reclaimed shipping container...

<comment><USER6> In particular anybody who reclaims a shipping container has not done the math. It's an idea that sounds good or affordable but it takes a lot of money and expertise to make that work properly even if the container was free. It would make considerably more sense to acquire a large cardboard box.

<comment><USER31> Never mind making it work properly, just slap them together as per [http://www.examiner.com.au/story/380795/one-mans- container-i...](http://www.examiner.com.au/story/380795/one-mans-container-is- another-mans-home/)

<comment><USER6> If you are not concerned with the difficulty of running plumbing/electric, you still have thermal bridging through steel at 400 times the conductivity of wood. The people who use steel framing often thermally isolate thin strips of metal, not the entire wall. The insulation job the guy says he hasn't done yet, he's going to find out he'll need to insert a cavity air gap. If he chooses to stick it with a gap as external sheathing to save space he'll still need to contend with condensation on this very conductive surface. If he goes for passive house level air tightness and internal smart vapour barrier he could be fine but somehow I think he's just winging it which means water vapour will condense inside his house and not be able to dry out. Hello mildew and everything he owns will rot. You can build with shipping containers, but you've got to really know what you're doing.

tldr; A guy spent 50k+ to put his house inside a heatsink. This looks environmentally friendly but with the probable dehumidifier requirements it is probably much worse than regular building.

<comment><USER31> Indeed! I kinda meant "just slap them together and to hell with the consequences", probably should have written that.

I recently bought a house, built in 1964 needs some maintenance but generally okay. Has a heat pump. The idea of buying land a little way out of town and constructing my own dwelling using reclaimed materials crossed my mind a lot. Fortunately I work in the structural steel fabrication industry, so I've got enough building experience to be dangerous, but the wisdom to know better.

We're at 41 degrees south, old mate in the article I linked is a bit closer to the bottom of the mountains, so probably cops a bit more of the cold air drifting down the snow caps. When it's been -4 degrees every morning for a week in the middle of winter going to work with cold steel is finger-snapping. I wonder how they make it through the winters. Probably crawl up inside their refrigerator where it's warmer.

<comment><USER6> > Indeed! I kinda meant "just slap them together and to hell with the > consequences"

I think he proceeded with that plan, I looked up some other photos of that build. He nailed some tarp with the containers into a kind of gable roof. I try to be as positive and constructive as possible with people's projects but sometimes it is very clear there exists a species of person who never had the thought "huh, maybe I should google that" or "this must have been done before, I wonder what best practice is". I suppose there's something to be said for being fearless.

> The idea of buying land a little way out of town and constructing my own > dwelling using reclaimed materials crossed my mind a lot.

I've said before that you can theoretically reclaim an entire house if you have enough time and employ your own labour. That is commendable, especially if you're stuck with few opportunities to work for money, but it is not the easiest path. You'll need a place to store large items secure from thieves and rain/sun.

> When it's been -4 degrees every morning for a week in the middle of winter > going to work with cold steel is finger-snapping. I wonder how they make it > through the winters. Probably crawl up inside their refrigerator where it's > warmer.

I've been soaked to the skin with water in winter so I know how that feels. They'll just spend a fortune on electricity. In their place I might have buried the containers to alleviate the temperature change. There is also a nice new/old technology called PCM - phase change material which would allow you to average out the temperature shifts from night to day by storing thermal energy like a battery. It releases heat from the walls when the temp drops and basically acts as artificial thin thermal mass. I think it's an Ozzie company too that does it.

</comment></comment></comment></comment></comment></comment><comment><USER19> A lot of this McMansion stuff has trickled down into smaller homes, in the 2000-3000 square foot range. I think the term is neo-eclectic. Multiple roof lines, no two windows looking the same, lacking symmetry, front-facing three car garages, three or four different types of materials on the outside (siding, shake shingle, brick, etc.). These houses also suffer the same fate as many McMansions, where the house takes up a massive amount of the lot and you get houses stacked on top of each other with very small backyards[1].

Almost all of the new houses I see being built are using this style. I'm looking into building a house and in my area and it's impossible to find a builder advertising their plans online who don't use this style. So if you want to deviate from this style of house, you have to start working with an architect to draw something up or try and find your own house plans. I'm not saying this is a terrible burden, just that it's hard to get something more traditional "off the shelf", so to speak, and many people building a house don't want to go through that much of a process.

I'm looking to build my house a rural lot in the 5-10 acre range, so fitting into neighborhood aesthetics isn't that crucial to me, but many places people build, it's going to look ridiculous to place a traditional cape cod amongst all the neo-eclectic stuff.

[1] Small backyards and closely built houses work well in city neighborhoods but seem to be in conflict with why many people move to the suburbs -- to have more space. I'm not sure the desire to live in such compact lots. Certainly the developers like the small lots because they can squeeze more houses onto the acres their developing on. However, I'm probably an exception because people build these types houses on these types of lots in troves.

<comment> nommm-nommm >A lot of this McMansion stuff has trickled down into smaller homes, in the 2000-3000 square foot range.

Oh, god, yes. My well off but not rich (high 5 figures, low six figures) friends are buying these. They are pouring a ton of their wealth/income into these pseudo-prestigious things. It's strange to watch.

<comment><USER19> I wonder what the resale value on these houses will be. In the areas these are built around me, housing prices aren't skyrocketing, so if you built and had to sell within a few years, you're probably going to take a loss unless the market changes substantially. However, these places likely have a 20-25 year lifespan for the original owners as kids are born, raised, go off to college, and then start their own lives.

There's going to be a glut of these things out there that someone needs to buy. Everyone wants new things, so why would people in 20-30 years have demands for a house that was "stylish" 20-30 years ago? I'm only in my 30's, so maybe I'm just ignorant of housing construction cycles, but it my social group, I see a lot of these things being built.

That's another reason why I want to build something more traditional -- to hopefully stand out from the pack when I eventually go to sell.

</comment></comment></comment><comment><USER32> This is architectural trollery unleashed on the innocent masses, the kind of information that just makes homeowners feel bad about their property but does little to change things. The mcmansionshell crusade is analogous to developers publically complaining (trolling) about perfectly functional, stable source code that isn't as idiomatic as it could be. Unlike real property, source code is a hell of a lot easier and more likely to be improved when the criticism is compelling. Homeowners, on the other hand, won't upgrade. They literally have to just "live with it".

<comment> Jean-Philipe I think you missed where she points out non-aestetical flaws of those McMansions, like cheap materials, water damage, covered-up measuring mistakes, wasted space.

<comment><USER32> yes I did

</comment></comment></comment><comment><USER33> Perhaps this is a good thread to ask: Does anyone have book recommendations about how and why houses are built? For example, this blog talks about siding (EIFS, vinyl, stucco), but I'd like to learn how these are made, relative costs, how they respond to different climates, how they're actually constructed etc. I'd like to learn about all different aspects of houses, for example, why are foundations just poured concrete, vs using stone? What are the advantages of brick vs stone, etc.

<comment><USER28> [http://diy.stackexchange.com/](http://diy.stackexchange.com/) might be a good place for those questions.

Stone is expensive, hard to transport, and difficult to shape. Concrete is stone you can pour, although you need to keep water away from the embedded steel reinforcement.

UK houses tend to be brick and US wood due to relative costs in those countries.

<comment><USER34> /r/homeimprovement on reddit can have some bright spots too.

As a general note, house construction varies a _lot_ throughout the US due to the climate variances.

E.g. someone moving to the bay area from the midwest is going to find the insulation in houses there comical. Here in Colorado we have almost no vinyl siding (because of the increased UV exposure, I presume), and mold is less of a concern than elsewhere. Full basements are the norm in the midwest, but rare in Texas and nearly impossible in Florida.

</comment></comment></comment><comment><USER34> Any valid critiques the author may have are completely lost in the contempt and pretentiousness of her writing style.

Additionally, I am incredibly skeptical of her ability to judge the quality of a house's construction based on a single exterior photo.

<comment><USER35> Come on. It's entertainment. Like [http://www.peopleofwalmart.com](http://www.peopleofwalmart.com) it's a lighthearted laugh at people with zero taste.

Or, to put it in terms HN will get: Do a code review of really bad unnecessarily-complicated code. It's hard to NOT think things like: "Jeez, this person doesn't know what they're doing." and "This code is confusing and ugly, but the writer probably thinks it's elegant." McMansion design is like someone throwing every design pattern that exists into their code because someone told them once that design patterns are good.

<comment><USER36> Wow, never heard of POWM before but that's one hateful piece of "entertainment" if I've ever seen one.

The entire entertainment value seems to be based on publicly shaming people. I have no idea how you can consider this "lighthearted". That's 4chan level misanthropy right there.

<comment><USER37> There's been a shift in American humor, and others have noted, due to the class division probably; we used to laugh with each other, or maybe laugh together _at_ the authorities, but now we are laughing _at each other_ , or better put, we are laughing at _them._

Here's a recent illustrative Saturday Night Live sketch: [https://www.youtube.com/watch?v=8WytdYtzyZg](https://www.youtube.com/watch?v=8WytdYtzyZg)

</comment></comment></comment></comment><comment><USER38> Interestingly the higher the number the more I like the house.

The low number ones are boring and plain. The high number ones are interesting to live in.

<comment><USER39> I hear there's an ancient Chinese curse about living in interesting-something- or-other. I don't _think_ it was houses, but I bet they'd have adjusted it if they'd seen these.

<comment><USER40> [https://en.wikipedia.org/wiki/May_you_live_in_interesting_ti...](https://en.wikipedia.org/wiki/May_you_live_in_interesting_times)

</comment></comment></comment><comment><USER41> As an european who has never visited the US, I'm totally unfamiliar with this kind of buildings, other than seeing them in TV Shows like Family Matters or Full House. Also, almost every single american woodworking YouTube channel is recorded in a garage of one this kind of houses. I find them huge, yet their popularity makes me think they're pretty common, maybe even affordable?

<comment><USER42> I wonder how are the houses in some places in Germany, for example? They also love their cars and have real winters...

<comment><USER36> The average German lives in an apartment or multi-family house.

On the country side there are still a lot of fully detached houses but they're either mostly "old" (i.e. built or fully renovated after the war) or built to a different standard (Germans generally consider drywall a cheap substitute). But of course that is also changing.

Also, building your own house is not as affordable as it seems to be in the US. Germans have a stronger aversion to taking out loans and banks often want a significant down payment.

From what I've seen few home owners actually park their cars in garages though. Recently carports (basically sunroofs) have become pretty popular but most people seem to park their cars in the driveway as far as I can tell. We just clean them more often, I guess.

<comment><USER43> what kind of multi-family house? Side by Side duplex? Up down duplex? Quadplex? Something else?

<comment><USER44> I don't know what the averages are, but I'd say in towns the most typical are terraced houses with four or five floors - sometimes that's one apartment on each floor, sometimes two.

</comment></comment></comment></comment></comment><comment><USER45> There is a great podcast released a few days ago by 99% invisible interviewing the creator of the site: [http://99percentinvisible.org/episode/mcmansion- hell-devil-d...](http://99percentinvisible.org/episode/mcmansion-hell-devil- details)

</comment><comment><USER25> Incidentally, I find TFA to exemplify a "McWebsite". The interesting primary content is totally dominated by the massive "More You Might Like" footer with four more _entire_ McMansion articles sandwiched in together, including all original images and graphics. Meanwhile Chrome is pegging at 500k for this one page. Lose the four-car garage please!

</comment><comment><USER46> The author rightfully hates on pre-lawsuit EIFS, but I know it's improved quite a bit.

Does anyone know how good EIFS is these days? As far as a quick Google tells me, post-lawsuit EIFS is a magical building material from the gods that can quite literally withstand hurricanes and missiles [0] but I imagine reality is a bit more nuanced than that.

[0] [http://www.architectmagazine.com/technology/products/revisit...](http://www.architectmagazine.com/technology/products/revisiting- eifs-the-once-maligned-cladding-system-that-may-help-architects-meet-new- energy-codes_o)

</comment><comment><USER25> I'm not surprised to see the higher end of the scale feature lots of oversized eave returns. I am surprised TFA doesn't mention this everyday horror of ostentatious suburban living. A classical eave return is _only_ appropriate when of classical dimensions.

</comment><comment><USER47> dupe of a dupe: [https://news.ycombinator.com/item?id=12754592](https://news.ycombinator.com/item?id=12754592)

[https://www.youtube.com/watch?v=pRtVMLwh6mY](https://www.youtube.com/watch?v=pRtVMLwh6mY)

</comment><comment><USER48> Every time this site come up on yc, I I always have the same impression... I like what the guy is trying to do to improve architecture, but it just seems so mean spirited in execution.

<comment><USER49> *girl ([http://99percentinvisible.org/episode/mcmansion-hell-devil-d...](http://99percentinvisible.org/episode/mcmansion-hell-devil-details/))

It's mean but well deserved.

</comment></comment><comment><USER50> Reminds me of Yelp reviews that slam a restaurant for its decor and don't mention the quality of the food.

<comment><USER51> She does talk about quality of materials in other posts in addition to the failure to use / design / construct with those cheaper materials.

She's a hysterical writer. Highly recommend poking around her site for a bit. She's changed the way I look at real estate.

</comment></comment><comment><USER52> So tiny houses and large mansions are the same on this scale? What does the author think mansion means?

<comment><USER53> The scale is supposed to be a scale of the quality of the design.

Neither tiny houses or well-designed mansions qualify as 'McMansions'.

<comment><USER52> The quality is only the "Mc" part of "McMansion" though. and Mansion implies large house.

Edit:

> Neither tiny houses or well-designed mansions qualify as 'McMansions'.

Yet they're on the McMansion scale.

<comment><USER54> It establishes a baseline as a frame of reference.

</comment></comment></comment></comment><comment><USER55> It's really bad when people idiotically think they should be able to put the house they want on their own property. What a bunch of tools.

<comment><USER53> Where does the author advocate banning terrible houses?

She's just explaining the features and design ideas that make this kind of architecture so distasteful - not telling anyone what to do...

<comment><USER56> She also frequently points out that "McMansion" homes often have design problems that make them unpleasant to live in, like:

\- Use of cheap materials, like vinyl siding and EIFS, which are likely to fail early and require expensive repairs.

\- Poorly conceived interior spaces. Rooms that are awkwardly shaped or placed, which are impossible to furnish sensibly, or which simply have no purpose but to fill space. "Grand entrances" are a frequent offender here. These aren't just ugly; they make the house uncomfortable to live in.

<comment><USER57> > _Use of cheap materials, like vinyl siding and EIFS, which are likely to > fail early and require expensive repairs._

I was under the impression that EIFS was a good system. Is that not true?

<comment><USER56> EIFS is great _if_ it's done properly. It can be leaky if designed/installed improperly, though, and it's difficult to repair.

<comment><USER25> I've had good results with EIFS on commercial buildings. In fact if you look around you'll find most new commercial buildings in USA are EIFS, usually with one or two accent materials like CMUs or steel. I don't really like the look of EIFS on most houses, although it probably works for "southwestern"-style houses that mimic adobe construction, and I'd love to see a medieval half- timbered house using EIFS.

I don't agree with TFA's complaint about what it's calling EIFS "seams". First of all properly-installed EIFS doesn't have seams; in the picture those are simply decorative details. It would have been less work not to include them. If they hadn't been included, the tiny windows would have really menaced the neighborhood with their empty soulless stares. If TFA's favored flavors of "modernism" reject simple details like these, it has to come up with _something_ to replace them, because giant blank walls just doesn't work.

EIFS is not alone in not dealing well with moisture when installed incorrectly. I have seen improperly installed vinyl siding, for instance, result in _horrific_ water damage in a _short_ period of time. If you're going to own the results for any amount of time, you must watch your contractors like a hawk. Reasonably-priced contractors will fuck you every time; the goal is to get fucked in relatively painless fashion. Having to replace entire walls is painful, even if insurance covers it.</comment></comment></comment></comment></comment></comment>


There's an Advertising Revolution brewing in India - <AUTHOR> https://campad.in/service-93b2525c21c6 <comment><AUTHOR> I'm the founder of CampAd. AMA!

We are targeting startups only at the moment, but we do have plans to partner with all kinds of brands.</comment>


Cinemagraph's experiments with animated photos - <AUTHOR> http://cinemagraphs.com/ <comment><USER2> How does this actually work?

They're diff-ing the images and only acknowledging significant changes throughout sequence? Or is it just manual?

It works perfectly.</comment>