Re: Code Review please.
* Control Freq:
Hi Alf,
Thanks for your input. I guess it is hard to appraise a solution when
you don't know the requirements. An impossible task really.
But, I read your comments with interest. Although my response to most
of your comments is 'Well, I had to do it that way; it was in the
requirements'. And, ' The coding conventions in use at the time had to
be followed'.
Specifically, your items (1) (2) & (5) were all requirements of the
test. I was applying for a MFC programming position, so I had to use
MFC, and I wasn't allowed to use the std::stack<int> method.
The issues I have with your comments are:
1) Keep functions to well under 10 lines?
I read a thread a while ago in C# stating that functions should be no
more than 25 lines long. These arbitrary limits serve no real purpose.
They do: they keep complexity down.
Like all rules of thumbs it's mainly a rule for those who don't understand
and/or fail to apply the rationale of the rule.
So, until you understand it, which you admit you don't, just try to follow it.
An eye-opener is trying to correct someone else's 800 line function.
Generally, a function that for no good reason is 100 lines or more screams
incompetence. Happily that's not something that is necessarily a permanent
attribute of a person. Everybody's done that until they learned better. :-)
I try to abide by the 'one function does one thing' method.
Good.
2) Indenting. This one seems to be dependent on who is in charge of
coding 'conventions'. I do a lot of third party integration work.
Meaning that I get lots of code from different sources and try to
stitch them together into a product. All parties apply their own
coding conventions. So, there are no hard and fast rules when it comes
to the number of spaces to indent by. This applies to *nixes as well
as Windows code.
"No" rules is stating it too strongly, and here you fail to understand the
issue: it's about tab size, not indent size.
For a pure Windows program it's OK using tab size 4, because that's the default
of Windows programming editors.
For portable code use spaces instead of tabs (e.g., this is the solution adopted
by Boost).
Having said all of this, I didn't get the job :(.
I was told that I should have used templating techniques, but really I
should have spent more time looking at the exception safety aspects of
my implementation.
I didn't even consider that as an issue. Now I have a book on that
subject I realise that I still have much to learn about C++
programming.
It can be hard to deal with exception safety in MFC because MFC predates the
introduction of exceptions in C++, and so is based on an ad-hoc ungood model.
A good place to start to learn about exception safety is <url:
http://www.boost.org/community/exception_safety.html>; try to understand the
three kinds of exception safety guarantee defined there.
See also e.g. the PDF file linked to from <url:
http://www.research.att.com/~bs/3rd_safe0.html>; try to focus on the concept of
class invariant and what Bjarne has to say about that and about "init" functions
(his discussion is unfortunately not complete, but a good starting point).
Cheers, & hth.,
- Alf
--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?