Reinier: Quite right!
Now... to recall my stated example:
for(int
indexOfAuthorInCurrentIteration=0;
indexOfAuthorInCurrentIteration<=authorsFromNameQuery.length;
++indexOfAuthorInCurrentIteration) {
Author currentAuthorBeingIteratedOver
= authorsFromNameQuery[indexOfAuthorInCurrentIteration]
// do something with the author
}
So nobody spotted it then? How about I try with a shorter form, perhaps a
little more obvious once the structure is exposed:
for(int i = 0; i <= authors.length; ++i) {
Author author = authors[i]
// do something with the author
}
Round about now, you should all be kicking yourselves for not noticing the
intentional mistake in the first place... I think this has quite
effectively demonstrated my claim that boilerplate obscures errors; and in a
real example with actual code, no less! (i.e. not just rhetoric)
On 25 October 2010 18:38, Reinier Zwitserloot <[email protected]> wrote:
> Isn't this fantastic? The "Author aa" part is just adding pointless
> confusion, but using 'i' as a loop counter is standard practice and by
> sticking to just 'i', those reading the code get a quick visual cue.
> In other words, shortening indexOfAuthorInCurrentIteration to 'i' is a
> significant improvement in readability. Not really because 'i' is
> short, though.
>
> Also, while descriptive variable names are important,
> "currentAuthorBeingIteratedOver" is silly. just "author" will be fine;
> by declaring it inside the loop, its context is limited to a single
> iteration within it, and thus the 'currentXBeingIteratedOver' part is
> implicit.
>
> Not stating the obvious aids readability. That's probably the biggest
> source of code readability you can find and covers both DRY violations
> and boilerplate, as well as overly wordy variable names.
>
> On the other hand, shortening 'author' to 'a' IS a pointless reduction
> and actively hurts readability, even if it is shorter.
>
> Neither wordiness nor conciseness are by themselves acceptable
> standards of code quality and readability. It's just not that easy!
>
> Interesting aside: When Microsoft and IBM decided to work together on
> OS/2, IBM firmly believed that length of code indicated quality, and
> thus measured everything in LOCs written. Naturally, IBM engineers
> added boatloads of boilerplate: Comments stating the obvious, saving
> the results of intermediate expressions to variables taken to an
> extreme, and other such practices that are very effective at inflating
> LOC while only hurting readability. They got better paid when they did
> it, what would you expect would happen?
>
> At the same time, microsoft was back then very much in the conciseness
> trumps all phase. You wouldn't expect it (during this time VB was
> released, which isn't exactly a concise language), but I hear from
> various people that worked there at the time that this was essentially
> true. Certainly measuring code progress by LOCs written was abhorrent
> to Gates and crew, and some have pointed the finger directly at this
> fundamental difference between the two teams for the flop that was the
> M$+IBM joint venture OS/2. M$ decided to cancel their original plan to
> phase out windows in favour of OS/2, bought a bunch of VMS talent, and
> started work on NT instead. IBM took over all OS/2 development, and
> the rest is history.
>
> On Oct 25, 3:26 pm, Augusto Sellhorn <[email protected]>
> wrote:
> > This is really bizarre, I've heard people say that fewer lines of code
> > is desirable, but this is the first time I hear somebody say that X%
> > fewer characters lead almost exactly to X% reduction in complexity!
> >
> > ---------------
> >
> > for(int
> > indexOfAuthorInCurrentIteration=0;
> > indexOfAuthorInCurrentIteration<=authorsFromNameQuery.length;
> > ++indexOfAuthorInCurrentIteration) {
> > Author currentAuthorBeingIteratedOver
> > = authorsFromNameQuery[indexOfAuthorInCurrentIteration]
> > // do something with the author
> >
> > }
> >
> > ---------------
> >
> > Nobody is saying you have to use super long names here, what you are
> > saying is that less characters more % reduction in complexity, which
> > leads to this
> >
> > for (int i=0; i <= aq.length; ++i) {
> > Author aa = aq[i];
> > // do something with the author
> >
> > }
> >
> > Which I don't think results in any % less chances of bugs, as a matter
> > of fact it ends up being less readable than some reasonable and clear
> > names that could have been applied.
> >
> > I hope in your code reviews you are not doing character counts and
> > blasting developers on these bogus measurements.
>
> --
> You received this message because you are subscribed to the Google Groups
> "The Java Posse" group.
> To post to this group, send email to [email protected].
> To unsubscribe from this group, send email to
> [email protected]<javaposse%[email protected]>
> .
> For more options, visit this group at
> http://groups.google.com/group/javaposse?hl=en.
>
>
--
Kevin Wright
mail / gtalk / msn : [email protected]
pulse / skype: kev.lee.wright
twitter: @thecoda
--
You received this message because you are subscribed to the Google Groups "The
Java Posse" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/javaposse?hl=en.
