in reply to How to make a progress counter for parsing HTML with HTML::TreeBuilder

Spotted at a glance.

$filetell += length $filec should be $filetell += length $buf of course, but the interesting part here is: how did I spot it?

Well, you say my $filesize = length $filec and are repeating yourself (code smell!) calculating length $filec in a loop, in which $filec doesn't change: that's nonsensical. Only after these findings did I fully grok the program (i.e. fully compiled it in my mind) and concluded: "that should be $buf".

And that's a good point for "peer programming" - since we write programs in different ways, we also read code in different ways (TIMTOWTDI applies also for reading), and thus are much better at spotting bugs by others than bugs perpetrated by $self.

perl -le'print map{pack c,($-++?1:13)+ord}split//,ESEL'

Replies are listed 'Best First'.
Re^2: How to make a progress counter for parsing HTML with HTML::TreeBuilder
by ambrus (Abbot) on Oct 31, 2014 at 17:55 UTC

    But

    $filec does actually change in that loop: the four-arg substr removes pieces from it destructively. If it weren't so, the loop would be infinite.
[reply]

      Erm... yes.

      Dinn' parse that substr as I should've done. Anyways the result of that substr is what should be added to $filetell, neither the length of the original string, nor the remainder. Sometimes a bug is spotted even without reading the whole surroundings (completely||correctly).
      perl -le'print map{pack c,($-++?1:13)+ord}split//,ESEL'
[reply]
[d/l]
Re^2: How to make a progress counter for parsing HTML with HTML::TreeBuilder
by GotToBTru (Prior) on Nov 03, 2014 at 15:33 UTC

    I was distracted by the 4 argument substr "bug". I had to update my desk reference which did not mention that option!

    1 Peter 4:10
[reply]

In Section Meditations