This poll was triggered by the frequently heard comments of non-Perl developers that follow along the lines of Perl code being obfuscated by definition. For mostly evangelical reasons, I try to make my Perl code understandable by the novice. Where ever I happen to be working, sooner or later, I start writing Perl code to assist with other development work. For example, even though I was brought on where I am now to do C++ work, the first code written was some Perl scripts/modules to parse and analyze the data in some 55,000 log files to verify if proposed changes would actually help the customer. As is typically the case, no one else in my group knows Perl. By writing well commented Perl that minimizes code combinations, eliminates implied variable names, and uses named variables as much as possible, I hope that those who look at the code will not be scared off, but realize that Perl code can be written, which can be understood by those not well versed in the language. While writing code this way may not be the most efficient in terms of processing, I feel CPUs are fast enough that the evangelical benefits outweigh the loss in processing efficiency. As an added benefit, this practice helps reduce the applicability of the last three poll items.

I posted "an experienced perl programmer", but I know there are cases where a lot of experienced perl programmers would probably do a double take. I try to code mainly for clarity, but that does not mean I stay away from "complex" techniques just because someone reading it might not know the ins and outs.

I definitely don't hesitate to use closures generating closures that get combined into another closure (for instance) if that's the "best" way to solve the problem. I would hate to solve that kind of problem using only "easy to understand" primitives.

What I mean to say is: some times, problems can only be easily solved (and understood) using relatively "obscure" techniques. If understanding the resulting code relies on the viewer knowing the technique, then that's probably still better than using "simple" techniques in a convoluted way which no-one will be able to understand.

I guess a factor in determining intended complexity may be the intended audience. For me, that audience is the non-Perl programmers who will inherit the code when my contract is over. Even though most of what I write is only for my use (that's how I sell it), I leave the code behind when I leave the contract, but with the hopes that someone else will look at it and try to use it. I want to make that use as easy as possible for them. If I were writing a module for CPAN with the intended audience being other Perl developers, the intended complexity level could safely jump way up.

I guess a factor in determining intended complexity may be the intended audience.

True.

I write most of my perl code these days for a client that wants me get the *hard* things done, and has the expertise to make sense of the code - at least, once I explain some things :) Most of my CPAN code is probably more straight-forward, just because the problems solved there are easier.

On the other hand, if I had to do the kind of stuff I'm getting paid for right now, and also had to cater to not very experienced perl programmers, I would estimate the most efficient use of our time would be for someone (or even me) to give them a really intensive course in advanced perl programming for a month or two.

IOW: it's not just the target audience, the problem domain is also important. Some things just can't be solved correctly or "maintainably" with only minimal skills. In those cases, it's better to try to raise the skill level (in whatever way suits the business).

Agreed. Adding my take to the "intended audience discussion", I expect that my co-workers have a solid grasp of Perl, so I don't shy away from using somewhat more complex Perl idioms.

Published papers in mathematics don't explain the summation symbol every time it comes up. If you have a degree in mathematics, you're just expected to understand it already. Likewise, there's no reason to limit yourself to a pidgin dialect of Perl (or any other language) if you're hiring good people.

"There is no shame in being self-taught, only in not trying to learn in the first place." -- Atrus, Myst: The Book of D'ni.

All my Perl code can be understood by the Perl compiler. Since the average computer has considerably less processing power than almost any tetrapod, my dog should be able to read and understand it. He can't, and I would be challenged six months later if it weren't for my habit of including a reasonable number of not too cryptic comments.

It all depends on the kind of code, and the intended audience. For CPAN modules, I try to optimize for performance if it doesn't hurt readability too much. This code can be understood by experienced Perl programmers.

For one-off quick hacks and oneliners, I don't care about readability and will use any technique that saves me from having to write much more code. This code can often be understood by people who are experienced in Perl. I will use ~~ instead of scalar.

For example code in documentation, I try to optimize for readability. However, I will continue to assume that the reader is at least comfortable with Perl. That means that I still do use statement modifiers and the $_ variable.

The Perl novice will have to find a way to plough through the first part of learning Perl: dealing with its sometimes exotic syntax. In some ways that is a barrier of entry, and keeps dumb and uninterested people away. It's not hard to learn how Perl works, there's lot of documentation to explain it. If you're learning Perl, you're only a real novice for a few days anyway.

I suggest that people who are not comfortable with Perl, should not be using it.

I spent years dumbing down my code so J. Random Neophyte could read it, understand it, and make changes. I found out the hard way that JR is an untrustworthy witless dolt who should never be allowed to use a computer. He turns off the strict pragma because it does nothing except stop perfectly valid code from executing, and thinks that testing is a crutch used by incompetent programmers who don't know what to expect from their own code. I don't want JR to feel comfortable "fixing" my "executable line noise". I want JR to go back to flipping hamburgers where he belongs. And to receive at least two painful burns each week. On his face.

The greatest threat to continued habitability of the planet is people who are convinced of their knowledge of things they've never actually learned.

Typically my Perl scripts are quite simple. I don't write scripts with packages, or object orientation, or things like map or grep, primarily because the scripts I write don't need any of that.

Some of the scripts I have written are currently being maintained by non-Perl programmers, so in those cases the scripts are even more simple. In those cases, any programmer should be able to read and modify the scripts for the given task.

Anyone comfortable with perl can understand my code. I'd like to spend more time making it pretty though and optimizing it, in the sense that I could actually make it more simple, like, "ohhh...that makes sense, wow that's nice AND simple."

Obviously that can't ALWAYS be achieved, but where possible, I'd like to do it more often.

Actually had a great object lesson in figuring out where my code could be better. My development machine went belly up on me a week ago, and because my office has been pretty ravaged by the flu, it took about a week to get a new one up and running.

Coming back to it afterward, there were quite a few places where I found I had to work through some code in my head. Needless to say, I've been spending some time getting those nasty patches in better shape.

When putting a smiley right before a closing parenthesis, do you:

Use two parentheses: (Like this: :) )
Use one parenthesis: (Like this: :)
Reverse direction of the smiley: (Like this: (: )
Use angle/square brackets instead of parentheses
Use C-style commenting to set the smiley off from the closing parenthesis
Make the smiley a dunce: (:>
I disapprove of emoticons
Other