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