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
_______________________________________________
Koha-devel mailing list
Koha-devel@lists.koha.org
http://lists.koha.org/mailman/listinfo/koha-devel
