By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
459,199 Members | 1,742 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 459,199 IT Pros & Developers. It's quick & easy.

Coding Standards

P: n/a
'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

Aug 31 '07 #1
Share this Question
Share on Google+
19 Replies


P: n/a
H
da*********@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?!??
Aug 31 '07 #2

P: n/a
H a écrit :
da*********@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
Aug 31 '07 #3

P: n/a
'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
Aug 31 '07 #4

P: n/a
H <H@r.cwrote in news:Lm*******************@news-server.bigpond.net.au:
da*********@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
Aug 31 '07 #5

P: n/a
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
Aug 31 '07 #6

P: n/a
"Phlip" <ph******@yahoo.comwrote in
news:tP******************************@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
Aug 31 '07 #7

P: n/a
<da*********@gmail.comwrote:
'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.
Aug 31 '07 #8

P: n/a
Phlip 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://*/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...
I think you can report the site to Google as an "ad spam" site by
clicking the "Ads By Google" link at the bottom of the ads.

--
SM
rot13 for email
Aug 31 '07 #9

P: n/a
On Aug 31, 12:19 pm, Shadowman <funqbjzna...@pbzpnfg.argwrote:
Phlip 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://*/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...

I think you can report the site to Google as an "ad spam" site by
clicking the "Ads By Google" link at the bottom of the ads.

--
SM
rot13 for email
it would be a great idea, but I couldn't find this option :(

Aug 31 '07 #10

P: n/a

Diego Martins <jo********@gmail.comwrote in message...
On Aug 31, 12:19 pm, Shadowman <funqbjzna...@pbzpnfg.argwrote:

I think you can report the site to Google as an "ad spam" site by
clicking the "Ads By Google" link at the bottom of the ads.

it would be a great idea, but I couldn't find this option :(
Since google encourages top-posting, and he said "bottom", did you think to
look at the top? <G>

[ Sorry, the devil *made* me do it. ]

Wonder if he meant the "Advertising Programs" link.

--
Bob <GR
POVrookie
Sep 1 '07 #11

P: n/a
BobR wrote:
Diego Martins <jo********@gmail.comwrote in message...
>On Aug 31, 12:19 pm, Shadowman <funqbjzna...@pbzpnfg.argwrote:
>>I think you can report the site to Google as an "ad spam" site by
clicking the "Ads By Google" link at the bottom of the ads.
it would be a great idea, but I couldn't find this option :(

Since google encourages top-posting, and he said "bottom", did you think to
look at the top? <G>

[ Sorry, the devil *made* me do it. ]

Wonder if he meant the "Advertising Programs" link.
Hmmm, sorry, I guess it's not there anymore. Used to be. My office
blocks the google ads, so I couldn't verify it.
--
SM
rot13 for email
Sep 4 '07 #12

P: n/a
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/
Sep 5 '07 #13

P: n/a
On Sep 5, 6:31 pm, Phlip <phlip2...@gmail.comwrote:
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ée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34

Sep 5 '07 #14

P: n/a
James Kanze wrote:
On Sep 5, 6:31 pm, Phlip <phlip2...@gmail.comwrote:
>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.
Sep 6 '07 #15

P: n/a
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
Sep 6 '07 #16

P: n/a
On Aug 31, 12:05 am, "davidsam...@gmail.com" <davidsam...@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
It says about making "liberal use of exception handlers". But
've also heard something where that having too many exception
handlers all over the place isn't necessarily a good thing.

Sep 7 '07 #17

P: n/a
mike3 wrote:
>http://*/SWtesting/FAQs/FAQs012.asp

It says about making "liberal use of exception handlers". But
've also heard something where that having too many exception
handlers all over the place isn't necessarily a good thing.
Tip: Read /Exceptional C++/ by Herb Sutter.

Here's a list of generic "don'ts":

- don't duplicate code all over, even catch() statements
- don't just catch everything, write it to a log and keep going
- don't catch(...)
- don't write any error handling code without developer-tests
(use a mock object if you can't force the target error!)
- don't let your users invoke untested error-handling code!
- don't allow uncaught exceptions
- don't use exception specifiers ("void foo() throw(whatever);")

Put them together, and you _catch_ exceptions liberally, but you don't
_write_ catch statements liberally. You design them carefully like any
other code.

The most important Do there is, "At exception time, roll your state back to
its condition before the user entered their last input, or equivalent.
Don't leave a dangling state." This advice matches our main homeboy, James
Kanze's, recent pronouncement that RAII refers to more than just leakable
resources.

And a block closure system works wonders there, too... (-;

--
Phlip
Sep 7 '07 #18

P: n/a
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
Sep 7 '07 #19

P: n/a
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/a.../message/12383

[2] http://fitnesse.org/

--
Phlip
Sep 8 '07 #20

This discussion thread is closed

Replies have been disabled for this discussion.