Re: Variables in for loop (style issue)
Andrei Alexandrescu (See Website For Email) wrote:
kanze wrote:
Maciej Sobczak wrote:
James Kanze wrote:
What is obviously being refered to is programmer efficiency.
Not that of the person writing the code, since this is
obviously the most efficient solution for him, but of the
person reading it.
Exactly, this is the source of the discussion. Or, putting it
another way, how many precise things can we say about the code
by just reading it without resorting to larger-scale code
analysis.
I keep referring back to what my high school English teacher
said: "Good writing is clear and concise."
You may want to stop referring to that. The advice matches,
but by chance. Prose writing (write-once-read-many) has a
different charter than code writing (write-many-read-many).
Prose should also respect many rules that code shouldn't, and
vice versa.
I'm not sure. The analogy obviously isn't 100% -- there are
differences. On the other hand, she said "good writing", not
"good prose", and the differences are more along the lines of
the differences between prose fiction, poetry, and a technical
treatise. A C++ program obviously has different constraints
than a novel, but so does a poem. Are the differences greater?
I'm not sure about it.
I'd also disagree with the write-many-read-many categorization,
but I think that may be just a simplification on your part.
Write-few-read-many would be closer to correct, but even then...
there is a difference between being the original author, and
making a modification. And a lot of prose gets reworked by
people other than the original author as well. (The program
documentation, for starters:-). Still, I agree with what I
think was your import: that we should write code with regards to
making it easy to rework or to modify, and that such issues are
rarely present when writing normal English text. Note however
that in order to modify code, we must first understand it --
which brings us back to "good writing". This aspect of code may
introduce additional constraints, but it doesn't remove any that
are present in writing.
[...]
But for_each says that you don't modify the size... or do
anything else which might invalidate its iterators. That's
part of the message of using for_each -- the loop is
executed exactly n times, where n is determined before
entering the loop. In fact, that's its only message: that
there are no break's, no continue's and no other fiddling
around which will change this.
I think that this is generally known and recognized by
programmers familiar with the STL. That is: the message
will be understood immediately, and I don't need any
particular "training" for the programmers for it to pass.
Yet the for_each loop is severely limited in what it can
effect. That it evaluates its boundaries only once is about
the only good thing about for_each.
It's limitations are in fact the good thing. When you see
for_each, you know that what is being done conforms to these
limitations -- for_each is not find_if, for example. It's value
is not in the function itself -- it is in its opposition with
other functions (and explicit loops).
If, of course, your programming style always visits all of the
elements in a sequence, for_each doesn't tell you anything more
than a simple for loop would. But I don't think that this is
your case:-).
--
James Kanze GABI Software
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
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]