in reply to Code for elegance, code for clarity

If I were you I wouldn't adopt that style. Don't use next for nothing :) I'd write something like this
sub csv_split { local $_ = shift || return undef; my @array; my $count = my $quoted = 0; while ( s/(.)// ) { if ( $1 eq ',' and !$quoted ) { $count++; } elsif( $1 eq q/"/ ) { $quoted = 1 - $quoted unless $quoted and s/^\"//; } else { $array[$count] .= $1; } } return @array; }
Yes, I know I like whitespace (look at that cascading unless).

I also wouldn't bother to write && except when needed (nothing wrong with and)

update: also, when all you want is to match, use m//.

MJD says "you can't just make shit up and expect the computer to know what you mean, retardo!"
I run a Win32 PPM repository for perl 5.6.x and 5.8.x -- I take requests (README).
** The third rule of perl club is a statement of fact: pod is sexy.

Replies are listed 'Best First'.
Re: Re: Code for elegance, code for clarity
by Roy Johnson (Monsignor) on Jan 12, 2004 at 16:22 UTC
    Your code is not quite equivalent. Note that if the unless fails, his code will fall through to set $array[$count] while yours won't. I think that's a bug in the OP's code.

    And for the OP, I think that reversing a Boolean is better expressed as $quoted = !$quoted rather than $quoted = 1 - $quoted.

    There's no need to be destructive with s///; all you need is to walk the pattern with //g, and there's no need to special-case the empty quotes. More efficiency can be gained by reading strings of non-quote, non-comma characters. The code becomes very clear, though the regex is a little complicated.

    sub csv_split { local $_ = shift || return undef; my @array = (); my $count = my $quoted = 0; while ( /([^,"]+|[,"])/g ) { if ($1 eq ',' and !$quoted) { $count++; } elsif ($1 eq '"') { $quoted = !$quoted; } else { $array[$count] .= $1 } } @array; }

    The PerlMonk tr/// Advocate
Re: Re: Code for elegance, code for clarity
by delirium (Chaplain) on Jan 12, 2004 at 14:45 UTC
    "next" makes a nice conceptual pocket (yes, I've long since been reduced to making up arbitrary terms). It trims down on the amount of nested conditionals, takes up less space, and makes (if not easier reading) for easier explanation to a third party.

    I'm not intending to debate the merits of the above snippets. Sure, they could be better optimized, use more community-approved idioms, etc. I'm proposing instead that it's OK to code to your audience, and to code with the intention of explaining your algorithms to a group of peers when time is at a premium.

    When left to my own devices without a timetable, my code becomes the nested and over-golfed hoo-hah posted at the top...which I enjoy tremendously.

    By the way, where are you proposing I use m// as opposed to what is already in place?

Re: Re: Code for elegance, code for clarity
by duff (Parson) on Jan 12, 2004 at 14:51 UTC

    It's always interesting to see how different people write code. Except for the weird use of s/// I would have written that routine in much the same way as delirium. It probably has to do with how I "grew up" as a programmer. For instance, being used to C/C++, it's more natural for me to write && than and so I tend to prefer the former over the latter (except, of course, for instances where && has the wrong precedence).