GNOME Bugzilla – Bug 776469
[PATCH] Modernize the Perl 5 code
Last modified: 2018-05-22 14:26:42 UTC
Created attachment 342453 [details] [review] The patch. The attached patch is my first attempt at modernising the tests' perl code. Some tests fail with it, but they do not appear to be my fault. For more inofrmation about modern Perl guidelines, see: http://perl-begin.org/tutorials/bad-elements/ The patch can be found as individual commits on this git/GitHub branch: https://github.com/shlomif/gnumeric/tree/shlomif--perl-modernization-and-cleanup I hereby disclaim any ownership of my changes and place this patch under CC0/X11L/LGPL-v2.1-or-above/etc.
Is there anything in there that isn't just substituting one man's perl style for another?
Hi Morten, sorry for the late reply. (In reply to Morten Welinder from comment #1) > Is there anything in there that isn't just substituting one man's perl style > for another? Well, first of all, I should note that I just got started in cleaning up the Perl code and tried to handle some of the low hanging fruit. Otherwise, the Perl online community has been trying to encourage Perl programmers to avoid bad practices and to settle on the so-called "Modern Perl" style (see http://modernperlbooks.com/ ), which is a difficult job as there are a lot of bad and/or old Perl 5 codebases and tutorials out there. There was some discussion on why dedicating some time to modernising and cleaning up code is important here: * http://shlomif-tech.livejournal.com/37969.html * https://szabgab.com/what-does--if-it-aint-broke-dont-fix-it--really-mean.html It is bad practice to use leading ampersands in subroutine calls - http://perlhacks.com/2015/04/subroutines-and-ampersands/ . As I wrote in a different context - https://en.wikibooks.org/wiki/Optimizing_Code_for_Speed/Factor_Optimizations#Are_.22Small.22_Optimizations_Desirable.3F - it is important not to dismiss small improvements in code quality, because they may eventually add up to something more significant. One also risks deterring or demotivating a contributor by rejecting their patch.
Ping!
> Is there anything in there that isn't just substituting one man's perl > style for another? It really comes down to that question here. The perl code is written using *my* perl style and has several things going for it: * I like it, obviously. I am an old fart, and I am the one who generally mucks with the code. * It plays well with Emacs syntax highlighting, something that isn't quite true for the style you are proposing. Given perl's general lack of static checking, that is very important. I *know* that the perl guys have been recommending "no &" for quite a while. They are perfectly welcome to do that, but if I can't get the same support from the the relevant tools, Emacs really, then I'll stick to the old perl motto of "there's more than one way to do it". If we aren't fixing bugs, then this is about the same as arguing over where to put braces in C code and much to indent. Nothing good has ever come out of bringing that up.
-- GitLab Migration Automatic Message -- This bug has been migrated to GNOME's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/gnumeric/issues/308.