Re: Variables in for loop (style issue)
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.
There are two things that provoked me to post my questions.
First is that there are really coding standards that force
programmers making the kind of distinctions I've tried to
describe.
Nothing new there. It's not rare that there is no really good
solution, and you have to choose the least bad.
It is intriguing that a good solution does not contradict any "law".
That is the interesting point.
Which is a very good argument. My experience with other
programmers is exactly the same - writing v.size() in the
second caluse of the for loop is a common and well understood
idiom. The ojective is, however, to build a better
understanding of *why* things are done the way they're done,
even when it comes to things like for loops (kind of Andrei's
"improving at all levels" idea - note also that respected
authors spent pages in CUJ discussing how basic stuff like for
loops should be written, so I'm in a good company ;-) ).
Well, CUJ had to have something to put into its articles:-).
Apparently not well enough since they're now no more.
Seriously: if you're actually writing code, Pete had the only
correct answer. Stopping to even think about it costs
productivity, and may result in delays in the delivery of the
product. But of course, you're not actually writing code when
you post an article in this forum, and some meta-discussion
concerning what should be in the programming guidelines is
always necessary, in any project.
The paragraph above is contentless. "You shouldn't chat on the phone
while driving. But now you're not driving. So you can chat on the
phone." Obviously the OP meant to devise one clear solution that then
can be applied without fuss. To me, such things are very productive. I
acquire some idiom (sometimes as simple as a naming convention) and then
I don't need to stop a few seconds every so often to rethink things on a
per-case basis. Furthermore, I don't like Damocles' sword over me: "Is
this function important? What is important? Oh, wait, I shouldn't care
about that, I'm supposed to spend some unbounded amount of time later to
profile the code so I clean up the inefficiencies that I am
systematically entering now."
Second, I believe it's good to have an inclination towards thinking of
such small issues. As I mention in other posts, generally programmers
who don't care about that are sloppy at all levels. I conjecture that
the vast majority of programmers I've ever worked with would improve a
lot if only they only found the motivation to put some order in the way
they write code. Posts like yours demotivate such people and reinforces
their decision to dismiss such things as rubbish, when in fact small
coding issues are avatars of a larger sense of order.
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.
Andrei
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]