This is the mail archive of the gdb@sourceware.org mailing list for the GDB project.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
Other format: | [Raw text] |
But to be fair, the coding standards we already impose don't usually have quantifiable benefits. In fact your argument could be used against any kind of abstraction in the code (how do you prove that the target stack is advantageous over some other design?), or against the adding of comments (can you demonstrate that any particular comment block is helping any other developers?).From: Vladimir Prus <vladimir@codesourcery.com> Date: Wed, 30 Jul 2008 11:18:09 +0400
Unless we can answer this question, refactoring and rewriting isAnd here, you also surely know what is generally goal of refactoring --
simply waste of resources, nothing less, nothing more.
to make code simpler and more amendable for future change.
No, refactoring always has some specific goal. Only given a specific
goal, can one weigh the alternatives -- one to keep existing design
and code and change it, the other to refactor it and then extend the
result. You need to have a clear goal so that you could balance
advantages against disadvantages. Without a goal, all you have is
disadvantages (the overhead and effort of refactoring), because
advantages cannot be estimated without a specific goal in sight. How
do you estimate an advantage of ``making code simpler and more
amenable to change''? You can't.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |