4 ms·

I fear even reading this. Back in 2010, I read the c++faq religiously, tried to warp my projects to it in college, and in the end produced nothing because i wa

I fear even reading this. Back in 2010, I read the c++faq religiously, tried to warp my projects to it in college, and in the end produced nothing because i was too busy trying to be a big boy. Now, the c++faq is obsolete. I'm generally tired of opinionated lists of "best practices," code that actually works is 10x better than what some guy (always a guy) somewhere thinks I should do whereas in fact what I should do is actually build things that I can use. Caveat (big one) okay, it's not "some guy", the authors are literally Bjarne Stroustrup & Herb Sutter. I still feel anxiety though.

jcelerier 4y ago
> I fear even reading this. you don't necessarily have to read it. Many of the guidelines are implemented as checks in clang, for me the ones I find relevant and enabled show up inline when I write code in my IDE.
simplotek 4y ago
> Back in 2010, I read the c++faq religiously, tried to warp my projects to it in college, and in the end produced nothing because i was too busy trying to be a big boy. You're just admitting to having created your own problem, and suffering consequences for it. Nothing in your comment pertains any issue with reading coding guidelines in general or specifically the C++ ones, let alone any comment in particular. > Now, the c++faq is obsolete. That's your personal assertion, and one that does not sound informed at all. I keep track of the C++ coding guidelines. In general they are nice rules of thumb. No one wants to build a religion around them.
- noobermin 4y ago
  >No one wants to build a religion around them. The phenomenon literally has a wikipedia page describing it[0]. That's a lot of people to describe as "no one." [0] https://en.wikipedia.org/wiki/Cargo_cult_programming https://en.wikipedia.org/wiki/Cargo_cult_programming
  - simplotek 4y ago
    Cargo cult programming has zero to do with religion or what features ship and do not ship with a standard library. Please read the wiki page you're trying to quote before quoting it.
kllrnohj 4y ago
You should probably read it before ranting against it assuming you already know the general gist of what it says. Or at least read the introduction on what the rules are trying to be and, just as importantly, what they are not trying to be. The authors of those guidelines are Bjarne Stroustrup & Herb Sutter, who kinda have more than average C++ experience. The guidelines are generally very well reasoned with motivating examples & practical exceptions to the rules. They are generally not of the opinionated "style guide" or "ban these things" camp that a typical set of "guidelines" tends to fall into. I think the only CppCoreGuideline rule I disagree with is it wants to use T& for out params whereas I prefer T* so that at the call site there's a more obvious indicator of potential mutability.
- distcs 4y ago
  The very first guideline is Month month() const; // do int month(); // don't I know I am in the outlier here but I very much prefer the second way of writing code. Sure the first one gives more compile-time safety but as someone who has to read the code, I have to go through an additional level of indirection before I truly understand how Month is implemented. Others might offer a counterpoint that hiding such implementation details is exactly the point of OOP. True but as a developer who has to read and fix code, I do have to worry about the implementation details because the bugs could be in implementation details and hiding simple integers behind an extra layer of types adds to one more step when I am trying to reach the implementation details and fix bugs there. Multiply this experience by the number of all the layers in the code and maybe others might be able to appreciate why I prefer the second type of coding. Please someone tell me I am not the only one who feels this way!
  - sqeaky 4y ago
    It doesn't need to be about OOP and hiding details, this seems like basic type safety. Both of these are member functions and are hiding details already, so OOP is an aside, you would need invest effort reading on both or neither if there are robust unit test that solid OOP would enable. With ints as months is 0 or 1 January? What about -1 and 13, do they have sensible meaning? You need to re-apply that effort constantly to any int that might be a month. This isn't a hidden implementation this is an easy mistake waiting to happen. Using a month enum solves this, and you are not fixing bugs in the implementation of an enum unless you are a compiler developer. Same with const, it prevents accidental changes to the class from this member function. It allows more sensible code and compiler optimizations. The "do" line will almost always be faster than the "don't" line. There is no way adding const changes the amount of effort for a reader in a negative way.

jcelerier 4y ago

> I fear even reading this. you don't necessarily have to read it. Many of the guidelines are implemented as checks in clang, for me the ones I find relevant and enabled show up inline when I write code in my IDE.

simplotek 4y ago

> Back in 2010, I read the c++faq religiously, tried to warp my projects to it in college, and in the end produced nothing because i was too busy trying to be a big boy. You're just admitting to having created your own problem, and suffering consequences for it. Nothing in your comment pertains any issue with reading coding guidelines in general or specifically the C++ ones, let alone any comment in particular. > Now, the c++faq is obsolete. That's your personal assertion, and one that does not sound informed at all. I keep track of the C++ coding guidelines. In general they are nice rules of thumb. No one wants to build a religion around them.

noobermin 4y ago
>No one wants to build a religion around them. The phenomenon literally has a wikipedia page describing it[0]. That's a lot of people to describe as "no one." [0] https://en.wikipedia.org/wiki/Cargo_cult_programming https://en.wikipedia.org/wiki/Cargo_cult_programming
- simplotek 4y ago
  Cargo cult programming has zero to do with religion or what features ship and do not ship with a standard library. Please read the wiki page you're trying to quote before quoting it.

kllrnohj 4y ago

You should probably read it before ranting against it assuming you already know the general gist of what it says. Or at least read the introduction on what the rules are trying to be and, just as importantly, what they are not trying to be. The authors of those guidelines are Bjarne Stroustrup & Herb Sutter, who kinda have more than average C++ experience. The guidelines are generally very well reasoned with motivating examples & practical exceptions to the rules. They are generally not of the opinionated "style guide" or "ban these things" camp that a typical set of "guidelines" tends to fall into. I think the only CppCoreGuideline rule I disagree with is it wants to use T& for out params whereas I prefer T* so that at the call site there's a more obvious indicator of potential mutability.

distcs 4y ago
The very first guideline is Month month() const; // do int month(); // don't I know I am in the outlier here but I very much prefer the second way of writing code. Sure the first one gives more compile-time safety but as someone who has to read the code, I have to go through an additional level of indirection before I truly understand how Month is implemented. Others might offer a counterpoint that hiding such implementation details is exactly the point of OOP. True but as a developer who has to read and fix code, I do have to worry about the implementation details because the bugs could be in implementation details and hiding simple integers behind an extra layer of types adds to one more step when I am trying to reach the implementation details and fix bugs there. Multiply this experience by the number of all the layers in the code and maybe others might be able to appreciate why I prefer the second type of coding. Please someone tell me I am not the only one who feels this way!
- sqeaky 4y ago
  It doesn't need to be about OOP and hiding details, this seems like basic type safety. Both of these are member functions and are hiding details already, so OOP is an aside, you would need invest effort reading on both or neither if there are robust unit test that solid OOP would enable. With ints as months is 0 or 1 January? What about -1 and 13, do they have sensible meaning? You need to re-apply that effort constantly to any int that might be a month. This isn't a hidden implementation this is an easy mistake waiting to happen. Using a month enum solves this, and you are not fixing bugs in the implementation of an enum unless you are a compiler developer. Same with const, it prevents accidental changes to the class from this member function. It allows more sensible code and compiler optimizations. The "do" line will almost always be faster than the "don't" line. There is no way adding const changes the amount of effort for a reader in a negative way.