The Problems of Perl: The Future of Bugzilla
after.fallout at gmail.com
Thu May 3 13:53:05 UTC 2007
Teemu Mannermaa wrote:
> If anything, we should extend these automated tests to catch more
> things we want to enforce.
How difficult would it be to create tests for code style with a tool
like perl-critic? Can we merge tests that others have written?
Is it possible to do things like type analysis in perl with tests?
Perhaps we need a more suitable structure for some testing. We could
probably get a good unit testing design if we were willing to do
something like this:
* In every directory with a perl script we would have a "t"
subdirectory. In that subdirectory there would be a file with the same
name as the perl script and a ".t" appended. We can dictate that every
function/sub has at least some tests to ensure it works (functionx must
have unit_functionx in the test script?).
* Rename what is currently the "t" directory in Bugzilla to
"designtests" ("t" should be unit/regression tests only) and
"runtests.pl" to "styleenforcer.pl"
* Create a script with a signature "runtests 'file.pl'" which would run
all tests on a given file and any dependant files.
* Create another script that would run all tests in Bugzilla.
* Make it known that any change to a part of Bugzilla requires new
tests, and reviews will be denied on the spot if they don't include test
> This could be why patches from known contributors seems to be more
> easy to review and accept. Or maybe they just don't know yet what
> objects, utility subroutines, filters and other ready-made items we
> already have and tend to "reinvent the wheel". If it's the latter then
> I don't think switching language helps at all. You have to learn these
> things for each project no matter what language they are written in.
Switching the language will not help in either case. I have been working
on asp.net in c# for a while now (with resharper to help with coding
style; everyone has the same configuration). I still end up fixing
problems with code design (person uses while loop where they should use
a foreach, 3000 line functions, ...).
> I don't know what patch writers think about our rules. For me that's
> not a problem as I don't know any other way. :) Besides, I thought
> they are based on globally accepted Style Guide of Perl.
I thought so too. Besides, this is one thing I really like about
Bugzilla. I have worked on other projects and just get lost when I try
and do something new because suddenly I am in another file with what
appears to be an entirely different language.
>> o It's very easy to make Perl code hard to read. It uses strange
>> variables like $_. It relies heavily on complex regular expressions. I
> True, but I don't think we have used much those strange variables.
> Isn't there supposed to be way to write Perl without using them?
The subject can be used for most elegant code as well. Most parts of
perl have their purpose and when used correctly can be very readable and
easy to understand.
More information about the developers