[aklug] Re: perl lists question, sorting, sort of.

From: Arthur Corliss <acorliss@nevaeh-linux.org>
Date: Wed Aug 18 2010 - 13:55:08 AKDT

On Wed, 18 Aug 2010, Michael Fowler wrote:

> On Wed, Aug 18, 2010 at 01:25:30AM -0800, Arthur Corliss wrote:
>> Consistency is a big part of secure programming, Mike.
>
> I seem to remember a quote about foolish consistency somewhere..

Hobgoblins of small minds, yes. General rules are nice, but there are
always exceptions. In this case you caught me in a habitual idiom instilled
by code quality tools like perlcritic. When looking for patterns that's
more often than not exactly what I do want, so I do it by default. And it's
saved me more than a few times when my code comes up against unexpected
input. So it complains when I don't do it because I usually mean to, even
when I forget to because a specific test passes without it.

It's very simple, Mike. *You* may not like it, but it helps me. It fits
with how *I* parse things by default.

> You want rational, and you want an anecdote.. interesting. I shall
> share an anecdote, then. I was discussing a regex on AKLUG mailing
> list, and..

:-)

> The point is, you used 'split /\./sm, $s'. Were I to see this without
> the context of this discussion, this would be a red flag. I would have
> to spend extra time trying to determine why you used /sm when it has no
> effect on the existing code. Did you neglect something in your regex?
> Is the regex accomplishing what it should? What should it accomplish,
> anyways?

With your level of knowledge you should either a) acknowledge that it has no
impact on this particular regex and move on, or b) perhaps concede that some
people may ascribe to portions of Conway's Perl Best Practices and not take
it as a personal affront. I'm often tempted to add 'i' to it as well, I'm
sure that would have driven you even more nuts. I may start doing it just
as homage to you. ;-)

> If you used '/foo .* bar/sm', I would also have to spend extra time
> trying to determine why you used /m. Did you neglect an anchor? There
> should be a name for this sort of thing; anti-bug, perhaps. It makes
> you look for problems where there are none (maybe).
>
> Superfluous code, that is, code that is completely unnecessary, makes
> your intent unclear. This has nothing to do with convention, unless the
> convention is "throw code at it until it sticks." You may consider
> unclear intent a bugaboo, but it has real implications for debugging;
> nearly every day I have to dig into someone's source code trying to
> figure out what the hell they were thinking.
>
> I can give you an example of unclear intent leading me down the wrong
> path for quite some time. I was maintaining an e-commerce system
> written by an author I will not name. It was double-escaping HTML
> coming out of a database; when I looked at the code responsible, there
> was only one level of escaping. I assumed this was correct. I then had
> to dig through the rest of the code trying to find where it was being
> escaped again during presentation, but I could not find anything. I
> then had to expand the search to code not responsible for presentation,
> and found that the HTML was being escaped -prior- to being inserted into
> the database.
>
> The initial HTML escaping I had found was, arguably, the error.
>
> Perhaps not an example of superfluous code, but I couldn't resist using
> this as an example of unclear intent.

You need to add another another possibility to your limited set of
possibilities: that some people may ascribe to the use of quality control
tools that define defacto standards with should only be altered with good
reason. I want my regex engine to be more sed'ish, more line-oriented,
rather than merely string oriented by default.

It is what it is.

         --Arthur Corliss
           Live Free or Die
---------
To unsubscribe, send email to <aklug-request@aklug.org>
with 'unsubscribe' in the message body.
Received on Wed Aug 18 13:55:19 2010

This archive was generated by hypermail 2.1.8 : Wed Aug 18 2010 - 13:55:19 AKDT