Ooh, you clever bugger. I'm glad I wasn't on the opposite side! On Mon, Oct 25, 2010 at 8:52 PM, Kevin Wright <[email protected]> wrote: > 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]. >> 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. >
-- 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.
