| Topic: |
DEVELOP > c-Plus-Plus |
| User: |
"" |
| Date: |
31 Aug 2007 01:05:17 AM |
| Object: |
Coding Standards |
'Good code' is code that works, is bug free, and is readable and
maintainable. Standards need to be followed for coding. Read more...
http://brsx.co.uk/SWtesting/FAQs/FAQs012.asp
.
|
|
| User: "osmium" |
|
| Title: Re: Coding Standards |
31 Aug 2007 08:37:42 AM |
|
|
<davidsamith@gmail.com> wrote:
'Good code' is code that works, is bug free, and is readable and
maintainable. Standards need to be followed for coding. Read more...
http://brsx.co.uk/SWtesting/FAQs/FAQs012.asp
An American would have called those "guidelines", not standards. It is not
too bad for a one page description by *one* person, i.e., his biases
preferences and so on. If almost anyone else were to come up with a one
page summary it would be different. For example, I don't think many would
advocate the use of flow charts.
Just take it with a grain of salt, I think the point was that some people
overuse operator overloading, it is a fairly new, attractive toy.
.
|
|
|
|
| User: "H" |
|
| Title: Re: Coding Standards |
31 Aug 2007 02:24:27 AM |
|
|
wrote:
'Good code' is code that works, is bug free, and is readable and
maintainable. Standards need to be followed for coding. Read more...
http://brsx.co.uk/SWtesting/FAQs/FAQs012.asp
This says to increase maintainability, we should minimise operator
overloading. I'm new at this and confused, I thought operator
overloading (used correctly) aided maintainability and readability?!??
.
|
|
|
| User: "Phlip" |
|
| Title: Re: Coding Standards |
31 Aug 2007 07:33:59 AM |
|
|
http://www.softwareqatest.com/qatfaq1.html
This says to increase maintainability, we should minimise operator
overloading. I'm new at this and confused, I thought operator overloading
(used correctly) aided maintainability and readability?!??
Use sets of overloaded operators, together as a kit, to provide minimal,
clear, and expressive statements that unify their behavior and submit to
templates.
The page then wanders on with the spectacular assertion, "note that the Java
programming language eliminates multiple inheritance and operator
overloading". That means if you abuse your tool, we will take it away from
you! so you can't use it where it's needed. And we have all seen Java
programs with run-on statements suffering from a lack of operator
overloading and multiple inheritance of behavior.
The page also contains questionable advice, like "keep class methods small,
less than 50 lines", or "in adding comments, err on the side of too many
rather than too few comments..."
(For those of you just tuning in, class methods should be 1 to 5 lines, even
in C++, and every comment should be treated as a failed opportunity to add
self-documenting identifiers, assertions, or unit tests...)
--
Phlip
http://www.oreilly.com/catalog/9780596510657/
"Test Driven Ajax (on Rails)"
assert_xpath, assert_javascript, & assert_ajax
.
|
|
|
| User: "Jerry Coffin" |
|
| Title: Re: Coding Standards |
01 Sep 2007 06:42:46 PM |
|
|
In article <F7Cdnc-Fcu9fl0XbnZ2dnUVZ_hudnZ2d@adelphia.com>,
phlipcpp@yahoo.com says...
[ ... ]
(For those of you just tuning in, class methods should be 1 to 5 lines, even
in C++,
While this can sometimes be true, there are other times that trying to
break up a routine that's naturally large can result it it becoming less
readable and maintainable rather than more so.
and every comment should be treated as a failed opportunity to add
self-documenting identifiers, assertions, or unit tests...)
Only if you don't know what sort of comments to write. Comments should
generally be devoted to things like _why_ you did something -- e.g. why
it's important to have used a prime number for the size of this
particular array, or why it was important to use one sorting algorithm
instead of another.
These reasons are not reasonable to explain in identifiers, assertions,
unit tests, etc.
--
Later,
Jerry.
The universe is a figment of its own imagination.
.
|
|
|
| User: "Phlip" |
|
| Title: Re: Coding Standards |
01 Sep 2007 07:17:55 PM |
|
|
Jerry Coffin wrote:
(For those of you just tuning in, class methods should be 1 to 5 lines,
even
in C++,
While this can sometimes be true, there are other times that trying to
break up a routine that's naturally large can result it it becoming less
readable and maintainable rather than more so.
Consider the simple example of operator overloading. strcat(a,b) is more
wordy than a += b. Over a long method, such tiny simplifications rapidly add
up.
You don't bust such routines in half - that typically produces two
un-reusable methods with huge argument lists. You typically perform the
smallest narrowest refactors first - Introduce Temporary, or Extract Method.
When you can't, you stick the entire routine into a class as its single
method. That provide the same interface, so it's easy to retrofit. Then you
make every local variable into a class variable. This frees you to move all
the segments out into separate methods without wondering what to pass in or
return. The last time I did this, I could work the problem until all the
class variables went away.
And, ultimately, there's the Replace Algorithm Refactor, where you simply
rewrite the module, then move each client of the old module to use the
replacement, one by one.
There's always a way. And, yes, I know that advocating 5 line methods is a
little cruel to C++ coders, when all the Ruby and Smalltalk coders out there
routinely average 2 lines. Good C++ code can easily average < 10
_behavioral_ lines per method.
And, in any language, some methods are declarative, not procedural, such as
GUI declarations, so these can ramble on harmlessly...
and every comment should be treated as a failed opportunity to add
self-documenting identifiers, assertions, or unit tests...)
Only if you don't know what sort of comments to write.
Only if you don't know what sort of self-documenting identifiers,
assertions, or unit tests to write.
Comments should
generally be devoted to things like _why_ you did something -- e.g. why
it's important to have used a prime number for the size of this
particular array, or why it was important to use one sorting algorithm
instead of another.
Those are the exception to ordinary straight-forward coding. Another example
is "don't change this to 42 because something all the way over there will
blow". No matter how good our decoupling, we will always have that problem.
And another reason for cute comments is to automatically generate your API
documentation:
http://assertxpath.rubyforge.org/classes/AssertXPath.html#assert_hpricot
--
Phlip
http://www.oreilly.com/catalog/9780596510657/
"Test Driven Ajax (on Rails)"
assert_xpath, assert_javascript, & assert_ajax
.
|
|
|
| User: "Jerry Coffin" |
|
| Title: Re: Coding Standards |
02 Sep 2007 02:24:05 PM |
|
|
In article <v7SdnahfvuWinEfbnZ2dnUVZ_quhnZ2d@adelphia.com>,
phlipcpp@yahoo.com says...
Jerry Coffin wrote:
(For those of you just tuning in, class methods should be 1 to 5 lines,
even
in C++,
While this can sometimes be true, there are other times that trying to
break up a routine that's naturally large can result it it becoming less
readable and maintainable rather than more so.
[ ... ]
There's always a way. And, yes, I know that advocating 5 line methods is a
little cruel to C++ coders, when all the Ruby and Smalltalk coders out there
routinely average 2 lines. Good C++ code can easily average < 10
_behavioral_ lines per method.
This is pretty much a non-sequiter. Comparisons to Ruby and Smalltalk
are mostly irrelevant. Most Ruby (to use your example) is relatively
simple code -- mostly light duty processing on web servers. When you're
just not doing much, it's pretty easy to keep your routines short and
simple.
C++ is rarely used that way though, and no matter how you try to avoid
it, some things are sufficiently complex that you end up with at least a
few routines that can't reasonably be tiny. Yes, there's always a way to
break them up anyway -- but if you insist on doing so, you do a lot more
harm than good. You make the code less readable, less understandable and
less maintainable. That's clearly not a good thing to do.
And, in any language, some methods are declarative, not procedural, such as
GUI declarations, so these can ramble on harmlessly...
and every comment should be treated as a failed opportunity to add
self-documenting identifiers, assertions, or unit tests...)
Only if you don't know what sort of comments to write.
Only if you don't know what sort of self-documenting identifiers,
assertions, or unit tests to write.
Okay, show me how to write identifiers, assertions or unit tests that
show why it's important in a particular instance to use a stable sort.
Comments should
generally be devoted to things like _why_ you did something -- e.g. why
it's important to have used a prime number for the size of this
particular array, or why it was important to use one sorting algorithm
instead of another.
Those are the exception to ordinary straight-forward coding.
Maybe I'm just lucky, but I've managed to leave a lot of ordinary
straight-forward coding to others, and concentrated most of my time on
things I find challenging and interesting.
Another example
is "don't change this to 42 because something all the way over there will
blow". No matter how good our decoupling, we will always have that problem.
That doesn't sound like a problem I've had anytime recently anyway...
And another reason for cute comments is to automatically generate your API
documentation:
http://assertxpath.rubyforge.org/classes/AssertXPath.html#assert_hpricot
Yish. Over time I'm becoming ever more thoroughly convinced that these
automatically-generated docs are the scourge of programming. In nearly
every case, they concentrate on nonsense, and miss about 99% of what
docs should really cover.
All in all, your post impresses me as a result of a great deal more
enthusiasm for the "latest and greatest" trends than real experience.
Much of it also impresses me as being far more applicable to quite a bit
of web programming and such than to what I'd normally think of as
"real" programming, where "ordinary straight-forward coding" is
relatively rare and much of what you're doing is converting things from
pure research into a marketable product.
--
Later,
Jerry.
The universe is a figment of its own imagination.
.
|
|
|
|
|
| User: "James Kanze" |
|
| Title: Re: Coding Standards |
04 Sep 2007 05:42:35 PM |
|
|
On Sep 2, 1:42 am, Jerry Coffin <jcof...@taeus.com> wrote:
In article <F7Cdnc-Fcu9fl0XbnZ2dnUVZ_hudn...@adelphia.com>,
phlip...@yahoo.com says...
[ ... ]
(For those of you just tuning in, class methods should be 1
to 5 lines, even in C++,
While this can sometimes be true, there are other times that trying to
break up a routine that's naturally large can result it it becoming less
readable and maintainable rather than more so.
While 1 to 5 lines sounds a bit too strict, anytime a function
gets longer than about 10 lines, I start asking myself
questions. As always, however, there are exceptions: a single
switch with 100 cases, each of which is a single line, is not a
problem, and trying to break it into smaller functions is
definitly counter productive.
A more general rule for function complexity would involve levels
of nesting of control structures, or the number of different
paths through the function.
and every comment should be treated as a failed opportunity
to add self-documenting identifiers, assertions, or unit
tests...)
Only if you don't know what sort of comments to write.
Comments should generally be devoted to things like _why_ you
did something -- e.g. why it's important to have used a prime
number for the size of this particular array, or why it was
important to use one sorting algorithm instead of another.
I also find comments as to why you didn't do something to be
important: why you didn't use the obvious simple solution (which
maybe not so obviously doesn't work).
These reasons are not reasonable to explain in identifiers,
assertions, unit tests, etc.
More importantly, assertions and unit tests aren't part of the
documentation. Unit tests, in particular, should be reviewed
against the documentation, to ensure that all requirements and
limit cases are checked---unit tests without a requirements
specification (documentation) are meaningless.
--
James Kanze (GABI Software) email:james.ka...@gmail.com
Conseils en informatique orient=E9e objet/
Beratung in objektorientierter Datenverarbeitung
9 place S=E9mard, 78210 St.-Cyr-l'=C9cole, France, +33 (0)1 30 23 00 34
.
|
|
|
| User: "Jerry Coffin" |
|
| Title: Re: Coding Standards |
08 Sep 2007 11:15:11 AM |
|
|
In article <1188945755.913459.37840@y42g2000hsy.googlegroups.com>,
james.kanze@gmail.com says...
[ ... ]
While 1 to 5 lines sounds a bit too strict, anytime a function
gets longer than about 10 lines, I start asking myself
questions. As always, however, there are exceptions: a single
switch with 100 cases, each of which is a single line, is not a
problem, and trying to break it into smaller functions is
definitly counter productive.
I wonder if I'm the only one who pays little or no attention to the
length of a function per se. I get concerned about things like:
1) repetition of code
2) things that could be spun out into separate functions whose names
would clarify the code.
3) a routine with more than one real purpose
OTOH, I semi-frequently run into things that don't seem amenable to
particuarly short routines either. Some are things like filling out a
structure to interface with the OS -- e.g. under Windows, creating a
font or registering a window class requires you to fill out a structure
with 30 or so members -- so most of it is simple assignments, but you
still end up with 30+ lines of them. I see nothing to be gained by
attempting to break this up.
Likewise, a few things are simply sufficiently complex that they end up
somewhat long. Just for one example, consider the code to delete a node
from a red-black tree or an AVL tree. You can (and certainly should,
IMO) delegate things like 'rotate_right' to separate routines -- but
even after you do that, you end up with a routine that's 100 lines long
or so. I suppose you _could_ break it up into routines that are 5-10
lines long, but if there's a way to do so while keeping the code as
readable, I haven't found it yet.
[ ... ]
Only if you don't know what sort of comments to write.
Comments should generally be devoted to things like _why_ you
did something -- e.g. why it's important to have used a prime
number for the size of this particular array, or why it was
important to use one sorting algorithm instead of another.
I also find comments as to why you didn't do something to be
important: why you didn't use the obvious simple solution (which
maybe not so obviously doesn't work).
I think we're in agreement here. That was more or less the point of my
example about using one sorting algorithm instead of another -- i.e. why
use one thing when another would be a more obvious choice.
--
Later,
Jerry.
The universe is a figment of its own imagination.
.
|
|
|
| User: "James Kanze" |
|
| Title: Re: Coding Standards |
09 Sep 2007 03:54:13 PM |
|
|
On Sep 8, 6:15 pm, Jerry Coffin <jcof...@taeus.com> wrote:
In article <1188945755.913459.37...@y42g2000hsy.googlegroups.com>,
james.ka...@gmail.com says...
[ ... ]
While 1 to 5 lines sounds a bit too strict, anytime a function
gets longer than about 10 lines, I start asking myself
questions. As always, however, there are exceptions: a single
switch with 100 cases, each of which is a single line, is not a
problem, and trying to break it into smaller functions is
definitly counter productive.
I wonder if I'm the only one who pays little or no attention to the
length of a function per se.
It's a symptom. If I see a collegue systematically producing
functions of 20 lines or more, it makes me suspicious.`
I get concerned about things like:
1) repetition of code
2) things that could be spun out into separate functions whose names
would clarify the code.
3) a routine with more than one real purpose
Agreed. However, violating those principles frequently leads to
overly long functions. The function length is a symptom, and
it's easier to check mechanically.
OTOH, I semi-frequently run into things that don't seem amenable to
particuarly short routines either. Some are things like filling out a
structure to interface with the OS -- e.g. under Windows, creating a
font or registering a window class requires you to fill out a structure
with 30 or so members -- so most of it is simple assignments, but you
still end up with 30+ lines of them. I see nothing to be gained by
attempting to break this up.
If your point is that there are definite exceptions, I agree.
Another classical case is a simple switch with a lot of cases.
Likewise, a few things are simply sufficiently complex that they end up
somewhat long. Just for one example, consider the code to delete a node
from a red-black tree or an AVL tree. You can (and certainly should,
IMO) delegate things like 'rotate_right' to separate routines -- but
even after you do that, you end up with a routine that's 100 lines long
or so. I suppose you _could_ break it up into routines that are 5-10
lines long, but if there's a way to do so while keeping the code as
readable, I haven't found it yet.
Are you sure? I've never actually written such code, but the
examples I've seen in textbooks have lead me to believe that
it's only about 10 lines. I can't imagine anything consisting
of 100 lines of swapping pointers that would be understandable
by a mortal human being, regardless of whether it was in one
function or many.
--
James Kanze (GABI Software) email:james.kanze@gmail.com
Conseils en informatique orient=E9e objet/
Beratung in objektorientierter Datenverarbeitung
9 place S=E9mard, 78210 St.-Cyr-l'=C9cole, France, +33 (0)1 30 23 00 34
.
|
|
|
| User: "Jerry Coffin" |
|
| Title: Re: Coding Standards |
09 Sep 2007 07:16:55 PM |
|
|
In article <1189371253.276578.318050@w3g2000hsg.googlegroups.com>,
james.kanze@gmail.com says...
On Sep 8, 6:15 pm, Jerry Coffin <jcof...@taeus.com> wrote:
[ ... ]
I get concerned about things like:
1) repetition of code
2) things that could be spun out into separate functions whose names
would clarify the code.
3) a routine with more than one real purpose
Agreed. However, violating those principles frequently leads to
overly long functions. The function length is a symptom, and
it's easier to check mechanically.
Okay -- I can get along with that position quite easily.
[ ... ]
Are you sure? I've never actually written such code, but the
examples I've seen in textbooks have lead me to believe that
it's only about 10 lines. I can't imagine anything consisting
of 100 lines of swapping pointers that would be understandable
by a mortal human being, regardless of whether it was in one
function or many.
You don't have 100 lines of swapping pointers -- that would be truly
heinous. What you have is about 10 lines -- but a slightly different set
of 10 lines for each for something like 9 different cases. For an AVL
tree it's basically a cross product of three possibilities for balance
and three possibilities for node type (root, interior or leaf node). If
memory serves, R-B trees are even a bit more complex than that. The
basic idea is pretty similar though: a couple of nested if statements to
pick out the right case, and then a few lines of swapping pointers, and
then checking to see if you need to fix up the balance.
--
Later,
Jerry.
The universe is a figment of its own imagination.
.
|
|
|
|
|
|
| User: "Phlip" |
|
| Title: Re: Coding Standards |
04 Sep 2007 08:41:13 PM |
|
|
James Kanze wrote:
While 1 to 5 lines sounds a bit too strict
By way of inevitably violent agreement, 1 to 5 lines is not a rule, so it
can't be "strict". Frequent compliance is a good sign that more subtle
guidelines are working. Such as ...
A more general rule for function complexity would involve levels
of nesting of control structures, or the number of different
paths through the function.
I also find comments as to why you didn't do something to be
important: why you didn't use the obvious simple solution (which
maybe not so obviously doesn't work).
Exactly; you couldn't simplify and clarify something past the commentary
threshold.
More importantly, assertions and unit tests aren't part of the
documentation.
They have majorly overlapping and complementary roles.
You might be different, but I rarely go from reading a new API's
documentation to typing in its first function. I keep searching until I
locate some good sample code. It almost always covers gaps in the
documentation, such as "oh yeah, you have to also call that function,
first". Something about documentation makes those gaps inevitable, and if
you can't beat unit tests, join them!
Developers should lean on their unit tests - even leaving redundant code in
them - to push up their self-documention. For example:
http://assertxpath.rubyforge.org/classes/AssertXPath.html#assert_hpricot
The top prose in your browser came from a comment above the target method,
assert_hpricot, and the white DIV with highlighted syntax, below, is a code
sample transcluded from a live unit test. The test can't appear on that web
page unless its suite passes.
And, oh yeah, the requirements document:
http://www.oreillynet.com/onlamp/blog/2007/08/assert_hpricot_1.html
--
Phlip
http://www.oreilly.com/catalog/9780596510657/
.
|
|
|
| User: "James Kanze" |
|
| Title: Re: Coding Standards |
05 Sep 2007 02:48:20 AM |
|
|
On Sep 5, 3:41 am, Phlip <phlip2...@gmail.com> wrote:
James Kanze wrote:
[...]
More importantly, assertions and unit tests aren't part of the
documentation.
They have majorly overlapping and complementary roles.
They have distinctly different roles. In particular, you can't
write a single line of code (unit test or implementation) before
you know what the function should do, and you don't really
"know" anything until you've written it down. For some very
simple functions, just the function name may be sufficient, but
99 times out of a 100, you'll need more. Some of that more can
be expressed within the language---if the return type is int,
for example, there is an explicit post-condition that the return
value won't be 1.5. But there are still a lot of things that
cannot easily be expressed, even taking assertions into account.
And as it currently stands, C++ has no mechanism for specifying
the assertions in a way that the user can see them. (What we
really need, of course, is some sort of system which converts
the documentation into a header file, rather than things like
Doxygen, which do the reverse. Something like ESC for Java
would be nice as well.)
You might be different, but I rarely go from reading a new API's
documentation to typing in its first function. I keep searching until I
locate some good sample code. It almost always covers gaps in the
documentation, such as "oh yeah, you have to also call that function,
first". Something about documentation makes those gaps inevitable,
Something about developing without a process may make those gaps
inevitable, but in well run shops, they don't get through code
review. And just looking at code will never really tell you
whether the function f() has to be called before function g(),
or is only called before it in this particular example. Whether
the f() must be called first must, in fact, be known before the
author writes g(), and as I said above, it's not "known" unless
it's written down. After that, the code review ensures that if
there is no requirement that f() be called first, there are unit
tests that don't call it first. But until the requirement is
stated, the author of g() can't write any code, implementation
or unit test, since he doesn't know what to write.
and if
you can't beat unit tests, join them!
Except that unit tests are a lot more wordy than good
documentation, and if you don't have the documentation to begin
with, then you have no way of verifying that the unit tests are
complete.
Developers should lean on their unit tests - even leaving
redundant code in them - to push up their self-documention.
Unit tests should be "self-documenting" in the sense that you
don't need any additional documentation to understand them. But
the user doesn't normally have access to them, nor should he.
--
James Kanze (GABI Software) email:james.kanze@gmail.com
Conseils en informatique orient=E9e objet/
Beratung in objektorientierter Datenverarbeitung
9 place S=E9mard, 78210 St.-Cyr-l'=C9cole, France, +33 (0)1 30 23 00 34
.
|
|
|
| User: "Phlip" |
|
| Title: Re: Coding Standards |
05 Sep 2007 11:31:28 AM |
|
|
James Kanze wrote:
In particular, you can't
write a single line of code (unit test or implementation) before
you know what the function should do,
I didn't bring up TDD, but if you are curious enough about it to keep asking
these entry-level FAQs, you ought to ask them to a community capable of
engaging your respect. That might help these endless tiffs and
disagreements regarding who is lecturing whom.
--
Phlip
http://www.oreilly.com/catalog/9780596510657/
.
|
|
|
| User: "James Kanze" |
|
| Title: Re: Coding Standards |
05 Sep 2007 03:06:10 PM |
|
|
On Sep 5, 6:31 pm, Phlip <phlip2...@gmail.com> wrote:
James Kanze wrote:
In particular, you can't
write a single line of code (unit test or implementation) before
you know what the function should do,
I didn't bring up TDD, but if you are curious enough about it
to keep asking these entry-level FAQs,
I'm not asking anything. I'm simply stating an easily
established fact, which wishful thinking seems to cause some
people to ignore. Tests definitly have their role, but until
you know what the code should do, you can't begin to write them.
And until you've written something down in black and white, you
don't know it.
--
James Kanze (GABI Software) email:james.ka...@gmail.com
Conseils en informatique orient=E9e objet/
Beratung in objektorientierter Datenverarbeitung
9 place S=E9mard, 78210 St.-Cyr-l'=C9cole, France, +33 (0)1 30 23 00 34
.
|
|
|
| User: "Ian Collins" |
|
| Title: Re: Coding Standards |
05 Sep 2007 09:38:42 PM |
|
|
James Kanze wrote:
On Sep 5, 6:31 pm, Phlip <phlip2...@gmail.com> wrote:
James Kanze wrote:
In particular, you can't
write a single line of code (unit test or implementation) before
you know what the function should do,
I didn't bring up TDD, but if you are curious enough about it
to keep asking these entry-level FAQs,
I'm not asking anything. I'm simply stating an easily
established fact, which wishful thinking seems to cause some
people to ignore. Tests definitly have their role, but until
you know what the code should do, you can't begin to write them.
And until you've written something down in black and white, you
don't know it.
I think we ares starting form a different definition of "know what the
code should do".
Those of us who use TDD, tend to use plain customer language stories as
our requirements. A recent example I had was "add a new type of alarm
that combines up to 10 existing alarms". From another, completely
non-technical customer "Add a notes box if the user selects red".
--
Ian Collins.
.
|
|
|
| User: "James Kanze" |
|
| Title: Re: Coding Standards |
06 Sep 2007 07:02:44 AM |
|
|
On Sep 6, 4:38 am, Ian Collins <ian-n...@hotmail.com> wrote:
James Kanze wrote:
On Sep 5, 6:31 pm, Phlip <phlip2...@gmail.com> wrote:
James Kanze wrote:
In particular, you can't
write a single line of code (unit test or implementation) before
you know what the function should do,
I didn't bring up TDD, but if you are curious enough about it
to keep asking these entry-level FAQs,
I'm not asking anything. I'm simply stating an easily
established fact, which wishful thinking seems to cause some
people to ignore. Tests definitly have their role, but until
you know what the code should do, you can't begin to write them.
And until you've written something down in black and white, you
don't know it.
I think we ares starting form a different definition of "know what the
code should do".
Those of us who use TDD, tend to use plain customer language stories as
our requirements. A recent example I had was "add a new type of alarm
that combines up to 10 existing alarms". From another, completely
non-technical customer "Add a notes box if the user selects red".
Writing the requirements specifications is an iterative process.
Obviously, given requests like the above, you start by getting
more information, and writing up some sort of more detailed
requirements for the customer approve.
I wonder if part of the problem isn't that you are confusing
prototyping with testing. For interactive programs, some degree
of prototyping is often useful, or even essential, in order for
the user to really see the impact of what he is approving. And
such a prototype can be part of the requirements specifications:
if event x occurs, the application should visually behave as the
prototype does. But a prototype is not the application. You
still need to specify a lot of "invisible" behavior. (Load
requirements, failure modes, synchronization requirements, etc.
See my other response to you for some concrete examples.)
And of course, prototyping is not necessarily relevant to
everything. If you're implementing an LDAP server, for example,
you don't really need to prototype; the protocol is already
specified, and the customer isn't going to change it.
--
James Kanze (GABI Software) email:james.kanze@gmail.com
Conseils en informatique orient=E9e objet/
Beratung in objektorientierter Datenverarbeitung
9 place S=E9mard, 78210 St.-Cyr-l'=C9cole, France, +33 (0)1 30 23 00 34
.
|
|
|
| User: "Ian Collins" |
|
| Title: Re: Coding Standards |
06 Sep 2007 02:46:24 PM |
|
|
James Kanze wrote:
On Sep 6, 4:38 am, Ian Collins <ian-n...@hotmail.com> wrote:
James Kanze wrote:
On Sep 5, 6:31 pm, Phlip <phlip2...@gmail.com> wrote:
James Kanze wrote:
In particular, you can't
write a single line of code (unit test or implementation) before
you know what the function should do,
I didn't bring up TDD, but if you are curious enough about it
to keep asking these entry-level FAQs,
I'm not asking anything. I'm simply stating an easily
established fact, which wishful thinking seems to cause some
people to ignore. Tests definitly have their role, but until
you know what the code should do, you can't begin to write them.
And until you've written something down in black and white, you
don't know it.
I think we ares starting form a different definition of "know what the
code should do".
Those of us who use TDD, tend to use plain customer language stories as
our requirements. A recent example I had was "add a new type of alarm
that combines up to 10 existing alarms". From another, completely
non-technical customer "Add a notes box if the user selects red".
Writing the requirements specifications is an iterative process.
Obviously, given requests like the above, you start by getting
more information, and writing up some sort of more detailed
requirements for the customer approve.
I think that part is where we diverge. Building the system is an
iterative process. We do not write up more detailed requirements, we
implement the story and give the customer working code, the easiest
thing for them to understand. Depending on the nature of the project,
I'd use one or two week iterations, shorter if the customer is unsure
what they really want.
I wonder if part of the problem isn't that you are confusing
prototyping with testing.
Most definitely not. I would tinker with a prototype to investigate new
technologies or ideas, but the customer doesn't get to see the
prototype, only the tested implementations.
For interactive programs, some degree
of prototyping is often useful, or even essential, in order for
the user to really see the impact of what he is approving.
So does working with short iterations. With a couple of customers, I
kept a live system (updated on each commit) running so they could play
with it as it grew and feed back changes.
--
Ian Collins.
.
|
|
|
| User: "James Kanze" |
|
| Title: Re: Coding Standards |
07 Sep 2007 05:02:44 AM |
|
|
On Sep 6, 9:46 pm, Ian Collins <ian-n...@hotmail.com> wrote:
James Kanze wrote:
On Sep 6, 4:38 am, Ian Collins <ian-n...@hotmail.com> wrote:
James Kanze wrote:
On Sep 5, 6:31 pm, Phlip <phlip2...@gmail.com> wrote:
James Kanze wrote:
In particular, you can't
write a single line of code (unit test or implementation) before
you know what the function should do,
I didn't bring up TDD, but if you are curious enough about it
to keep asking these entry-level FAQs,
I'm not asking anything. I'm simply stating an easily
established fact, which wishful thinking seems to cause some
people to ignore. Tests definitly have their role, but until
you know what the code should do, you can't begin to write them.
And until you've written something down in black and white, you
don't know it.
I think we ares starting form a different definition of "know what the
code should do".
Those of us who use TDD, tend to use plain customer language stories as
our requirements. A recent example I had was "add a new type of alarm
that combines up to 10 existing alarms". From another, completely
non-technical customer "Add a notes box if the user selects red".
Writing the requirements specifications is an iterative process.
Obviously, given requests like the above, you start by getting
more information, and writing up some sort of more detailed
requirements for the customer approve.
I think that part is where we diverge. Building the system is an
iterative process.
And each iteration has its requirements, which must be
documented. Nothing new here.
We do not write up more detailed requirements, we
implement the story and give the customer working code, the easiest
thing for them to understand.
And what's the "story", if it isn't some sort of requirements.
Probably incomplete, since there are aspects that the client may
not even understand, but that you'll want to document---see my
posting about things like a dropped connection. But with the
use of the word "story", you've sort of half-way agreed with me
anyway: you don't just randomly code something; you specify what
you are going to code first. My main argument is that this
specification 1) must be written (not just oral), and 2) is
documentation. (Afterwards, we can agree to disagree with
regards to how detailed this specification must be. My
experience is the more detailed the better, as long as it
doesn't introduce any implementation details.)
Depending on the nature of the project,
I'd use one or two week iterations, shorter if the customer is unsure
what they really want.
And longer, perhaps, if there are rigorous technical documents
detailing much of the interface (e.g. a LDAP server, or a C++
compiler---if the customer's story is he wants to compile C++, I
doubt you can come up with anything close in a week). If the
final customer requests an LDAP server front end for his data
base, I certainly won't require him to review partial code every
week or so, regardless of what we mean by review. His data base
schemas and the LDAP protocol are a very precise specification
of what is required.
Of course, internally, once the design is done, the people
working on one subsystem may be considered clients (customers)
of another subsystem, and more frequent deliveries (to detect
design flaws) would definitely be desirable there.
I wonder if part of the problem isn't that you are confusing
prototyping with testing.
Most definitely not. I would tinker with a prototype to investigate new
technologies or ideas, but the customer doesn't get to see the
prototype, only the tested implementations.
That's a different type of prototype. For interactive programs,
it's often useful to hack up a prototype to verify ergonomy
features before you've really begun to define what will take
place behind the scenes. In several cases, I've even seen
Tcl/tk used for this, although the final application would be in
C++. If you can do this in a way that the prototype code can be
used, at least partially, in the final application, I'm all for
it.
For interactive programs, some degree
of prototyping is often useful, or even essential, in order for
the user to really see the impact of what he is approving.
So does working with short iterations. With a couple of customers, I
kept a live system (updated on each commit) running so they could play
with it as it grew and feed back changes.
I'm not too sure what kind of systems you work on, but my
customers don't "play" with the system. There are some aspects
where this sort of play is useful (e.g. ergonomy of a GUI), but
for a lot of things, it simply isn't relevant. Many of the
details in my current application (a server), for example, are
conditionned by various stock market and bookkeeping laws, and
even for the others, many types of changes would require
modification in the various client software before them could be
exercised. And what about my previous contract, where the
requirements were simply to take the existing Radius server
(used for dynamic allocation of IP addresses in a wireless
network) and upgrade it so that it could handle 170 transactions
per second (given that each data base transaction required an
non-compressible 10 millisecond write to disk). How does such
interaction play a role when issues like transactional integrety
or thread safety are the issues? (Maybe I'm oversensitive about
this, but I've just seen so much code which passed all tests,
but which would fail once or twice a year in actual use.)
--
James Kanze (GABI Software) email:james.kanze@gmail.com
Conseils en informatique orient=E9e objet/
Beratung in objektorientierter Datenverarbeitung
9 place S=E9mard, 78210 St.-Cyr-l'=C9cole, France, +33 (0)1 30 23 00 34
.
|
|
|
| User: "Phlip" |
|
| Title: Re: Coding Standards |
07 Sep 2007 05:35:08 AM |
|
|
James Kanze wrote:
Afterwards, we can agree to disagree with
regards to how detailed this specification must be.
As the iteration length drops, and as the tests become more literate, and as
the code grows more resistant to unwanted changes, the value of details in
the specifications go down. That's why, at the limit of one week, you can
rely on cards with the _names_ of features on them, accompanied by ready
access to someone in the customer role.
--
Phlip
.
|
|
|
|
| User: "Phlip" |
|
| Title: Re: Coding Standards |
07 Sep 2007 05:44:28 PM |
|
|
James Kanze wrote:
And what's the "story", if it isn't some sort of requirements.
Probably incomplete
Between writing the text story-card and the developer tests, you should
first write a customer test.
This is an excerpt from today's Agile Testing mailing list[1]:
Here's an example of
how it has worked for us. This literally happened on the 2nd story for
which we wrote FitNesse tests.
1. I write a FitNesse[2] test for code that's not yet implemented.
2. The programmer working on the story goes to automate the test. The
test
case is not what he expected. 3. The programmer comes over to ask me. I
explain what the test case is doing and he says "Aha, I had misunderstood
how that should work." He goes to change his code to make the feature
work
the way the product owner had actually intended.
If there were no FitNesse test, the programmer would write the unit test
for
how he understood the feature, then write the code, then nobody would
discover the incorrect implementation until later, when the programmer may
even think he's 'done'. You could argue that we should have all done a
better job of talking about the story so that everyone understood the
requirements, but in this case, something simply slipped past the
programmer's awareness until he saw the test case.
--Lisa Crispin, author of /Testing XP/
So it seems to me the odds of requirements being incomplete go down as they
are expressed as literate tests cases...
[1] http://tech.groups.yahoo.com/group/agile-testing/message/12383
[2] http://fitnesse.org/
--
Phlip
.
|
|
|
|
|
|
|
|
|
|
| User: "Ian Collins" |
|
| Title: Re: Coding Standards |
05 Sep 2007 03:38:34 AM |
|
|
James Kanze wrote:
On Sep 5, 3:41 am, Phlip <phlip2...@gmail.com> wrote:
James Kanze wrote:
[...]
More importantly, assertions and unit tests aren't part of the
documentation.
They have majorly overlapping and complementary roles.
They have distinctly different roles. In particular, you can't
write a single line of code (unit test or implementation) before
you know what the function should do, and you don't really
"know" anything until you've written it down.
But they (well written, test first unit tests) do bridge the gap between
a client's requirements (or some formal specification) and the code.
As such, they provide an interpretation of those requirements. The
interpretation should be validated by a set of customer acceptance tests.
For some very
simple functions, just the function name may be sufficient, but
99 times out of a 100, you'll need more. Some of that more can
be expressed within the language---if the return type is int,
for example, there is an explicit post-condition that the return
value won't be 1.5. But there are still a lot of things that
cannot easily be expressed, even taking assertions into account.
And as it currently stands, C++ has no mechanism for specifying
the assertions in a way that the user can see them.
That is where unit and more importantly customer acceptance test
frameworks come in. They provide the required vocabulary to enable
developers and customers/test engineers to to specifying the assertions
in a meaningful way.
and if
you can't beat unit tests, join them!
Except that unit tests are a lot more wordy than good
documentation, and if you don't have the documentation to begin
with, then you have no way of verifying that the unit tests are
complete.
That is because thy provide more detail than the documentation.
--
Ian Collins.
.
|
|
|
| User: "James Kanze" |
|
| Title: Re: Coding Standards |
05 Sep 2007 03:02:46 PM |
|
|
On Sep 5, 10:38 am, Ian Collins <ian-n...@hotmail.com> wrote:
James Kanze wrote:
On Sep 5, 3:41 am, Phlip <phlip2...@gmail.com> wrote:
James Kanze wrote:
[...]
More importantly, assertions and unit tests aren't part of the
documentation.
They have majorly overlapping and complementary roles.
They have distinctly different roles. In particular, you can't
write a single line of code (unit test or implementation) before
you know what the function should do, and you don't really
"know" anything until you've written it down.
But they (well written, test first unit tests) do bridge the gap between
a client's requirements (or some formal specification) and the code.
As such, they provide an interpretation of those requirements. The
interpretation should be validated by a set of customer acceptance tests.
They are an implementation of part of the specification. But
you can't write them until you have the specification: a precise
English (or other human) language document as to what the code
is to do. And there are more than a few cases that they simply
cannot cover, and for the most part, they are both more verbose
than a requirement specification should be, and fail to say a
lot of things that are essential in a requirement specification.
For some very
simple functions, just the function name may be sufficient, but
99 times out of a 100, you'll need more. Some of that more can
be expressed within the language---if the return type is int,
for example, there is an explicit post-condition that the return
value won't be 1.5. But there are still a lot of things that
cannot easily be expressed, even taking assertions into account.
And as it currently stands, C++ has no mechanism for specifying
the assertions in a way that the user can see them.
That is where unit and more importantly customer acceptance test
frameworks come in. They provide the required vocabulary to enable
developers and customers/test engineers to to specifying the assertions
in a meaningful way.
If the customer can read and write unit tests, he's perfectly
capable of implementing the code himself, and doesn't need you.
My customers are bankers, or telephone specialists, or simply
application programmers, who are completely incapable of writing
or reading the level of C++ I program at (framework and system
level code). Asking a customer to guess the thread safety
guarantees made by the class, for example, just by reading the
unit tests, is simply ridiculous.
and if
you can't beat unit tests, join them!
Except that unit tests are a lot more wordy than good
documentation, and if you don't have the documentation to begin
with, then you have no way of verifying that the unit tests are
complete.
That is because thy provide more detail than the documentation.
Actually, they provide less useful information---they are more
verbose, because the compiler requires a lot more unnecessary
and uninteresting detail than the user does. But they don't
make a succinct abstraction or summary of anything, which is the
most important thing for the user. How do you determine the
role of a class in an application from its unit tests?
--
James Kanze (GABI Software) email:james.ka...@gmail.com
Conseils en informatique orient=E9e objet/
Beratung in objektorientierter Datenverarbeitung
9 place S=E9mard, 78210 St.-Cyr-l'=C9cole, France, +33 (0)1 30 23 00 34
.
|
|
|
| User: "Ian Collins" |
|
| Title: Re: Coding Standards |
05 Sep 2007 09:31:38 PM |
|
|
James Kanze wrote:
On Sep 5, 10:38 am, Ian Collins <ian-n...@hotmail.com> wrote:
But they (well written, test first unit tests) do bridge the gap between
a client's requirements (or some formal specification) and the code.
As such, they provide an interpretation of those requirements. The
interpretation should be validated by a set of customer acceptance tests.
They are an implementation of part of the specification. But
you can't write them until you have the specification: a precise
English (or other human) language document as to what the code
is to do.
Which when provided by customers (those who pay my bills) are at a level
understandable by the customer, not precise technical language.
And there are more than a few cases that they simply
cannot cover, and for the most part, they are both more verbose
than a requirement specification should be, and fail to say a
lot of things that are essential in a requirement specification.
Such as?
I'm not being difficult, just commenting based on a development process
I have been following for a number of years.
That is where unit and more importantly customer acceptance test
frameworks come in. They provide the required vocabulary to enable
developers and customers/test engineers to to specifying the assertions
in a meaningful way.
If the customer can read and write unit tests, he's perfectly
capable of implementing the code himself, and doesn't need you.
You didn't read what I wrote "and more importantly customer acceptance
test frameworks". Most of my customers can, with a bit of help, use
something like FIT for developing *acceptance* tests, not unit tests.
--
Ian Collins.
.
|
|
|
| User: "James Kanze" |
|
| Title: Re: Coding Standards |
06 Sep 2007 06:52:46 AM |
|
|
On Sep 6, 4:31 am, Ian Collins <ian-n...@hotmail.com> wrote:
James Kanze wrote:
On Sep 5, 10:38 am, Ian Collins <ian-n...@hotmail.com> wrote:
But they (well written, test first unit tests) do bridge the gap betwe=
en
a client's requirements (or some formal specification) and the code.
As such, they provide an interpretation of those requirements. The
interpretation should be validated by a set of customer acceptance tes=
ts.
They are an implementation of part of the specification. But
you can't write them until you have the specification: a precise
English (or other human) language document as to what the code
is to do.
Which when provided by customers (those who pay my bills) are at a level
understandable by the customer, not precise technical language.
You have to find a middle road. The customer (including
internal customers---"customers" for individual classes are
almost always internal) must be able to specify his needs
adequately for you to understand them. You then produce a more
detailed document, but still in a language the customer can
understand.
And there are more than a few cases that they simply
cannot cover, and for the most part, they are both more verbose
than a requirement specification should be, and fail to say a
lot of things that are essential in a requirement specification.
Such as?
I'm not being difficult, just commenting based on a
development process I have been following for a number of
years.
Anything involving undefined behavior, for example. Most things
involving threading as well. And a lot of things involving
floating point. (The fact that floating point arithmetic is
non-linear means that you can't always determine the critical
values which need to be tested without a lot of additional
analysis. And that they depend on the actual algorithm used;
black box testing isn't all that effective.)
A good unit test will typically test hundreds of "limit"
cases, all of which can often be covered by one or two succinct
sentences in the requirements specification. On the other hand,
no unit test will make statements at the more abstract level:
what is the role of the class in the application. What are it's
responsibilities, and what aren't?
It's not quite the sort of thing I was thinking of, but since
it's readily available on the net: consider the guarantees (the
contract) concerning thread safety in the SGI implementation of
the STL (http://www.sgi.com/tech/stl/thread_safety.html). How
on earth could you document something like this in unit tests?
For that matter, how on earth could you even test it? And note
that the aspects which your most concerned about in testing (the
cases when an external lock isn't necessary) are precisely the
ones which are least important for the user.
Another simple example, consider a network connection class.
The "documentation" (the requirements specification, or the
contract) may simple say that an exception will be raised if the
connection is broken. My unit tests, however, will simulate all
sorts of ways the connection might break. Details that the user
doesn't care about, and probably doesn't even understand. One
the other hand, 100's of tests don't begin to express the
abstract aspect of the contract: that whatever the cause of the
connection being broken, an exception will be raised.
Some additional important points:
-- The contract is a contract. It holds for the future as
well. It doesn't just make promesses about the current
implementation; it constrains future modifications. And
tests can only do this partially: if the protocol is
modified sometime in the future, and new failure modes are
introduced, there is no way to express in the tests that
these (at present unknown) failure modes must also result in
an exception.
-- Some failure modes may be extremely difficult, if not
impossible, to simulate. If the code is well reviewed, it's
probably acceptable to not test these.
-- Most failures will in fact be detected and reported by the
system. For the user, the contract isn't: an exception if
the Posix function select returns such and such an error
code---the user doesn't care about the function select, nor
even understand it. But what my tests test, of course, is
the behavior of my code depending on the status returned by
select.
In the end, the reason why unit tests (or any tests) aren't
acceptable as a requirements specification is because they are
(or should be) oriented to a different audience. You don't use
the same language when you communicate with people as when you
communicate with a machine.
That is where unit and more importantly customer acceptance test
frameworks come in. They provide the required vocabulary to enable
developers and customers/test engineers to to specifying the assertions
in a meaningful way.
If the customer can read and write unit tests, he's perfectly
capable of implementing the code himself, and doesn't need you.
You didn't read what I wrote "and more importantly customer acceptance
test frameworks". Most of my customers can, with a bit of help, use
something like FIT for developing *acceptance* tests, not unit tests.
It's a difference of level, perhaps. Development is a
hierarchial process. The final customer or user defines the
behavior of the application, and (hopefully for him) defines an
acceptance protocol, including tests, document review, etc.
Each individual class, however, also has "customers". And unit
tests are about the only testing individual classes will
receive. Typically (at least in the places I've worked), such
unit tests aren't written by the clients; they're part of the
development. And because I tend to work in the infrastructure,
generally, my "client" programmers wouldn't necessarily be able
to understand all of the unit tests.
The way it generally happens (in well run companies) is that the
architecture team will come up with a general design---including
the interface and the contract between subsystems, and possibly
even down to the class level. (The interface will, at any rate,
be defined in terms of classes.) Then there will be a design
review, where all concerned parties "sign off" the design---they
more or less state that they can live with the interfaces as
they are specified. Depending on the organization, at this
point, the header files may or may not have been written, but no
implementation nor unit tests exist---only a contract between
the implementors (of each subsystem or class) and the clients
(who are also implementors of other subsystems or classes).
Only once the contract has been defined does anyone start to
write code. (Obviously, it is almost always necessary to revise
the contract at various times during development. Even the best
architecture team can't think of everything. But any revision
which modifies the contract must be reviewed by a representive
of all parties concerned.)
--
James Kanze (GABI Software) email:james.kanze@gmail.com
Conseils en informatique orient=E9e objet/
Beratung in objektorientierter Datenverarbeitung
9 place S=E9mard, 78210 St.-Cyr-l'=C9cole, France, +33 (0)1 30 23 00 34
.
|
|
|
| User: "Phlip" |
|
| Title: Re: Coding Standards |
06 Sep 2007 06:34:57 AM |
|
|
James Kanze wrote:
A good unit test will typically test hundreds of "limit"
cases
We are discussing "developer tests". You don't know what they are, so of
course they are not "unit tests".
--
Phlip
.
|
|
|
|
| User: "Ian Collins" |
|
| Title: Re: Coding Standards |
06 Sep 2007 02:47:45 PM |
|
|
James Kanze wrote:
On Sep 6, 4:31 am, Ian Collins <ian-n...@hotmail.com> wrote:
James Kanze wrote:
On Sep 5, 10:38 am, Ian Collins <ian-n...@hotmail.com> wrote:
But they (well written, test first unit tests) do bridge the gap between
a client's requirements (or some formal specification) and the code.
As such, they provide an interpretation of those requirements. The
interpretation should be validated by a set of customer acceptance tests.
They are an implementation of part of the specification. But
you can't write them until you have the specification: a precise
English (or other human) language document as to what the code
is to do.
Which when provided by customers (those who pay my bills) are at a level
understandable by the customer, not precise technical language.
You have to find a middle road. The customer (including
internal customers---"customers" for individual classes are
almost always internal) must be able to specify his needs
adequately for you to understand them. You then produce a more
detailed document, but still in a language the customer can
understand.
When one uses an iterative process with short one or two week
iterations, the customer gets to see his story as working working code,
far better than yet another document.
I can't do justice to the rest of the post here, I'll digest it and get
back to you.
--
Ian Collins.
.
|
|
|
|
|
|
|
|
|
|
|
|
|
| User: "Joe Greer" |
|
| Title: Re: Coding Standards |
31 Aug 2007 07:31:22 AM |
|
|
H <H@r.c> wrote in news:LmPBi.28851$4A1.15145@news-server.bigpond.net.au:
davidsamith@gmail.com wrote:
'Good code' is code that works, is bug free, and is readable and
maintainable. Standards need to be followed for coding. Read more...
http://brsx.co.uk/SWtesting/FAQs/FAQs012.asp
This says to increase maintainability, we should minimise operator
overloading. I'm new at this and confused, I thought operator
overloading (used correctly) aided maintainability and readability?!??
Well, it's a double-edged sword. If you are modeling a mathematical class
where the normal operators are well-known and understood (i.e. complex
arithmetic) then the overloaded operators make a whole lot of sense and in
general are a good thing. However, if you are adding somewhat arbitrary
meaning to the operators like having + sort do a search on a list or
something, then it adds to the confusion level because the '+' symbol
itself offers no clues to the operation being performed and worse it hints
that some sort of additive action is taking place.
Really, there isn't a whole lot of difference between operator overloading
and normal function overloading done badly. What I mean is, it is just as
bad to have a function named 'print' that does a search operation as it is
to abuse the binary operators, at least from a code maintenance aspect.
joe
.
|
|
|
| User: "Phlip" |
|
| Title: Re: Coding Standards |
31 Aug 2007 07:38:39 AM |
|
|
Joe Greer wrote:
This says to increase maintainability, we should minimise operator
overloading. I'm new at this and confused, I thought operator
overloading (used correctly) aided maintainability and readability?!??
Well, it's a double-edged sword. If you are modeling a mathematical class
where the normal operators are well-known and understood (i.e. complex
arithmetic) then the overloaded operators make a whole lot of sense and in
general are a good thing. However, if you are adding somewhat arbitrary
meaning to the operators like having + sort do a search on a list or
something, then it adds to the confusion level because the '+' symbol
itself offers no clues to the operation being performed and worse it hints
that some sort of additive action is taking place.
Right - that falls under the guidelines...
- overload operators to do the same thing as their native versions
- don't overload them to accomplish sophomoric pranks
- and overload them together in kits.
Except for <<
(-;
--
Phlip
http://www.oreilly.com/catalog/9780596510657/
"Test Driven Ajax (on Rails)"
assert_xpath, assert_javascript, & assert_ajax
.
|
|
|
| User: "Joe Greer" |
|
| Title: Re: Coding Standards |
31 Aug 2007 07:50:23 AM |
|
|
"Phlip" <phlipcpp@yahoo.com> wrote in
news:tPSdne6JWIpHlkXbnZ2dnUVZ_h6vnZ2d@adelphia.com:
Joe Greer wrote:
This says to increase maintainability, we should minimise operator
overloading. I'm new at this and confused, I thought operator
overloading (used correctly) aided maintainability and
readability?!??
Well, it's a double-edged sword. If you are modeling a mathematical
class where the normal operators are well-known and understood (i.e.
complex arithmetic) then the overloaded operators make a whole lot of
sense and in general are a good thing. However, if you are adding
somewhat arbitrary meaning to the operators like having + sort do a
search on a list or something, then it adds to the confusion level
because the '+' symbol itself offers no clues to the operation being
performed and worse it hints that some sort of additive action is
taking place.
Right - that falls under the guidelines...
- overload operators to do the same thing as their native versions
- don't overload them to accomplish sophomoric pranks
- and overload them together in kits.
Except for <<
(-;
Well, personally I hate iostreams, though I understand the desire and the
perceived need for the operator overloading. I won't go there however. :)
joe
.
|
|
|
|
|
|
| User: "Michael DOUBEZ" |
|
| Title: Re: Coding Standards |
31 Aug 2007 03:17:00 AM |
|
|
H a écrit :
davidsamith@gmail.com wrote:
'Good code' is code that works, is bug free, and is readable and
maintainable. Standards need to be followed for coding. Read more...
http://brsx.co.uk/SWtesting/FAQs/FAQs012.asp
This says to increase maintainability, we should minimise operator
overloading. I'm new at this and confused, I thought operator
overloading (used correctly) aided maintainability and readability?!??
Don't believe everything you read. And every pattern (including coding
guidelines) should present the forces it balanced.
IMO, if you want a good starting point on C++ coding, give a try to "C++
Coding Standards" by Herb Sutter and Andrei Alexandrescu.
A review is available on ACCU:
http://www.gotw.ca/publications/c++cs.htm
Note that those gurus felt a whole book, not a single web page, was needed.
Michael
.
|
|
|
|
|
| User: "Phlip" |
|
| Title: Re: Coding Standards |
31 Aug 2007 07:26:29 AM |
|
|
'Good code' is code that works, is bug free, and is readable and
maintainable. Standards need to be followed for coding. Read more...
http://*/SWtesting/FAQs/FAQs012.asp
That site is yet another fraudulent honey-pot for Google Ads. Here's the
site they ripped the text off:
http://www.softwareqatest.com/qatfaq1.html
Good code...
- passes all test cases
- is clear and readable
- duplicates no expressions of behavior
- minimizes lines, methods, and classes
Not sure why the original page neglected the test cases...
--
Phlip
http://www.oreilly.com/catalog/9780596510657/
"Test Driven Ajax (on Rails)"
assert_xpath, assert_javascript, & assert_ajax
.
|
|
|
|
|
Related Articles |
|
|
