Wednesday, April 29, 2015

Test for Good Software Design (C++ precompiled headers are an excuse)

Here is a great and simple test for good C++ design.
If you have to add a header file for a new class or structure to one module, does it cause many other unrelated C++ files to be recompiled?
You had to add the header include to another header that is included by lots of .cpp files.
Precompiled headers are used as an excuse for bad design.

Good Software Design

1) Use standard C++ code, as few Macros and Globals as possible.
2) As few dependencies between modules as possible. Modules should be as self contained as possible.  Less dependencies on the platform the better, depend on standard C++ only as much as possible.

Wednesday, April 8, 2015

Conventions, Change, Uniformity, Potential

When I look at software I see potential for change, for improvement, (even if just mine, inside of me, my own understanding).
Stifling creativity.  Uniformity makes it easier to see (transparent) but also opaque to potential to change.
Conventions create the illusion of solidity but the solidity is apparent, but not real, to it's potential for reinterpretation and redesign.
Uniformity and conventionality.
I'm not stubborn, perhaps ignorant.  But the idea that (they) cannot go in and fix my code when (they) have a better idea to demonstrate what (they) feel is needed, or right, is a little odd to me, and hard to accept, and - what's the word, humiliating? hyper pedagogical? self important?
Perhaps (they) are just trying to be pedagogical and I over-react.
I can get emotional sometimes, that's another of my faults, (but even that's open to interpretation).