I think your goal is laudable. You'll find quite a few discussions on PM about PBP and several that come out generally against some of them. I'd sum up the overall drift as "most of the PBP points are excellent advice and would make the Perl world better and a few really just aren't but all of it is worth thinking about."

We have no standard at my workplace and I've only ever been in one shop that did (via a perltidy hook on commits). Currently we have a handful of solid hackers who have some disagreements about readability issues, etc. We do the "right thing." Don't futz with code style for the sake of your preferences; fit in with what you're working on. Do new stuff how you please with at least some consideration of maintenance for the next sucker hacker.

TheDamian is 10x the hacker I am but some of the advice is subjective and even silly. sub something{ is no better than sub something {. I adore unless and any construct that makes a line of code read naturally (unless(){}else{} is much less natural than do_this unless that). Inside-out objects are a waste of cycles unless you have one of the exceptionally rare real/defined need for them (client code hooks at a bank, for example). Contextual::Return is… a really cool idea and might have some Devel applications but I'm grateful I haven't encountered in a maintenance situation. The book pre-dates Moose.

The main thing I'd argue Perl has going for it versus most other languages for maintenance is its introspection and testing tools. Basic testing with Perl is trivial. Crazy/difficult testing is at least possible. Requiring all new code to be submitted with a peer reviewed test file and to pass a coverage (test and Pod) test and would probably do more for your shop's sanity than a style guide. It is also more objective than a style-guide--which is likely to contain at least a few arbitrary choices for the sake of standardization--so it could go down easier where personal feelings might otherwise cause resistance.

(Update: typo fixed.)

I'm actually a pretty strong supporter of keeping the style of the code you've been given. We've got old code and new code. Injecting new style into old code makes it harder to read and I think it's better to conform on that front. There are limits of course. There is simply too much old code with not enough tests to warrant running over the old style. Too easy to introduce bugs with large scale changes. That code gets the kid gloves treatment until we can define WHAT it does so we can fix it.

A standard I can point to at work that's been gone over and thought about is really something I hope we can get to.

--
meraxes

What parts of PBP (like the discussion on the modules recommended) are out-dated?

Please see the PBP Module Recommendation Commentary on the perlfoundation wiki. It contains many interesting thoughts, IMHO.

My last contract specified that I should follow the PBP coding standards, but not to which extend. Which I quite liked, because I have my own thoughts about their (non)sense, and it still allowed me to invest time in proper formatting and following coding standards :-)

(Of course such a vague formulation doesn't scale, but our contract was based on mutual trust too, and I may well end up maintaining my own code as a further contract...)

But of course our company has a coding standard:

• Write it any old how.
• Keep the warnings off.
• Don't ever touch old code!
• Tests? Forget them!
• Documentation? Why?
• Shared code? Nonsense! We've got copy&paste.
• Efficiency? Why bother? Memory footprint? Who cares? Safety? Never mind!
• Ad-hoc SQL with variables interpolated into the queries all over the place.

I'm leaving by the end of this month.

Update: And I'm looking forward to it!
Yeah the salary's quite OK, I would not have to work too hard, but OH MY GOD THIS IS DRIVING ME CRAZY!!!

Adding an overcomplicated formal process on top of a years old "slap it all together" project is ... a sure way to petrify the spaghetti bowl. It's just as messy, but much harder to maintain and much more fragile. I feel like Adrian Monk tied down in a messy room. With an old, noisy, smelly, friendly dog loosing fur.

I don't know Python and the tools available for it, but do questions like 'what is Python unit test support like', 'has Python a Perl tidy equivalent' and 'has Python a Perl Critic equivalent' focus attention in useful areas?

Some yes, some no. But mostly the selling point for Python is that there is a standard (PEP 8) and everyone (seems to) use it and it's easy to know what modules to use because Python comes batteries included.

Directly answering your questions: Python is growing a testing culture from what I've seen and the Python guys at my work are good with writing tests. Don't know much about the actual infrastructure though. My Python-Fu is in its infancy for the most part. Python really doesn't need a perltidy since their rules are mostly enforced by the significant leading whitespace.

Python doesn't have a Perl::Critic kinda thing that I'm aware of but we're not using that at work (yet) so it's a non-issue. Besides which, running Perl::Critic on old code is going to dishearten folk, not make them happier. It'd make me happier. That being said, the lack of use strict I see as a really bad thing not to have. One Pythonista told me today that it's a non-issue for him because he writes his code in Netbeans which highlights such things.

In the end, it's PEP 8 and the "clean syntax" that's winning hearts and minds.

--
meraxes

I've just had a read through PEP 8 and about 85% of it applies just as well to Perl (and many other languages) as it does to Python. Adopting PEP 8 with appropriate adjustments for Perl may be all that's required especially as then essentially the same coding standard can be used across languages (although that may not be what you want to hear).

True laziness is hard work

Besides which, running Perl::Critic on old code is going to dishearten folk, not make them happier

Take a look at Test::Perl::Critic::Progressive. It addresses the issue with having to maintain legacy code without it having to fail critic policies. Of course if someone goes in and starts changing that code the test will look at it and fail it if the new code does not support current coding standards.

It is a good bridge between legacy and new code.

everyone (seems to) use it

I beg to differ. It was mentioned at a Python conference I went to last year and hardly anyone had heard of it, let alone actually used it. Don't believe all the hype.

"The Zen of Python" (import this) is often quoted. The line "There should be one-- and preferably only one --obvious way to do it." (obviously a stab at Perl) is broken so often in Python 2.6 and 3.1 that it is getting to be a TMTOWTDI language. The "cleaness" is an illusion, is using triple quotes clean? Perl is honest about using sigils, but Python uses them as well, leading underscores mean different things, depending on how many and where they are in the variable name. It uses @ as a decorator sigil - different to Perl's use and Ruby's use. Of course without mandatory sigils you cannot have interpolation, so Python does not have that. The lack of curley braces means you cannot define a variable just for a conditional block, and you can't have a case statement. Actually, come to think of it, there is no way to just define a variable (see the requirement for Python 3 function nonlocal and the discussion in PEP 3104). Anyone who thinks the new format syntax is clear and clean has never tried to teach it to novices. Sorry, I'm ranting...

Superficially Python is a clean language, its just that when you stretch it then it is as dirty as the rest.

This brings many questions.

• Having standards is one thing. But how do you check if it's actually followed?
• What are your sanctions if someone breaks the coding standard? Say you have a coding standard of "3 space indent". What if someone keeps using a 4 space indent. Repeatedly. Even after being told. Do you fire him? Even if he's a good coder? Does your business benefit from letting good coders because of a whitespace war?
• Coders may already have the habit of following their own standards, crafted from their experience before they worked for your company, and from the work they do outside of your company. Now they have to break their habit (repeatedly, they still will follow their standard in their night-time hacking). Have you measured their productivity loss?
• Did you actually quantify the benefit of your coding standard? At the end of the year, how much more profit did your company made because of the coding standard? How did you measure that? If productivity really went up, did you let programmers go, because you now need less of them?
• If people can break coding standards, what's the point of having them in the first place?

Having standards is one thing. But how do you check if it's actually followed?

For the formatting, perltidy, for the rest, code review. Code review is on the rise in our company. Some teams use it for everything. Others, like my own, are moving very quickly towards it.

What are your sanctions if someone breaks the coding standard? Say you have a coding standard of "3 space indent". What if someone keeps using a 4 space indent. Repeatedly. Even after being told. Do you fire him? Even if he's a good coder? Does your business benefit from letting good coders because of a whitespace war?

I really see this as a non-issue. If they don't do it, it gets seen in review. If he's a good coder and the team is going to follow a standard but he refuses.... well then he's not a great employee is he? I've known good coders who were awful employees and they got let go. Coding skill rarely makes up for deficiencies in other areas.

Coders may already have the habit of following their own standards, crafted from their experience before they worked for your company, and from the work they do outside of your company. Now they have to break their habit (repeatedly, they still will follow their standard in their night-time hacking). Have you measured their productivity loss?

But we have many people of wildly different skill levels and wildly different styles. Productivity loss? I'm betting there will be one at the start, but as things settle down I have my doubts that it will be crushing. No one gets to do what they want to do all the time. It's a reality of employment. Hardly scientific but we can try and find out.

Did you actually quantify the benefit of your coding standard? At the end of the year, how much more profit did your company made because of the coding standard? How did you measure that? If productivity really went up, did you let programmers go, because you now need less of them?

Suggestions welcome. How do you quantify something like this? Has anyone tried?

If people can break coding standards, what's the point of having them in the first place?

If people can break laws, why have them? My viciously awful comparison aside, this still seems to me to be a poor reason to NOT do something. However, as we've started doing code reviews, it HAS helped us catch and fix things before they go out to production. Yes, it takes more time, but we have definately saved time down the line. Can't know till you try.

--
meraxes

For the formatting, perltidy,

Ah, so you have a coding standard with trivialities like how to format lines of code. (See my other post in this thread about why I don't like codified coding standards).

What are your sanctions if someone breaks the coding standard?

I really see this as a non-issue.

Strange. I see what you do when a standard isn't followed as one of the most important issues. It defines how serious a standard is taken.

If he's a good coder and the team is going to follow a standard but he refuses.... well then he's not a great employee is he?

I've heard that argument about wearing ties as well.

I've known good coders who were awful employees and they got let go.

About the use of whitespace? That's the example I'm using. I wasn't talking about not writing readable code. I was talking about not following the number of spaces the company standard dictates.

How do you quantify something like this?

Well, that was my question, wasn't? If you can't measure it, does it have a significant effect?

The think about programming languages like Python is that most don't even understand why they are good and for what they are good, they use it because Google etc use it. Basically where there is money people think the future of that project is always bright.

Python saw a major version jump, which gives an impression that some very big might have happened there. Actually its a modest revision from the three series. When I first heard Guido's talk about Py3K he says "He doesn't want to change the look and feel of language" and "Just fix the historical mistakes". So Py3K is not a very major semantic of syntactic revision. Their whole idea is to play safe rather than play correct

Whereas Perl put up a major fight, and they are making a very good product called "Perl 6". Although a little late, the emphasis is to make sure we do things right so that we can have a great future ahead. A little bit of time for a bright future should be easily acceptable, the long term benefits are great and the Perl developers have a good incentive when Perl 6 releases.

Above all Perl still remains a very beautiful language for a lot of problems which is Python is not suitable for. Another problem is that unprecedented growth of the "Web", has led people to believe that if some thing is not good for the web, its good for nothing. Which is not true.

If you rewrite you suffer for few years and if you don't you suffer for ever.Perl 6 is doing that!!! Hail Perl.

I am being clubbed to death by PEP 8.

• "Always make a priority of keeping the comments up-to-date when the code changes!"
• "When in doubt, use your best judgment. Look at other examples and decide what looks best. And don't hesitate to ask!"

A while back I wrote:

• On Coding Standards and Code Reviews
• Why Create Coding Standards and Perform Code Reviews?

Generally, Perl has come out of our coding standards effort looking very good. In particular, Perl::Tidy and Perl::Critic have proved to be excellent tools, unmatched by the other languages. For Perl, all new code must successfully pass through our tailored versions of Perl::Tidy and Perl::Critic before code review. Doing this avoids wasting time during the review arguing about trivia, such as code layout.

With a tip of the hat to kaizen, I suggest you set up a wiki page and encourage all team members to add to it during a code review, or at any time, when they find something that could improve the coding standard. That is, you need to create a vibe of inclusiveness with everyone trying to improve the quality of the shared codebase, not individuals fighting the standards police. And with a focus on real world things that matter, not trivia or dogma. The coding standard should be a living document.

To some extent, what goes into your coding standard reflects the level of your programmers. We have few Perl experts, many Perl part-timers, and some external contractors, so the sort of things that crop up here during code review (and then get added to our wiki page) may be trivial and inappropriate for an environment chock-full of Perl experts. Nonetheless, they are relevant to us because they actually happened (often repeatedly). I list below a couple of items to give you a feel for the sort of things that have cropped up here:

• Protect against metachars with \Q and \E where appropriate. To illustrate, /\d+ $nodename \d+/ should be written as /\d+ \Q$nodename\E \d+/ if the intent is to match the literal $nodename because $nodename may contain regex metachars.
• The use statement is performed at compile time, so putting one inside a subroutine is confusing. If in doubt, put all use statements at the top of the file.

Businesses definitely need to have some standards in place around coding, including guidelines (not laws) about indenting, and other questions of visual style.

Did you actually quantify the benefit of your coding standard? At the end of the year, how much more profit did your company made because of the coding standard? How did you measure that? If productivity really went up, did you let programmers go, because you now need less of them?

Suggestions welcome. How do you quantify something like this? Has anyone tried?

I guess one way to try and quantify this would be to think back at how much time was spent trying to remember what your intention was for various pieces of code before you then had to go and explain that same code to junior members of your team.

I remember several years ago, I wrote a code generating SED script, that I thought was really clever. It was virtually unreadable (all symbols, etc.) and contained zero comments. I didn't write it for production, but as a utility for my own use. It was cool and I was really proud of myself, but I would have deserved to be fired if I even thought about putting it into production like that. And if it were intended for production use, then I would not have changed a line of code, but I would have commented the heck out of it.

Where I found a lack of standards, I've tried to discipline myself - I've used a specific exit code pattern for abends such that someone else maintaining my code in the future could easily see the pattern and add a new abend exit code as needed.

I guess one way to try and quantify this would be to think back at how much time was spent trying to remember what your intention was for various pieces of code before you then had to go and explain that same code to junior members of your team.

Yes, but that falls in the category "don't use needlessly complicated algorithms". Useful, but hard to codify in a standard, and usually absent in any list of coding standard bullet points. Impossible to catch with Perl::Critic.

My rant is against silly things as putting in a standard than you should use 3 spaces for indentation, or 4. Surely you haven't spend much time explaining code to junior members who struggled with the fact someone used 4 spaces in an indent, and not 3?

I think the biggest problem I have with languages that propose forced conformance is that it is good code. Conforming to a standard is a first step, however it is not a good indicator of code quality. A good example would be Visual Studio.

Visual Studio is a neat product it that it provides many useful utilities for help you program. The code it helps you write can easily be used by other programmers on another machine. That does not mean the code is bug free or even well written. It just means it is meeting a particular benchmark established by someone.

Just because you march in a straight line does not mean you are headed in the right direction!

Speaking as someone who, as a matter of fact, "knows both languages quite well, thankye" ... I am never of the opinion that you will ever solve any real-world business problem by introducing another programming language into the mix.

If you write crappy code in Perl, then you will write crappy code in Python. And vice-versa.

Actually, the root cause of the problem is that people react favorably to software that is new, and they do not know how to properly maintain software that is old. Instead of learning how to do that, they simply want to sweep it away and start over.

You should immediately fire a programmer who advocates such a position. Every piece of new computer software very quickly becomes old.

If you are an undisciplined coder who writes crappy code, then you will do just that ... no matter what language(s) you are using. No characteristic of any language will keep you from doing that, just as no characteristic of any language will cause you to do that.

Personally, I find it far more important to have standards like "any database change should be inside a transaction" and "applications shall deal with signals sensibly" than whether an opening paren should be follow, or be followed by a space (or no space, or spaces on either side). IMO, if you think layout details like that are important to standardize on, you're saying to me that your productiveness is influenced by such details. But I think that if you find it significantly harder to understand code based on how spaces and parens interact, you shouldn't be coding. Go fry French fries instead. For instance, we all agree that indentation is important. But 3 or 4 spaces? Who cares? As long as it's consistent in the same block.

Note that by no means I'm saying people should mess around. Writing clear and correct code is important (the latter obviously being the more important one), but don't waste your time codifying unimportant things. And certainly don't base it on a book that's full of 'rules' which are either obvious, or smell like "it's two weeks to the deadline, I'm way off my target number, what I can come up with now?". Yes, it's PBP I'm talking about.

While sometimes coding policies can be nit-picky they can sometimes be very useful. One place I worked at had no coding standards either. The result was code that no one understood or could support. It was fairly common to have 1 subroutine to be 2000 lines! I repeat 2000 lines! What the hell!

I am not saying coding standards are going to everything, but without them, the quality can very greatly depending on the skill level of the programmer...

One place I worked at had no coding standards either. The result was code that no one understood or could support. It was fairly common to have 1 subroutine to be 2000 lines! I repeat 2000 lines! What the hell!

Yes, and?

Are you suggesting to solve that with a coding standard that says "No subroutine shall be more than N lines"? What should N be? 1000? 100? 10? 2? Does N include lines that contain nothing but comments? Nothing but white space? Nothing but an opening or closing parenthesis? What if the result of picking an N is that programmers start using nested maps on a single line, instead of multiline nested for loops, just so their subroutines fit in the N line maximum?

I can imagine cases where a single 2000 line subroutine is preferable over splitting it up. There are 10 line subroutines that should be split up in two separate routines.