Re: A refactoring trap

Actually? In this case I prefer the regexen without the x modifier. The regex /^\s*$/ is not long enough to require internal comments, the comment after the regex explains it fully. The addition of whitespace just spreads it out.

As opposed, of course, to potentially confusing regexen such as /\[\s*([^\]]+)/ which, I think, gained a lot of readability with the x:

/\[\s*  # literal [ followed by optional whitespace
(       # begin capture
[^\]]+  # get one or more chars that are not ]
)       # end capture
/x      # end regex
[download]

(note that this regex is part of a script at work where the future maintainers will probably not know regexen well, which explains the over commenting)

Comment on Re: A refactoring trap Select or Download Code

Replies are listed 'Best First'.
Re^2: A refactoring trap by Anonymous Monk on Aug 17, 2005 at 10:00 UTC
Does it really gain that much? I think commenting out a regex like that is just as silly and pointless as writing: `my $tmp = 0; # Make $tmp 0. $i ++; # Increment $i. print "hello"; # Print 'hello' to the screen.` [download] If I want to comment the regex, I'd write: `# Capture what's between brackets, # omitting leading white space. /\[\s([^\]]+)/;` [download] Because that documents the intent* of the regex, not the mechanics. Given the context, I'd probably even document what's between the brackets, and not just the fact I'm capturing between brackets, for instance: `# Capture the wiki-link. /\[\s([^\]]+)/;` [download] Now, that's useful, and you immediately know what to change if the syntax of the wiki-links changes. Where as your example carefully documents the tiny steps it takes, and not the overall picture. You might want to read Brian W. Kernighan, Rob Pike: The Practice of Programming*, which discusses correct commenting style as well. And there's no reason to assume you should use a commenting style for regexes that's considered bad style for other code.	[reply] [d/l] [select]
Re^3: A refactoring trap by Nkuvu (Priest) on Aug 17, 2005 at 16:55 UTC
Does it gain that much in this instance? Probably not. Commenting on intent is actually a nice way to put it, and one habit that I'm trying to break is commenting on mechanics. I've written a number of scripts for people who are not Perl-savvy, and they come back with questions on how this or that works. So for a long time I started commenting on every single regex on how it works -- because that's what people were asking about. These people are general C/C++ programmers, so I didn't get into the habit of commenting code like your first example, thank dog. So you have a very good point, and I'll add your reading suggestion to my list of books. I have some good habits, some not so good. I knew when I posted this that I might have comments about the style -- which is really what I want. Nothing like critiques of bad practices to break the habit.	[reply]
Re^2: A refactoring trap by ysth (Canon) on Aug 17, 2005 at 05:51 UTC
On the off chance that you really use your "potentialy confusing" regex, I will comment that it seems a little inconsistent to me. Can you tell me what it does (including what becomes $1) for each of: `"[ x]", "[ ]", and "[]"`? Is it what you wanted it to do?	[reply] [d/l]
Re^3: A refactoring trap by Nkuvu (Priest) on Aug 17, 2005 at 17:01 UTC
I should also have mentioned that this was a known-fragile regex to parse out some very specific files. The files in question are Matlab files that always have something in the brackets, but not always a leading space. I do have this commented in the actual script, I just didn't add the comment here.	[reply]


Keep It Simple, Stupid
	PerlMonks