Re: Best practice or cargo cult?

[ikegami]

in reply to Best practice or cargo cult?

Adhering to a programming style is a form of voluntary cargo cult programming. One adheres to a style to promote readability and maintainability through consistency. The style is not always completely appropriate in all circumstances, but that's a cost the adherant is willing to accept. As long as one knows when it's appropriate to break from the style, it's not cargo cult programming.

So the real question is whether the style was created with thought, or whether it was the result of cargo cult programming. In this case, there are merits to always using those switches.

• x encourages readability, the addition of comments, etc. at little or no expense.

• Using m intermittently requires more work on the reader's part to understand the meaning of ^ and $.

  As to choosing whether to always use it or to never use it, using it adds two new instructions to your regexp library ("match start of line" and "match end of line") at some expense[*].

• Using s intermittently requires more work on the reader's part to understand the meaning of ..

  As to choosing whether to always use it or to never use it, using it adds a new instruction to your regexp library at little or no expense. Where it could do "match any character but \n" before, it can now easily do the same ([^\n]) plus "match any character" (.).

* — I consider having to use \A instead of ^ expensive (in terms of readability), but I already find $ dangerous to use in validation.

[dsheroh]

I suppose I can agree that adopting someone else's programming style is a form of voluntary cargo cult programming, but I do not believe that assembling your own style by considering various options and choosing those which you consider to be the best for you would be CC (even if the end result happens to be identical to someone else's style).

As to the merits of always using the switches, they all come at the expense of changing the regex semantics to be different from the standard/default semantics. I do not consider this to be "little to no expense". When there are defined standards and well-known semantics, I find it much better to stick with them where possible and only deviate when needed rather than making deviation the default.

[ikegami]

but I do not believe that assembling your own style by considering various options and choosing those which you consider to be the best for you would be CC

Definitely. That's why I said "the real question is whether the style was created with thought".

they all come at the expense of changing the regex semantics to be different from the standard/default semantics.

"standard/default"? They're not the same. Personally, I use the modifiers only when needed. I need s more often than not, so my standard usage is with s, which is not the default. From what I see, when people don't use s on a regexp that uses ., it rarely would cause no harm to use s, and it's often an error not to use s.

When there are defined standards and well-known semantics, I find it much better to stick with them where possible and only deviate when needed rather than making deviation the default.

When there are defined standards and well-known semantics, I'd love to here about them. There's obviously differences in the standard usage of the modifiers (default vs Damian's, for example), and the semantics are far from constant.

[dsheroh]

That's why I said "the real question is whether the style was created with thought"

In that case, I misunderstood whose thought you were referring to and had taken you mean the originator of the coding style rather than the one using it.

When there are defined standards and well-known semantics, I'd love to here about them.

The defined standard is documented in perlre and the well-known default semantics are those which are used in the absence of any modifiers. There are certainly times when the default semantics need to be changed, thus the standard includes modifiers such as /s to alter them, but this does not change my original point that it is generally better to stick with the default (no modifiers) semantics where possible and only invoke modified semantics when there is a need to do so.

[Juerd]

and it's often an error not to use s.

It is, but never forget that it can also be a bad to use /s with .. Matching \n just like any other character is not always natural; this default for . is NOT arbitrary or accidentally introduced. It actually makes sense a lot of the time, and in fact, I encounter more line based data than data that's differently delimited.