Abstract: I analyze why Perl is perceived an obfuscated language and propose a solution to that problem not compromising the richness of the language.
There is an obvious connection between the TIMTOWDTDI philosophy and the fact that Perl is perceived obfuscated. It can go three ways. First is that when the language is really powerfull than can write obfu. Second is that when the language is rich in constructions of simillar semantics people use just one of them mostly, and when they read code written by someone else then they need to get used to new constructions. The third is more psyhological - since the language is rich there is much to learn and it is simpler to just say that the code is obfu than to learn.
It seems to me that Perl 6 is even more rich language than Perl 5. Just name a language theoretical term and you have it in Perl 6. So the problem is going to be only worse with Perl 6.
Don't read me wrong - I really like the fact that Perl is such a rich language. There is much fun in constant learning New Ways To Do It and observing constant improvement in the way you code. Smaller programs means less bugs and better understanding of the code. So I really believe the richness is a Good Thing but the bad fame of being an obfu language has done much harm in the acceptance of Perl and we should cope with that.
Here is my proposal - something that could be useful for large projects. How about writing a tool that would report bad practices? What bad practices mean should be of course a variable - thus every project could suite it to its own convenience. For medium projects the tool would be less strict, for larger ones more, and each team could choose it's own style. I think it should rather report than not let to compile (like use strict) but it could be done variable as well.
And here is a beginning of the list of "bad practices" for large projects (I hope you will add your own):
- not using strict
- overlong functions (there could be exceptions like for long switch statements)
- breaking the encapsulation of objects (actually for me a read-write property of object is a more comprehensive interface than two functions, but each team should choose its own paradigm)
- abusing of $_ - like using it as a global variable or something
- to many global variables
- abusing of the <> operator
The tool shoul be usefull for refactoring as well.
A reference discussion can be found in this node: Why our company doesn't use Perl :(.
UPDATE: Style guidelines are nothing new - as the list provided by valdez shows. What I am suggesting is some tool for automatic checking of guidelines conformance, and I mean something flexible, and extendable as opposed to the great but fixed -w switch.
UPDATE: There seems to be a Parse::Perl project planned by Damian Conway. And there is the PPI library but unfortunately "Most of this is really broken, and put in CPAN for the benefit of the interested".
UPDATE:Perl::BestPractice |
Re: TIMTOWDTDI, obfu and analyzis of code
by valdez (Monsignor) on Mar 12, 2003 at 12:37 UTC
|
| [reply] |
Re: TIMTOWDTDI, obfu and analyzis of code
by crenz (Priest) on Mar 12, 2003 at 12:27 UTC
|
To do large projects, you will have to learn how to do large projects and intimately know your development environment.
That holds true no matter what language or environment you use. I think the real problem is that for big C/C++ projects, people tend to hire C++ software developers. For big Perl projects, they tend to hire "web designers" that learned Perl along the way. And then they are astonished that their codebase is messy...
The good thing about Perl is that you can do small and simple projects without having a lot of background in software development. The even better thing is that Perl will allow you to do bigger projects and actually have fun at the same time. But it doesn't liberate you from knowing what you do.
So learning about Perl "don'ts" mostly means learning about software development "don'ts" and Perl idioms.
| [reply] |
|
|
OK - you could use that tool to see who of the hired programmers is not proffesional.
| [reply] |
Re: TIMTOWDTDI, obfu and analyzis of code
by theorbtwo (Prior) on Mar 12, 2003 at 12:03 UTC
|
I don't see <> as being bad, but have more things for the list:
- Using BAREWORD filehandles
- Not checking for return values (IMHO one of the most important things about OO filehandles is that they force you to check for errors, pretty much -- possibly more important then timely closes and clean namespaces)
- Any module longer then a few hundred lines (should be split up when possible)
- Not using DBI when applicable.
- Not using CGI.pm when applicable.
- String eval, string do.
- Assigning to $_ without localizing it.
Warning: Unless otherwise stated, code is untested. Do not use without understanding. Code is posted in the hopes it is useful, but without warranty. All copyrights are relinquished into the public domain unless otherwise stated. I am not an angel. I am capable of error, and err on a fairly regular basis. If I made a mistake, please let me know (such as by replying to this node).
| [reply]
[d/l] |
|
|
$ echo >'|echo "Perl is my bitch"'
$ perl -ne 0 *
Perl is my bitch
$
but p5p seems to consider this a feature which stunned me into silence when I ran into it related to a patch I tried to write, Re: binmode for @ARGV (open.pm).
- tye | [reply]
[d/l] |
|
|
Oh, I was thinking <>, the file-reading operator, not the specific code <> (AKA <ARGV>). Tye, I can see their point, that it changes the meaning of existing code... but making it taintable, putting a warning in the docs, and making an optional and fatalable default-on warning are are certianly called for -- just not silently changing the behaivor. OK, possibly changing existing behavor to make the <ARGV> magic use three-arg open, but only with a BIG FAT WARNING and a pragmata to change the behivor back.
Warning: Unless otherwise stated, code is untested. Do not use without understanding. Code is posted in the hopes it is useful, but without warranty. All copyrights are relinquished into the public domain unless otherwise stated. I am not an angel. I am capable of error, and err on a fairly regular basis. If I made a mistake, please let me know (such as by replying to this node).
| [reply]
[d/l]
[select] |
|
|
|
|
| [reply]
[d/l]
[select] |
Re: TIMTOWDTDI, obfu and analyzis of code
by hardburn (Abbot) on Mar 12, 2003 at 15:23 UTC
|
I wrote a similar tool used internally by my employeer. It uses File::Find to look for files with a given extension. A list of wanted extensions is kept in a hash with the value being a referance to a subroutine. The sub can then read in the file data and do some checks on it. The sub returns a hash which contains the results of those checks. The culmitive data is then used to build some HTML, which is saved to a file and can later be downloaded by our staff.
There are some limits to what you can do. Perl is really hard to parse, so a full syntax checker is pretty much out of the question. Something basic like if(/^\s*use strict/) is the best you can hope for. Still, it's better than nothing.
----
Reinvent a rounder wheel.
Note: All code is untested, unless otherwise stated
| [reply]
[d/l] |
Re: TIMTOWDTDI, obfu and analyzis of code
by chromatic (Archbishop) on Mar 13, 2003 at 01:14 UTC
|
I have part of a bytecode analyser in progress. It's my intent to do something like the Stanford Checker. The next piece of the puzzle is matching subtrees. I have a good design, so it's just a matter of finding time.
| [reply] |
|
|
This is the first time I hear about the Stanford Checker. I googled verify.stanford.edu/SVC - but I don't see how it can apply here. Could you explain a bit?
| [reply] |
|
|
| [reply] |
|
|
