Re: Iterating over an array style question
On 11/24/2010 2:20 PM, Alex Mentis wrote:
Eric Sosman wrote:
BufferedReader rdr = ...;
for (String line; (line = rdr.readLine()) != null; ) // BZZZT!
Pattern patt = ...;
Matcher match = patt.matcher(...);
if (match.matches()) // BZZZT!
... and so on, and so on. Sounds like a silly school.
As for your code above, why not use:
BufferedReader rdr = ...;
String line = rdr.readLine();
while (line != null)
{
line = rdr.readLine();
}
That seems much clearer to me.
It also (1) gives `line' a wider scope than the original,
and (2) writes the same piece of code twice, giving subsequent
programmers a chance to change one without changing the other
to match. (1) could be addressed by introducing another block:
{
String line = rdr.readLine();
while (line != null) {
...
line = rdr.readLine();
}
}
.... or by rearranging the duplication:
for (String line = rdr.readLine(); line != null;
line = rdr.readLine()) {
...
}
.... but I see no way to dismiss (2) -- the more serious objection --
without relying on side-effects. (Or on throwing an exception to
break out of a "normal" control flow, which is also Bad.)
Your second example doesn't appear to have a side-effect, so I'm not
sure what your point is there. match.matches() simply returns a
Boolean, which is what is expected in the condition part of the if
statement. It's not checking a condition and also changing some
variable before or after it's done.
Quoth the Javadoc, "More information about a successful match can
be obtained by querying the state of the matcher." The updating of that
"state" is a side-effect of match.matches(). If you don't think so,
pray explain why all of match.end(), match.group(2), and so on behave
differently before match.matches() than afterward.
--
Eric Sosman
esosman@ieee-dot-org.invalid