You could:

• Try to help them understand why you would rather use strict and warnings. (Of course, this means you'll need to know that.)

  I doubt "Because the Perlmonks say so" will be entirely sufficient. If you can demonstrate a business case, one outlining the benefits for detecting common mistakes early and so forth, you should be able to make headway. Most bean-counter types understand better return on the investment.

  Perhaps you could propose a test scenario, one comparing your current practices against the results of using strict & warnings. If it works, then you'll have something concrete to work with.

  Also, it may help to propose a transition plan, one that updates your legacy code over time. That can be an effective way to rewrite stuff without slowing down the entire process.

• Use strict and warnings to develop your contributions to the project and then deactivate those before turning it in. I'm not too fond of that idea myself, but at least your work gets some benefit.

• Failing the above, put up with it until you find a position with a more enlightened organization. (I'm not sure it's productive to be in a place where you're marginalized for wanting to use better coding practices.)

As far as programming Perl if you're conforming to the (sub)standards they demand, I don't see why not. It's still Perl and you're still learning something about it. Just keep learning the best practices on your own and be ready to move if there's an opportunity.

--f

As far as programming Perl if you're conforming to the (sub)standards they demand, I don't see why not. It's still Perl and you're still learning something about it.

I just want to second this advice. So often, what I hear instead is along the lines of "Just throw up your hands, yell 'You people are so clueless', and stalk out in a huff."

adamsj

They laughed at Joan of Arc, but she went right ahead and built it. --Gracie Allen

I think we've all seen this requirement before over and over again. Particularily when we work in multi-faceted teams where everyone comes from a different background and learned the language for various reasons.

My current contract is an investment bank with serious in-house perl experience. Yet the team where I am had never even heard of strict as a concept, did not use -T or -w, did not use any OO methods, did not have a working perl debugger working, and used CGI by seeding print statements throught the subroutines.

When I started here, I was appalled. I thought I had regressed to babyperl (thank you, monk who used the term on the CB yesterday, I'd give you credit if I knew who you are). Quickly I adjusted to the new problems I had to deal with, such as living in fear of scoping problems and willy-nilly use of local to make up for the lack of strict.

Here is the philosophy I approached in this case to cope with the situation:

I am a contractor employed to:
1. do what the client wants me to do within some ethical bounds
2. add value to the price my client pays by providing the greatest amount of features possible.

Point 1) helps me remember that the client needs to be able to understand my work - like posting Monk is facing.

Point 2) helps me remember that it is sometimes a good thing to warn the client of the dangers of such behaviour as not using strict, and of the increase in effectiveness and portability that the client will enjoy from improving the team's adherence to general standards.

After 9 months on the job, we have finally managed to convince the group's manager (retired perl/sql coders) that better behaviour was good for everyone, and we now have fully strictified templates, and even managed to teach these old dogs about the benifits of templates and OO design.

Summary: We need to do what our managers want us to do. If there is a better, safer, smoother way to do it, we need to give a meaningful defense for that method, and see if we get a bite. But in the end, IMHO, we need not to try to force our own concept of standards down the throats of uninterested people faced with thousands of lines of well spaghetti-ized legacy code.

Hope this little story helps.

--Hackmare

However my best advice is to define a subset of Perl that you think allows you to program Perl well which you also think you could teach fairly quickly. For me that list would include scalars, arrays and hashes. Basic programming constructs I would insist on include functions, foreach, my, and package. I would insist on the basic array operations, push, pop, shift, and unshift. I would include simple REs. The global variables $_, @_ and $! would be acceptable. I would be willing to use wantarray wisely, with it being my responsibility to put scalar at places where something is used in scalar context but a beginner might not realize it.

To that I would throw in the semi-magical invocations needed for use, strict, vars, and exporting a function from one namespace to another with Exporter. I would add perldoc to the requirements, and say that for some set of modules that the public interface as documented in the documentation is fair game. What set of modules depends on what you are doing. And it would be allowed to write your own perlpod documentation inline.

Stop.

There is a lot missing. An awful lot. But the above list is enough to program fairly cleanly. It offers constructs to keep life sane. It offers options to reuse existing wheels. It is powerful enough to keep you productive. But it is still a list that that you could bring someone up to speed on fairly fast. It does not offer many major conceptual barriers for someone who does not have your background. There is enough room there to work on your programming style.

Now what is missing? Well references. Objects. Slices. Closures. Typeglob games. Most of the special variables. The intricate details of pack. Complex RE tricks. The need to know most of the precedence table. (Use parens.) And so on.

Can you convince them of this compromise? I don't know. You can try. I think you have a chance. I was in a vaguely similar position. I voluntarily did something like that, and it worked well. So well, in fact, that we are using a lot more Perl than we used to. It also helped that I later got to help train several co-workers.

But even if you cannot get everything on this list, look on the bright side. It is a perfect chance to go out and pick up books like Code Complete or the Pragmatic Programmer and learn about how to write better code. Most what you can learn about clarity of code doesn't need a lot of language features to apply, and is darned useful...

On the other hand it might be looked at as motivation to polish your resume a little...

Hello, utopian.. I wish I could say your crisis is uncommon, but in my personal experience, I've faced a similar challenge...

There are some things that you can do.. not all of these are related to programming Perl, obviously, but have a bearing on your workplace environment (dare I say politics) as well...

Firstly, ask yourself (and your managers) about why you need Perl.. Obviously, there is a situation in which Perl seems to be a good fit to solve a problem.. in that case, you should use Perl to its fullest capacity, or risk reducing it to the level of C or Java or any other language... Most people pick Perl because it has something to offer that not too many other languages do... if you always have to contort Perl to be understandable by a person familiar with another language, you're probably negating the reason for picking Perl in the first place....

Further to this point, -w and use strict, among other things, are part and parcel of the language.. would these people contemplate writing Java without using the class libraries ? of course not... the same situation applies here.. I think that a break with a bad tradition is a good thing, and to support not using these useful language features merely perpetuates bad practices...(I temper this by saying that I share your pain with regard to non strict compliant code... converting all of it hurts.. :o)

The next point, these restrictions may be put in place because no one else in the organization knows Perl yet (and they worry about having another person maintaining your code).. Good code walks and peer review sessions can go a long way towards easing those barriers to entry for a person new to programming (for Perl or any other language)

In answer to your final question, even baby Perl is still Perl... use strict and -w are, after all, merely coding practices that make life simpler and easier for you, the programmer... there is nothing in Perl that prevents you from writing entire production systems without these or any other features... that is one of the good things about Perl, it doesn't dictate the way you should write your code (just try coding any which way you want on Pascal or Modula-2, for example...). If what you want to be doing is writing Perl, then you can still learn a lot, despite these restrictions.. (one of the dumber restrictions I had to deal with earlier was that I couldn't pass a variable number of arguments to a sub.. I always needed to fix the number and have a prototype... just to give one example)..

I have no doubt that once the persons in charge see what is Perl (and you!) are capable of, they'll be willing to give more autonomy in coding practices... Its a hard road, I know... but there are very good reasons for using all the features that you mentioned as being on the no-no list, and with time, it shouldn't be too difficult to convince management of your case...
Good luck..!

• Well designed objects make your code look easier, not harder, because you can code a high-level interface that hides the complexity of what lies beneath.
• You can then surround your code with lots of comments. I use a colorizing editor which greys them out, including when you print. The contrast makes the code look very clean.
• Use variables everywhere, especially with meaningful names, rather than implicits: $_ and the like. Unobfuscate your code to the point where, though not self-documenting, it is at least highly readable, especially in the context of its comments.

I'll second the part about not using implicit variables. I do this for my own benefit as well, as I am inexperienced enough that I don't always understand what they're going to do.

If you can't get away with any object-oriented stuff, try putting must of your functions in subroutines. That way the main part of your program will just be a series of subroutines:

&get_field_ids();

&get_field_values();

&build_message();

&send_email();
[download]

If you name the subroutines well, it should be reasonably obvious what's going on, especially if you add comments.

Chumley

"What are the facts? Again and again and again--what are the facts? Shun wishful thinking, ignore divine revelation, forget what 'the stars foretell,' avoid opinion, care not what the neighbors think, never mind the unguessable 'verdict of history,' -what are the facts, and to how many decimal places? You pilot always into an unknown future; facts are your only clue. Get the facts!"
-- Lazarus Long

I strongly disagree not using the implicite variables (mainly $_ and @_, but also @ARGV, ARGV, STDIN and STDOUT). Using them all the time adds needless clutter in your program, making it harder to find out what's going on. Do you really think:

    @foo = grep {$_ =~ /qux/} @bar;
[download]

reads better than

    @foo = grep {/qux/} @bar;
[download]

It doesn't mean you should always use implicite variables, far from that. But never using them is like writing shell scripts without using pipes.

-- Abigail

What your boss can or cannot understand is totally subjective so I am afraid you will have to argue each feature with him. You can start with the kind of "baby Perl" that he has defined and try introducing new features slowly, showing him how they work and why they are useful, maybe by writing snippets 2 different ways, one that conforms to the current directives and a simpler (and obviously easier to understand) one which introduces a new feature.

This way not only will your boss learn more Perl but you will learn how to teach it.

One thing I would definitely not compromise on would be the use of strict and -w though. These make the code safer, cleaner and easier to read. Declaring a variable (and initializing it if need be) is the perfect place to comment its role. And I really don't see how they can be described as making the code more complex. What part of my $total=0; does your boss not understand? Especially if written as:

Tough spot. Sounds like you're being micro-managed by an insecure superior. The tough guy in me would ask the manager "Who's the programmer here, you or me?" but the older I get, the less often I listen to that voice.

Maybe I'm cynical, but I doubt this situation will improve for you. You'd probably be better off looking elsewhere before things get worse and you find yourself saying and doing things you'll regret.

My editors rarely expect me to write English such that a person who speaks only Mandarin could understand the point of my book or article. (I find the argument that "Perl is hard to read" similarly toothless.)

tilly and Abigail and many other posters are correct. You should establish what the coding standards are and work within those. I hope your company encourages good communication between programmers such that you can learn from each other.

I would rather have one new programmer willing and able to learn than ten seasoned programmers unwilling even to ask me what my latest idiom means. Any organization that treats its programmers like stagnant morons will soon retain only people who refuse to learn.

You can write staggeringly useful programs in a small subset of Perl, but rare is the program over 50 lines that can't be improved with hash slices, for example.

If you have to, be subversive. Show your fellow programmers another way to do it, and say, "Here is what it does, here is why it is better, maybe we should consider it." It's subversive because you're teaching them and appealing to a hopefully-just-dormant sense of curiosity.

Best of luck.

It sounds like the company is established though, due to the exsitance of "magical" legacy code that must not be touched. If you've been there a while and have built up some respect, have a go at it -- you may convince them. I was in a job once where I didn't, no matter how hard I tried, and it was a long painful lesson.

FWIW, there is nothing wrong with writing code that a beginner who has never coded before can understand -- as long as the code is about 20 lines long. Complex problems generally require complex solutions (unless they're already on CPAN), and inexperienced beginners won't understand them even if you've written them in the academics' choice of Pascal or some form of pseudocode.

Penny-pinching (pound-foolish) companies will meet their doom before too long, hopefully your's isn't. The company I was at died a meager death.

Dumbing down to the lowest common denominator, however, isn't very useful in my opinion. Personally, I would refuse to work under the rules laid down. Not using strict or -w could be circumvented for a while; just develop your code with use strict; and use warnings 'all';, and just before checking in, change the use to no, but that breaks down as soon as someone else touches your code, or you have to work on someone elses code. Most of the other rules are downright absurd.

I would step to the manager and declare that apparently she has hired a big bunch of people not up to the task (programming Perl), and that I will not dumb down to their level. For me to be useful, I will have to work with peers - not morons. Depending on her reaction, I would seek work elsewhere. Be it in the same department, same company, or at some other company. I would make it clear to her she carries responsibility for hiring incompetent people, and that I don't have any qualms in venting that opinion to her boss. In fact, I'd probably state this in email, Cc-ed as far up the chain as appropriate.

The success of this of course depends on your reputation/experience, your salary (the more you get paid, the less eager they are to have you perform suboptimally) and the power of the manager.

Of course, there's always the difference between theory and practise. What will they do if you write quality code, breaking the coding standards? Fire you? On what grounds? And then don't forget that rm is an excellent debugging tool - specially if you have to debug someone elses code.

-- Abigail

And then don't forget that rm is an excellent debugging tool - specially if you have to debug someone elses code.

This is great advice. I wish I'd had the nerve to take it back when I needed it.

adamsj

They laughed at Joan of Arc, but she went right ahead and built it. --Gracie Allen

My sympathies - I have been in a similar position in the past, and found that no amount of "dumbing down" of my code made it possible for the uninitiated to make sense of it.

In fact, in the long run, it resulted in a poorly coded app that behaved like one, and that _still_ did not meet the requirement of "understandable by intellectually superior graphic designers" ;^)

all jabs aside, your issue, like mine, is really not one of meeting an unrealistic expectation - it's an issue of trust.

Your employer doesn't trust you to write good code - and expects you to generate only code that he can proof for him/her self. You really have a limited number of choices.

1. put up with it and draw the paycheck
2. quietly look for a job working for more intelligent people
3. screw the requirement and write code so brilliant there is no option but to use it (even if it does look like wizardy to your boss)

For me, I ended up losing the job. It was financially painfull, but I became able to speak and to sleep again - It was really in my best interest in the long term.

Do yourself a favor and find yourself someone to work for who is in possession of a brain. It is doubtfull that this person will ever come to trust you to do your job if s/he doesn't now.

May the manifold blessings of Eureka! visit you often- BrotherTwitch