At 9:41 AM -0600 11/22/96, Dave Wolfe wrote:
>[ Brent Chapman writes: ]
>>
>> Right idea, but not an ideal implementation. For starters, I'd change the
>> "split" line to
>> @uptime = split(/\s+/);
>> in order to make it less sensitive to the exact spacing of the numbers.
>
>JFTR, in describing split the Camel says:
>
> "If PATTERN is also omitted, the function splits on whitespace,
> /\s+/, after skipping any leading whitespace. [...] As a special
> case, specifying a space (" ") will split on whitespace just as
> split with no arguments does. Thus, split(" ") can be used to
> emulate awk's default behavior, whereas split(/ /) will give you as
> many null initial fields as there are leading spaces."
>
>(As well as null fields for multiple spaces.) So split(" ") and
>split(/ /) are *not* equivalent and split(" ") and split(/\s+/) are
>nearly equivalent except for leading whitespace, although by referencing
>the array relative to the tail, the distinction is moot in this case.
Oh, I _hate_ it when Perl gets "smart" like that... I'd rather code it
clearly (split(/\s+/)) than count on somebody to know that " " is a special
case kinda-sorta-but-not-quite the same thing.
While I'm up on my soapbox about Perl programming style, let me mention
another Perl-ism that I hate: conditionals following code bodies. That is,
things like "{ <code> } if ..." and _especially_ "{ <code> } unless ...".
<CURMUDGEON>There weren't any goofy constructs like that in Majordomo when
I first released it; they've all been added since then by somebody else,
and I don't like 'em!</CURMUDGEON>
In all seriousness, though, there is a code maintenance principle that,
when working on existing programs, you code in the style they were written
in, even if that's not precisely your own style. Introducing new styles
only serves to confuse folks who come along later, and don't know the new
code from the old. This applies to all sorts of things; control constructs
like those mentioned above, variable naming, variable scoping, use of
globals, function naming, package organization, indenting conventions,
commenting conventions, ... Consistency in all these "style issues" makes
code easier to maintain.
I haven't been paying close attention to the discussions regarding 2.0
development (I keep intending to go back and read them someday), but I
think that this issue of coding style is something that needs to be
addressed right along with all the other logistical aspects of the project
that you've been discussing.
-Brent
----------------------+----------------------------+------------------------
Brent Chapman | Great Circle Associates | 1057 West Dana Street
Brent@GreatCircle.COM | http://www.greatcircle.com | Mountain View, CA 94041
----------------------+----------------------------+------------------------
Internet Tutorials from the Experts!
Follow-Ups:
References:
|
|
