From mboxrd@z Thu Jan 1 00:00:00 1970 From: Bernhard Bitsch To: development@lists.ipfire.org Subject: Aw: Re: perl code cleanup (was: IPFire 2.17 - Core Update 91 release schedule) Date: Fri, 12 Jun 2015 12:31:39 +0200 Message-ID: In-Reply-To: <1434058639.25208.245.camel@ipfire.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============2386208554256549497==" List-Id: --===============2386208554256549497== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hi Michael, > Hi Bernhard, >=20 > I am not really sure in what way this is related to this Core Update. I > guess it is not. >=20 You are right. I was just thinking about a post to the mailing list, when you= r annoucement about the new test release arrived. Because of the relation to testing, I posted my proposal in this thread. > On Thu, 2015-06-11 at 15:55 +0200, Bernhard Bitsch wrote: > > Hi, > >=20 > > a thread in the forum showed up a little issue in our tests. >=20 > Which one? https://forum.ipfire.org/viewtopic.php?f=3D22&t=3D13965&p=3D86585#p86576 When looking at the code of this web page, I found errors ( the standard lang= uage files are not used, "undefined" vars ) which are reported by switching o= n the debug output. =20 > > Some parts, don't know how many, just have a status of "untouched for a l= ong time". >=20 > Indeed, we won't touch the web user interface in order to clean up the > code if we do not need to. It has been a nightmare from the very > beginning since we forked the project. We never invested much into > cleaning up the code because there will be a complete rewrite of the > entire thing. Nevertheless there are possible errors or "issues" in this code. > That does not mean that we don't fix bugs though. >=20 > > This is mainly true for Perl scripts in the WUI. >=20 > Yes. Some other things have been replaced over time. The most recent > example is the setddns.pl script that was replaced by ddns. If we don't know the errors, they can't be fixed. My proposal reports those d= eficiencies. Even whilst testing phase this should be done. > > I would be a big effort to check all this files. > > But some issues will come in sight, if at least during test period these = files contain the lines > >=20 > > use strict; > > use warnings; > > use CGI::Carp 'fatalsToBrowser'; > >=20 > > Perl does tolerate so much dirty coding. In such cases it isn't sure whet= her the intentions of the programmer meet the interpretation of the interpret= er. > > These three lines force a check and log possible errors to the WUI. >=20 > I am not really sure what you are saying here. If you want to clean up > the code that would be helpful. Eventually we will have to update our > version of perl and we know that huge chunks of the web user interface > code are incompatible to that. I have never done any actual testing if > it works but we have many features in the code that have been removed. > There is for example the smart match operator. > A new version of Perl doesn't really help. The Perl interpreter is built arou= nd compatibility to older versions and coding styles. To achieve this assumptions about the semantics of the "dirty code" are made.= These must not meet the intention of the programmer of the original code. > > I fear, without these statements a couple of faulty test cases are report= ed as error-free. >=20 > Of course we cannot ship code that will show error messages to the user. This is an old discussion in software development: "Should the released code = contain checks for correctness ( 'assert' in C, 'use strict' in Perl, ...)?" My (personal) answer: Yes! Because these errors shouldn't show up in the ship= ped product, but the conditions proven are essential for a effective function= ing. > Those changes should be also very small so that they can be easily > reviewed and should not cause too much damage. It is just essential to > keep the development process tidy to not create an even bigger mess. >=20 In first application the addition proposed is small ( 3 lines per cgi file) a= nd doesn't change processing of programs without "issues". The corrections for errors shown may be of a greater extent. But they are nec= essary, thus the effort is legitimate. Bernhard --===============2386208554256549497==--