W
William Stacey [C# MVP]
Agree. Some wise words:
- A protocol design is not complete when there is nothing left to add, it is
complete when there is nothing left to remove.
- Any one can make something complicated, what is hard is to make it simple.
--
William Stacey [C# MVP]
| Remeber Creative Writing 101 in college? I'm sure your instructor told
you
| to write your story and then go back and cut it to about 25% of the words
you
| started with.
|
| The same applies to code though the percentages get better, just as in
| writing, when we've learned by cutting out code so much that we write less
| code that we will just have to remove later.
|
| Dale
| --
| Dale Preston
| MCAD C#
| MCSE, MCDBA
|
|
| "William Stacey [C# MVP]" wrote:
|
| >
Good one. I have felt this pain recently. Another reason to just
do a
| > very thin skeleton first and get basic things working to test your
design
| > and shake out many things you did not think about - resist random stream
of
| > thought and the temptation to add more function then minimal (surely we
| > never do that
. The hard problems (e.g. concurrency, atomic, etc) are
| > much harder to see and debug with all the junk in the way. When it
feels
| > good, then add all those nice overloads and properties and keep unit
testing
| > along the way. Don't push a bad design and think you can "fix" it with
more
| > code.
| > MS had to do this with Vista. I think over million lines of code went
in
| > the basket. Hindsight says that was a great desision as they ended up
with
| > a better product.
| > --
| > William Stacey [C# MVP]
| >
| > | > | Hi Bruce,
| > |
| > | > The approach is the usual
| > | > one: create the best design you can, use the most appropriate data
| > | > structures you can, then run your program and find the trouble
spots,
| > | > and optimize those.
| > |
| > | And I'd just like to add that it's not unlikely you'll have to ditch
some,
| > or even most, of the
| > | design and start from scratch. When designing high-performance
systems
| > it's difficult to account
| > | for everything without prototyping first and running some tests.
| > |
| > | --
| > | Dave Sexton
| > |
| > | | > | >
| > | > xlar54 wrote:
| > | >> I've been going through the newsgroup, picking up best practices
and
| > | >> things not to do, as I think it helps to make a good programmer a
very
| > | >> good one. But rather than fishing, I figure that there are many
out
| > | >> there who are tired of fixing someone else's poorly written code as
it
| > | >> relates to best practices, architecture, security and such. So to
the
| > | >> group, if you had to post a list of "never ever do this..." or
"always
| > | >> do this..." what would that include? We all know there's many ways
to
| > | >> do something, but some ways are clearly not good solutions. My
| > | >> expectations here is that I will learn quite a bit as will everyone
| > | >> else. Thanks for your replies.
| > | >
| > | > Number one on my list of foolish things to do in any language is "a
| > | > priori" micro-optimization. By that I mean spending hours (or even
| > | > minutes) tweaking your code to "improve its speed" before you've
| > | > determined that it's slow (and what, exactly, is slow) and needs
some
| > | > help. Even then, the solution is usually at a higher level: in the
| > | > design, in the choice of data structures or things like that.
| > | >
| > | > Of course, it's perfectly legitimate to prefer some constructs over
| > | > others if experience has taught you that they're more efficient.
| > | >
| > | > As well, there are areas of computing, and types of problems, that
| > | > require screaming tight code. Even in these areas, however, it's a
| > | > fool's game to optimize every line of code. The approach is the
usual
| > | > one: create the best design you can, use the most appropriate data
| > | > structures you can, then run your program and find the trouble
spots,
| > | > and optimize those.
| > | >
| > | > So many people post in this newsgroup, asking whether classes or
| > | > structs are "more efficient," or stressing over the cost of boxing,
| > | > when in fact they haven't started writing their app yet. (The recent
| > | > discussion on boxing overhead excepted: the OP already had a working
| > | > app in another language and had a specific question.) So many
newbies
| > | > think that the way to write good code is to torture and twist the
| > | > language to "make it fast" while at the same time they create
painfully
| > | > bad designs that introduce massive overhead that code tweaking can't
| > | > begin to address.
| > | >
| > | > The dumbest "optimization" I've ever seen was this (in C)... I quote
it
| > | > complete with comment:
| > | >
| > | > // Unwind loop to save clock cycles incrementing loop counter
| > | > int a[10];
| > | > a[0] = 1000;
| > | > a[1] = 1000;
| > | > ...
| > | > a[7] = 1000;
| > | > a[8] = 1000;
| > | > a[9] = 1000;
| > | >
| > | > Not only was this in the initialization phase of the program (so it
| > | > would occur exactly once per program run) but the rest of the
program
| > | > then built a SQL query and headed off to a database to pull in a few
| > | > thousand rows of data. This guy shaved a few microseconds off a
program
| > | > that ran for five minutes.
| > | >
| > |
| > |
| >
| >
| >
- A protocol design is not complete when there is nothing left to add, it is
complete when there is nothing left to remove.
- Any one can make something complicated, what is hard is to make it simple.
--
William Stacey [C# MVP]
| Remeber Creative Writing 101 in college? I'm sure your instructor told
you
| to write your story and then go back and cut it to about 25% of the words
you
| started with.
|
| The same applies to code though the percentages get better, just as in
| writing, when we've learned by cutting out code so much that we write less
| code that we will just have to remove later.
|
| Dale
| --
| Dale Preston
| MCAD C#
| MCSE, MCDBA
|
|
| "William Stacey [C# MVP]" wrote:
|
| >
Good one. I have felt this pain recently. Another reason to justdo a
| > very thin skeleton first and get basic things working to test your
design
| > and shake out many things you did not think about - resist random stream
of
| > thought and the temptation to add more function then minimal (surely we
| > never do that
. The hard problems (e.g. concurrency, atomic, etc) are| > much harder to see and debug with all the junk in the way. When it
feels
| > good, then add all those nice overloads and properties and keep unit
testing
| > along the way. Don't push a bad design and think you can "fix" it with
more
| > code.
| > MS had to do this with Vista. I think over million lines of code went
in
| > the basket. Hindsight says that was a great desision as they ended up
with
| > a better product.
| > --
| > William Stacey [C# MVP]
| >
| > | > | Hi Bruce,
| > |
| > | > The approach is the usual
| > | > one: create the best design you can, use the most appropriate data
| > | > structures you can, then run your program and find the trouble
spots,
| > | > and optimize those.
| > |
| > | And I'd just like to add that it's not unlikely you'll have to ditch
some,
| > or even most, of the
| > | design and start from scratch. When designing high-performance
systems
| > it's difficult to account
| > | for everything without prototyping first and running some tests.
| > |
| > | --
| > | Dave Sexton
| > |
| > | | > | >
| > | > xlar54 wrote:
| > | >> I've been going through the newsgroup, picking up best practices
and
| > | >> things not to do, as I think it helps to make a good programmer a
very
| > | >> good one. But rather than fishing, I figure that there are many
out
| > | >> there who are tired of fixing someone else's poorly written code as
it
| > | >> relates to best practices, architecture, security and such. So to
the
| > | >> group, if you had to post a list of "never ever do this..." or
"always
| > | >> do this..." what would that include? We all know there's many ways
to
| > | >> do something, but some ways are clearly not good solutions. My
| > | >> expectations here is that I will learn quite a bit as will everyone
| > | >> else. Thanks for your replies.
| > | >
| > | > Number one on my list of foolish things to do in any language is "a
| > | > priori" micro-optimization. By that I mean spending hours (or even
| > | > minutes) tweaking your code to "improve its speed" before you've
| > | > determined that it's slow (and what, exactly, is slow) and needs
some
| > | > help. Even then, the solution is usually at a higher level: in the
| > | > design, in the choice of data structures or things like that.
| > | >
| > | > Of course, it's perfectly legitimate to prefer some constructs over
| > | > others if experience has taught you that they're more efficient.
| > | >
| > | > As well, there are areas of computing, and types of problems, that
| > | > require screaming tight code. Even in these areas, however, it's a
| > | > fool's game to optimize every line of code. The approach is the
usual
| > | > one: create the best design you can, use the most appropriate data
| > | > structures you can, then run your program and find the trouble
spots,
| > | > and optimize those.
| > | >
| > | > So many people post in this newsgroup, asking whether classes or
| > | > structs are "more efficient," or stressing over the cost of boxing,
| > | > when in fact they haven't started writing their app yet. (The recent
| > | > discussion on boxing overhead excepted: the OP already had a working
| > | > app in another language and had a specific question.) So many
newbies
| > | > think that the way to write good code is to torture and twist the
| > | > language to "make it fast" while at the same time they create
painfully
| > | > bad designs that introduce massive overhead that code tweaking can't
| > | > begin to address.
| > | >
| > | > The dumbest "optimization" I've ever seen was this (in C)... I quote
it
| > | > complete with comment:
| > | >
| > | > // Unwind loop to save clock cycles incrementing loop counter
| > | > int a[10];
| > | > a[0] = 1000;
| > | > a[1] = 1000;
| > | > ...
| > | > a[7] = 1000;
| > | > a[8] = 1000;
| > | > a[9] = 1000;
| > | >
| > | > Not only was this in the initialization phase of the program (so it
| > | > would occur exactly once per program run) but the rest of the
program
| > | > then built a SQL query and headed off to a database to pull in a few
| > | > thousand rows of data. This guy shaved a few microseconds off a
program
| > | > that ran for five minutes.
| > | >
| > |
| > |
| >
| >
| >