These are mine:
  1. Keep things simple.
  2. Layering/encapsulation and good API design are the keys to good programming.
  3. Too much abstraction is as bad as too little.
  4. Minimize code dependencies and specially temporal dependencies: I specially hate the case when you have an object that requires its methods to be called in a particular order and that is manipulated from different layers. Impossible to follow code!
  5. If you have to write some complicated piece of code, try to hide it behind and easy to use API.
  6. Code flow must be easy to follow.
  7. Perl is a powerful and expressive language, don't be afraid to use it to its maximum.
  8. Avoid code duplication. Don't copy&paste. Boilerplate is OK to a certain degree.
  9. Make your subs/methods meaningful.
  10. Try to avoid helper subs/methods with long lists of arguments.
  11. Don't use an object when a simple hash or array will do.
  12. Speed matters, scalability matters, memory usage matters, IO matters. Keep that in your mind while programming.
  13. When breaking some of the previous rules, document it.
  14. Check the validity of your input (specially when dealing with external input), refuse anything you don't know how to handle: Note that this does not go against the robutness principle, they are orthogonal concepts.
  15. Write regular expressions as strict as possible.
  16. Check for errors extensively. Don't ignore them.
  17. Include internal consistence checks.
  18. Add lots of debugging code so that you may be able to debug problems reported by others even when you are not able to reproduce them.
  19. Depending on an external module needs a good justification.
  20. use strict, use warnings, selectively disable them when required.
  21. No TDD, it gets on the way of my iterative design/programming thinking process (but if it works for you I am OK with it).
  22. Otherwise, testing is a very good thing.
  23. Be consistent in your coding style.
  24. And use a good editor that takes care of it for you: actually I don't care too much about cosmetics, as far as blocks are indented it is OK for me.
  25. Finally, paraphrasing the great Salvor Hardin, "Never let your sense of best practices prevent you from doing what is right!"

Replies are listed 'Best First'.
Re: Yet another set of Perl best practices
by toolic (Bishop) on Aug 24, 2012 at 12:43 UTC
    19. Depending on an external module needs a good justification.
    Re-inventing an optimized, well-tested, well-documented wheel requires an even better justification.
[reply]
      Providing functionality is a very good justification.

      But for instance, providing syntactic sugar is not a so good justification, in some cases it would make sense, in others it would not.

[reply]
Re: Yet another set of Perl best practices
by Anonymous Monk on Aug 24, 2012 at 12:35 UTC

    Make your subs/methods meaningful.

    Make your subs/methods names meaningful.

    Now if only there was a book of examples of each practice :)

[reply]
      No, I really mean the subs/methods, not their names.

      IMO subs/methods should do something specific, clear and easy to explain (at least, once you have a good vocabulary for the problem space at hand).

      Though, if you have problems naming your methods, it is probably a good indication that you are not doing that right.

      Maybe meaningful is not the right word here...

[reply]
[reply]
Re: Yet another set of Perl best practices
by grizzley (Chaplain) on Aug 24, 2012 at 13:37 UTC
    Why is this list called Perl best practices? Only 7, 11, 20 and maybe 18 is related specific to Perl. The rest is valid for any language.
[reply]

      Why is this list called Perl best practices?
      Good point. I prefer to have two separate lists: one for general programming practices, another for language-specific ones.

      The general, language-independent list tends to be the more important and interesting of the two IMHO. Most language-specific items, such as "start each file with use strict" or "use three-argument open and lexical file handles" are easily detected by a tool, such as Perl::Critic. The general list, OTOH, usually requires a human with good taste to adjudicate.

      The point that sound programming is mostly language independent was well made by chromatic in response to a reddit post extolling Python's "readability":

      Pray tell, how precisely does Python prevent you from using bad variable names? How does Python enforce good encapsulation? How does Python detect methods and functions that are too long? How does Python help you avoid poor coupling and promote wise decomposition? Does Python write good documentation for you? Does Python require comprehensive testing?

[reply]

        Oooh. Interesting.

        Imagine a compiler that rejects code with excessive cyclomatic complexity or too many SLOC. unless you add a pragma marking it as ok.


        TGI says moo

[reply]

      Why is this list called Perl best practices? Only 7, 11, 20 and maybe 18 is related to Perl. The rest is valid for any language.

      They're all related to perl since perl is a programming language :)

      Perhaps you meant specific to perl ?

      But even if they look specific, they all really are generic

      7. Perl is a powerful and expressive language, don't be afraid to use it to its maximum.
      write idiomatic code
      11. Don't use an object when a simple hash or array will do.
      Don't use an object when a simple struct will do
      Don't use an object when a simple data structure will do
      20. use strict, use warnings, selectively disable them when required.
      lint that mother hard, maximum warnings -Wall
      lint, "use strict";
      18. Add lots of debugging code
      use assertions, use logging
[reply]
Re: Yet another set of Perl best practices
by Anonymous Monk on Aug 24, 2012 at 20:04 UTC
    26. Don't use too much bold face in a posting.
[reply]

Back to Meditations