Re: The cost of unchecked best practices

The reason for the advice should be mentioned. Best practices exist because of real world issues that have come up again and again. In this case, the reason for the single-char class is because of changing requirements when using regexes as a parsing tool. The other regex best practices fall under the same category. If your regex changes so that now both : and ; are delimiters, then a single-char class is easier to maintain with a lower chance of error.

That's all best practices are - things that reduce your chance of error when changing code. It's no different than the C best practices that go into changing

if ( foo == 5 )
    call_function( foo );
[download]

into

if ( 5 == foo ) {
    call_function( foo );
}
[download]

Not much of a difference at first glance, but those "minor changes" took thousands of man-hours to coalesce and we ignore them at our peril. Don't blindly accept, but look deeper before suggesting a rejection.

My criteria for good software:

Does it work?
Can someone else come in, make a change, and be reasonably certain no bugs were introduced?

Comment on Re: The cost of unchecked best practices Select or Download Code

Replies are listed 'Best First'.
Re^2: The cost of unchecked best practices by amarquis (Curate) on Mar 20, 2008 at 14:29 UTC
I'll bite, why make that change? Is it so if you accidentally slip and use "=" you will get an error for trying to assign into a literal?	[reply]
Re^3: The cost of unchecked best practices by kyle (Abbot) on Mar 20, 2008 at 16:32 UTC
There are two changes there. One, yes, is to catch `s/==/=/` by making it an error (for Perl, that error is "Can't modify constant item in scalar assignment"). The other is to add braces. This is so that later it's easy to add another line that's within the branch. Otherwise, you might have this: `if ( 5 == foo ) call_function( foo ); call_other_function( foo );` [download] ...which actually means this: `if ( 5 == foo ) { call_function( foo ); } call_other_function( foo );` [download]	[reply] [d/l] [select]
Re^3: The cost of unchecked best practices by mr_mischief (Monsignor) on Mar 20, 2008 at 16:33 UTC
That's exactly the reason. Many people do the same thing in Perl, too, considering we use the same assignment and equals operators. Personally, I try to remember to do so during an initial version and I might make the swap if I'm already rewriting or refactoring code. I don't go through existing, working code looking for that and making the change. Changing something that's not in error is error prone in itself, and why take the time? Update: I completely missed the braces added at first. That's a good change, and it is another one I try to stick to in C and PHP (which have the same single-statement rule for conditionals) for initial versions. Still, unless I have some reason to change working code, I won't. When I change the code around that section, I'd probably go ahead and add the braces whether or not I was adding another statement. I wouldn't just go into the source and add the braces and not change anything else. As an aside, the "blue" language (as opposed to the "Blue" language, apparently) has a single-expression rule for conditionals. All of its conditionals are done using the 'condition ? true : false' operators common to C and Perl, with the false case being purely optional. I'd say braces (or parentheses) are the way to go there, too, unless you're working with a very short single-line statement.	[reply]