The Problems of Perl: The Future of Bugzilla

[Bill Barry]

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 
cases.

> 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.