[Koha-devel] koha code cleaning bug?

Marc Chantreux marc.chantreux at biblibre.com
Mon Sep 29 16:42:59 CEST 2008


On Mon, Sep 29, 2008 at 08:49:00AM -0500, Galen Charlton wrote:
> for my $subdir (qw( lock register shadow tab key)) {
>   ...
> }

> i.e., please use an explicit loop variable instead of $_.  Otherwise,
> I agree with rolling these up into a loop.

as i said to Sebastien: in this case, i think it add some readability. 

do you think that:

for my $var ( list_generator ) {
    $var =~ /useless/;
    $var =~ s/old/new/;
    next unless -d $var;
    mkdir $_;
}

is more readable than:

for ( list_generator ) {
    /useless/;
    s/old/new/;
    next unless -d;
    mkdir $_;
}


? (it's a real question: i feel i can be wrong). I don't need to see the
for line to see, for exemple, that the substitution applies on the
current element of the list (and it's shorter to read and write). 

I think that be confortable with $_ (without abusing it) is a part of
the perl programmer skills set. If you don't, you'll never use such
usefull fonctions like grep and map.

perl 5.10 makes $_ lexical and add the (_) prototype. It would be sad to
not use it imho.

can this practice discuted with all developpers and added in the coding
style? 

> 1. If you're doing this sort of stylistic change, please consider
> writing test cases.

you're right but i'm not fluent with it. Any doc about that (in the wiki
or whatever?)

> 2. Unless you're revamping an entire module or script, don't mix
> cleanup (that theoretically shouldn't change behavior) with
> functionality changes in the same patch.

completely agreed: no idea to do it in another way.

> 3. If you fix a problem in one place, consider fixing it in all places.

all places in the file, right? doing it in every files of koha is a long
job.

> 4. The goal of a refactoring should be to improve clarity,
> maintainability, testability, or logical structure.  Please don't
> "refactor" just to show off your knowledge of Perl arcana;
> a newbie to Perl should have a fighting chance of understanding Koha's code.

don't worry: we feel the same about that. One of the reasons that leads
me to a code cleaning is that i think that koha can be more attractive
for contributors with a code that is more easier to understand. 

(that's why i'm for Template::Toolkit too)

> A generic code-cleaning bug is too vague; I suggest opening a bug for
> each cleanup, to remain open until all instances of that cleanup have
> been completed.

i though about it but it will open a large range of bugs. the only one
bug was just a proposal to limit the polution in bugs.koha.org.

regards


-- 
Marc Chantreux
http://www.biblibre.com
Expert en Logiciels Libres pour l'info-doc



More information about the Koha-devel mailing list