5 ms·

Creating objects in “empty” states is lazy programming. The point of references is to guarantee an object exists. But don’t pretend an object exists just to sat

Creating objects in “empty” states is lazy programming. The point of references is to guarantee an object exists. But don’t pretend an object exists just to satisfy the reference. Rethink your code to take advantage of the guarantee.

quotemstr 9y ago
You've illustrated why I'm against the kind of simplistic programming maxims you'll find in "Effective X" books. It's easy to brand certain syntactic constructs as "bad", but unless you teach people good taste (which is fiendishly difficult to learn), all you do by telling people to avoid certain easily-recognizable syntactic patterns is to get them to come up with new horrors.
- notduncansmith 9y ago
  As GP said, rethink the code, from as far out as you need to. Granted, much code has been written under the explicit constraint of not doing this. In that case, do the nasty thing and then if it matters that much to you, find somewhere else to work that cares a similar amount about producing maintainable software.
- leni536 9y ago
  > You've illustrated why I'm against the kind of simplistic programming maxims you'll find in "Effective X" books. Another thing you won't find in this book is the C++ Gospel, the One True Path to perfect C++ software. Each of the Items in this book provides guidance on how to develop better designs, how to avoid common problems, or how to achieve greater efficiency, but none of the Items is universally applicable. ... If you follow all the guidelines all the time, you are unlikely to fall into the most common traps surrounding C++, but guidelines, by their nature, have exceptions. That's why each Item has an explanation. The explanations are the most important part of the book. Scott Meyers - Effective C++ The problem is not "Effective X" books. The problems is people treating these rules in these books as dogma.
  - jstimpfle 9y ago
    Not following a dogma pretty consistently in a single code base (or part of a very large codebase) very quickly leads to inconsistent code and bikeshed style of decision making.
    - marcosdumay 9y ago
      That, or it could lead to well architected code that changes according to its requirements. YMMV. The one thing that does never work is blindly following dogma.
  - quotemstr 9y ago
    > The problem is not "Effective X" books. The problems is people treating these rules in these books as dogma. You put a bunch of stuff in a book and people are going to copy the stuff from the book into their programs. Bits of front-matter don't matter. Consider the GoF book and the havoc that mindless repetition of design patterns creates.
    - marcosdumay 9y ago
      Still the problem is the people working mindlessly, not the books. The alternative would be to not ever improve our knowledge.
jstimpfle 9y ago
Just a reminder that there are many people who prefer not to think in objects. Rant: Personally since working on my game engine in C, my architecture has become so much simpler, I can easily avoid unnecessecary allocations. My code is much more coherent. Aspect-oriented - which is not at all OO spirit, since OO encourages (trying) to bundle things in self-contained packages. Yes, that seems hard to believe, since there is so much bad C code out there. With allocations, strings, file system operations etc. all over the place, just as in typical OO code. (Of course some things are really hard to do in C vs C++. The point is forcing myself to have a good architecture and avoid having to make many meaningless decisions).
- plesn 9y ago
  Could you provide more precisions / examples of this C code-style ?
  - jstimpfle 9y ago
    I wrote a huge ranty reply, but deleted it because it leads OT. Basically, read up on the link to ECS in the sibling comment. Also, definitely check out "Data-oriented design". There's a talk by Mike Acton on Youtube. "Where there's one, there's many" is a pretty basic but super important insight. I consider this to be important to code maintainability at least as much as to performance.
- quotemstr 9y ago
  The game engine people have the right idea with their entity-component-system [1] model. Essentially, it models the program as a big relational database instead of a graph of objects. It can work pretty well. [1] https://en.wikipedia.org/wiki/Entity%E2%80%93component%E2%80%93system https://en.wikipedia.org/wiki/Entity%E2%80%93component%E2%80...

quotemstr 9y ago

You've illustrated why I'm against the kind of simplistic programming maxims you'll find in "Effective X" books. It's easy to brand certain syntactic constructs as "bad", but unless you teach people good taste (which is fiendishly difficult to learn), all you do by telling people to avoid certain easily-recognizable syntactic patterns is to get them to come up with new horrors.

notduncansmith 9y ago
As GP said, rethink the code, from as far out as you need to. Granted, much code has been written under the explicit constraint of not doing this. In that case, do the nasty thing and then if it matters that much to you, find somewhere else to work that cares a similar amount about producing maintainable software.
leni536 9y ago
> You've illustrated why I'm against the kind of simplistic programming maxims you'll find in "Effective X" books. Another thing you won't find in this book is the C++ Gospel, the One True Path to perfect C++ software. Each of the Items in this book provides guidance on how to develop better designs, how to avoid common problems, or how to achieve greater efficiency, but none of the Items is universally applicable. ... If you follow all the guidelines all the time, you are unlikely to fall into the most common traps surrounding C++, but guidelines, by their nature, have exceptions. That's why each Item has an explanation. The explanations are the most important part of the book. Scott Meyers - Effective C++ The problem is not "Effective X" books. The problems is people treating these rules in these books as dogma.
- jstimpfle 9y ago
  Not following a dogma pretty consistently in a single code base (or part of a very large codebase) very quickly leads to inconsistent code and bikeshed style of decision making.
  - marcosdumay 9y ago
    That, or it could lead to well architected code that changes according to its requirements. YMMV. The one thing that does never work is blindly following dogma.
- quotemstr 9y ago
  > The problem is not "Effective X" books. The problems is people treating these rules in these books as dogma. You put a bunch of stuff in a book and people are going to copy the stuff from the book into their programs. Bits of front-matter don't matter. Consider the GoF book and the havoc that mindless repetition of design patterns creates.
  - marcosdumay 9y ago
    Still the problem is the people working mindlessly, not the books. The alternative would be to not ever improve our knowledge.

jstimpfle 9y ago

Just a reminder that there are many people who prefer not to think in objects. Rant: Personally since working on my game engine in C, my architecture has become so much simpler, I can easily avoid unnecessecary allocations. My code is much more coherent. Aspect-oriented - which is not at all OO spirit, since OO encourages (trying) to bundle things in self-contained packages. Yes, that seems hard to believe, since there is so much bad C code out there. With allocations, strings, file system operations etc. all over the place, just as in typical OO code. (Of course some things are really hard to do in C vs C++. The point is forcing myself to have a good architecture and avoid having to make many meaningless decisions).

plesn 9y ago
Could you provide more precisions / examples of this C code-style ?
- jstimpfle 9y ago
  I wrote a huge ranty reply, but deleted it because it leads OT. Basically, read up on the link to ECS in the sibling comment. Also, definitely check out "Data-oriented design". There's a talk by Mike Acton on Youtube. "Where there's one, there's many" is a pretty basic but super important insight. I consider this to be important to code maintainability at least as much as to performance.
quotemstr 9y ago
The game engine people have the right idea with their entity-component-system [1] model. Essentially, it models the program as a big relational database instead of a graph of objects. It can work pretty well. [1] https://en.wikipedia.org/wiki/Entity%E2%80%93component%E2%80%93system https://en.wikipedia.org/wiki/Entity%E2%80%93component%E2%80...