Beefy Boxes and Bandwidth Generously Provided by pair Networks
Perl-Sensitive Sunglasses
 
PerlMonks  

Seeking Best Practices - does your company follow a standard?

by meraxes (Friar)
on May 05, 2010 at 03:51 UTC ( #838442=perlmeditation: print w/ replies, xml ) Need Help??

The situation: I am being clubbed to death by PEP 8. Specifically, at my job, there are some well meaning but increasingly vocal folk who wish to abandon Perl for Python. The voices are being heard. I don't have any huge issue with Python... but I do prefer Perl and the idea of maintaining similar code in two languages seems wasteful especially when we already have a bunch of Perl hackers.

I am tired of being beaten about the head with PEP 8 and Python and "how clean" it is and "how easy to maintain" it is. I don't buy it myself. Sure, the code standard is set and the batteries are the same for each install of Python... but people still write bad, undocumented code. I've seen it. We need to show that there's just as good a business case for Perl as there is for Python.

Enter a co-worker. Tired of this, he spearheaded (and is driving) a movement to put together a coding standard for our company with the Perl. Google has'em... can't be all... evil. We have a place to start of course: Perl Best Practices. We're going through it, item by item, to see if it makes sense for us to use at our company. We are now a group of three (possibly four... not sure) doing this. We need to put together something we can sell to management. We, like many, have old code. Hopefully this means we can put together something useful. Create our own standards guide for our Perl code. If we can set a standard and people follow it (by enforcing it... thank you perltidy and Perl::Critic) it'd be nice to stop having PEP 8 thrown in my face all the time.

Business case aside, I agree it's needed. We have many Perl dev's of different levels. Some folk are coming to Perl for the first time... after being taught Python in our local Uni. I'm not looking to "convert" them... but it'd be nice if we could give them a better guide to start them off with than just staring at some bad Perl. In the end, I agree that getting everyone to conform to a standard (even one that not everyone will like... cause they won't) would help a lot of things.

Some of PBP looks a little long in the tooth or hasn't really been picked up by the community. Where do we go from here?

This is where I'm hoping some other monks come in. I've seen a page on the Perl5 wiki that talks about some potential problems/disagreements concerning the modules chosen in PBP. I also recognize that it's not universal (hey, this is Perl after all: TMTOWTDI). However, the "but sometimes consistency is not a bad thing either" part is something we want to get to.

This brings many questions.

  • Does your company have a coding standard/best practices list for Perl?
  • Has anyone ever released their standard out into the wild?
  • What parts of PBP (like the discussion on the modules recommended) are out-dated? For example:
    • Are any of you using inside-out objects? I never have... not sure I see the big hoopla.
    • I don't think that PBP's naming conventions are used in full all that often (specifically the (adjective_)*noun_preposition component of variable naming)... maybe I'm mistaken? But it looks good to me. I haven't used it but it seems like a reasonable thing to get in the habit of. Seems to make code pretty readable. Counterpoint?
    • I know PBP thinks unless is the devil. But I like it for postfix control flow. (i.e.  next unless defined $var) Now, if there's any logic whatsoever to the condition after unless, i think you should go with an if. Or is unless completely passé these days?
  • What's your .perltidyrc? Do most of you just stick to -pbp?
  • Did PBP leave anything out?

Don't get me wrong. TheDamian did a fantastic and wonderful thing with PBP that really brought this stuff to the forefront of the community as far as I can tell from my lurkiness in the hidden shadows. PBP made people talk and think which I think is good. However, I know it's a place to start, not the place to stop... or at least that's how it seems to me.

I appreciate that many of the PBP topics are touched on elsewhere but is this a discussion anyone is having these days? Any feedback, suggestions, discussion would be most welcome. I really just wanted some kind of barometer and an idea of what others are doing and what they think is a good idea. Hopefully I can incorporate this into the building of our standard.

--
meraxes

Comment on Seeking Best Practices - does your company follow a standard?
Select or Download Code
Re: Seeking Best Practices - does your company follow a standard?
by GrandFather (Cardinal) on May 05, 2010 at 04:17 UTC

    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?

    True laziness is hard work

      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.
Re: Seeking Best Practices - does your company follow a standard?
by Your Mother (Canon) on May 05, 2010 at 04:42 UTC

    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
Re: Seeking Best Practices - does your company follow a standard?
by Jenda (Abbot) on May 05, 2010 at 06:40 UTC

    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.

    Jenda
    Enoch was right!
    Enjoy the last years of Rome.

Re: Seeking Best Practices - does your company follow a standard?
by moritz (Cardinal) on May 05, 2010 at 08:02 UTC
    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...)

    Perl 6 - links to (nearly) everything that is Perl 6.
Re: Seeking Best Practices - does your company follow a standard?
by Anonymous Monk on May 05, 2010 at 10:37 UTC

    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.

Re: Seeking Best Practices - does your company follow a standard?
by Herkum (Parson) on May 05, 2010 at 19:33 UTC

    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!

Re: Seeking Best Practices - does your company follow a standard?
by JavaFan (Canon) on May 05, 2010 at 19:46 UTC
    The company I work for doesn't have coding standards. And I hope they never will. A few times, people have discussed getting some coding standards - but each time, those discussion quickly goes in the direction I always predict (and this has been true for other companies I worked for as well, whether they code mainly in Perl, C or Java): they forget about the important things and start with trivialities like layout nitpicks.

    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.

Re: Seeking Best Practices - does your company follow a standard?
by JavaFan (Canon) on May 05, 2010 at 22:19 UTC
    This brings many questions.
    I've some of my own as well. Targetted at those who have coding standards.
    • 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?
Re: Seeking Best Practices - does your company follow a standard?
by eyepopslikeamosquito (Canon) on May 10, 2010 at 22:20 UTC

    I am being clubbed to death by PEP 8.
    I've just read PEP 8 and am not impressed. There's too little substance, too many platitudes and stating of the obvious with gratuitous exclamation marks. For example:
    • "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!"
    If PEP 8 is your primary concern, you don't have much to worry about. :)

    A while back I wrote:

    Though we have specific coding standards for each language, our general coding standards document, similar to On Coding Standards and Code Reviews, has perhaps proved the most useful. Last night, for example, I used it to club some external contractors into fixing some basic issues with their code such as "The result of every file operation or API call or external command must be checked, and unexpected results handled". Things that matter, not trivia.

    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?

Re: Seeking Best Practices - does your company follow a standard?
by sundialsvc4 (Monsignor) on May 11, 2010 at 01:24 UTC

    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.

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: perlmeditation [id://838442]
Approved by GrandFather
Front-paged by Old_Gray_Bear
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others rifling through the Monastery: (5)
As of 2014-08-30 16:45 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    The best computer themed movie is:











    Results (293 votes), past polls