in reply to In Need of Mentoring

Let me start by saying that I think you are at the right place (PerlMonks!) to find out answers & gather opinions about coding styles and what's new in the Perl world. You could even extend out to blogs, subscribe to Perl Weekly, or just keep an eye on what's just been released on CPAN (enable your CPAN nodelet under Nodelet Settings).

It's best if you trim your question on a particular style down to a simple SoPW post. Monks have varying opinions and perspectives, and sometimes the discussions will fill up the thread significantly. Better yet, search perlmonks.org for the question you're about to ask - many times I have found another monk has already asked the same thing. You could also post your code somewhere public (maybe on your PerlMonks scratchpad), and then have a link to it - but you may be creating more barrier with it being tl;dr.

So you've asked your question about 'style' and got answers. Maybe too many opinionated answers. I feel that the key to learning about recent 'styles' + new ways of doing things is to fully understand the shortcomings of the past and why people do it the new way. If you can gather the development motivation for, say, a new syntax for declaring constants, then it gives you a glimpse at the reason for the 'style' transition (i.e. peruse perldeltas/changelogs). Once you know why, then ask yourself whether the new way helps you. It it doesn't help, drop it; next question! Remember, form your own conclusions.

With all that said, now I'll attempt at bombarding you with my opinions about the questions you've asked so far :-)


parent is newest, lightweight, and recommended. I highly recommend reading the excellent latest Perl OOP tutorial by Dave Rolsky which explains OOP from the basics with modern Perl in mind.


You make it seem as though object-oriented is an evolution of procedural programming in the Perl world. I disagree. They're two distinct techniques that have their own merits; one won't replace the other. For me, I'd code my directory tools and throwaway scripts procedurally. Once I start to see the possibility of many functions acting on a single type of data, I'd consider whether it'd be worth switching to OO.


Your module requirement of 5.8.8 is absolutely fine. If you can support Perl 5.6, then great! There would always be people on ancient versions, but consider that most *nix OS distros are shipping "modern enough" versions of Perl (my guess: 5.10 and above). My gut feel is to draw the line right around Perl 5.8; that is, if you have to break your backbone to support 5.6, not worth the pain at all. Disclaimer: this is a moving gut feel.


I don't see much of that anymore. AFAIK, the recommendation is to use a float with 6 decimal places. You should highly consider your module for semantic versioning.


It doesn't matter. Pick the one you like stylistically and be consistent.

Replies are listed 'Best First'.
Re^2: In Need of Mentoring
by Anonymous Monk on Jan 16, 2012 at 07:24 UTC

    I don't see much of that anymore. AFAIK, the recommendation is to use a float with 6 decimal places. You should highly consider your module for semantic versioning.

    I never saw anyone mention "semantic versioning", and I think I know why, its absolute nonsense :) I can't tell if the idea has merit, its too hard to parse (compare to compare to http://www.json.org/ ).

    All I can say is, whatever numbering scheme you adopt, make sure the documentation renders the number redundant information. Note important changes in the docs and in some kind of CHANGES file.

[reply]
      Of course you can't tell the merit, you didn't parse it! :) Versions are versions, something you keep bumping up over time to show progression/improvement. Corporations try to make them look sexy.

      Semantic versioning is a recommendation if you haven't made up your mind yet for the format of your software version. In it, the numbers try to tell what changed in your software's public API.
[reply]
Re^2: In Need of Mentoring
by JavaFan (Canon) on Jan 16, 2012 at 10:06 UTC
    AFAIK, the recommendation is to use a float with 6 decimal places.
    It is? By whose authority? Does that mean Perl goes back to the 5.005 and before era, and the next version of Perl is going to be 5.016000?

    If you think there are good reasons to use floats with 6 decimals, by all means, state and defend your reasons. Don't hide behind weasel words like "the recommendation is".

[reply]
[reply]
      $ perl -le " print $]
5.014001

$ perl -le " print $^V
v5.14.1

.14 is 014
.1 is 001

      [download]
[reply]
[d/l]
        Other than showing Perl cares about backwards compatability, do you have a point?
[reply]
Re^2: In Need of Mentoring
by Anonymous Monk on Jan 16, 2012 at 07:28 UTC

    camelCase vs underscore_variables; for(;;) vs while (1) vs while () It doesn't matter. Pick the one you like stylistically and be consistent.

    FWIW, when it comes to both issues, I don't think consistency matters that much either :) It doesn't when reading other peoples code (too many different kinds of people), so it doesn't when writing my own (its all functionally equivalent )

[reply]

      If you're inconsistent with lexical variables like my($fooBar, $quux_xyzzy), then that's fine by me. It may slightly confuse people hoping to delve into your code, but that's probably only a small number of people.

      However, for public functions/methods - for the API you expect other people to code to - you should aim for consistency throughout a module or collection of related modules.

      Generally speaking under_scores seem to be the most popular way of naming functions and methods, so unless you've got a specific reason to use another naming convention, should be the default option. Good reasons to use camelCase or runtogetherwords might be:

      • consistency with a specification - for example, an HTTP library might name functions or methods after HTTP methods which are conventionally written in uppercase, so it migh make sense to name methods like $object->POST and $object->GET.
      • porting code from another language - if you've ported a library from another language, then it makes sense to keep the original case of function/method names. This allows your users to easily understand the documentation and examples of the source library and apply that knowledge when using your port.
      • inspiration from another language - perhaps your code is not a direct port of a library from another language, but aims to be a work-alike.
[reply]
[d/l]
[select]
      Oooo.. alternating between camelCase and underscore_variables in a huge class will be quite the sight to see :) To each her/his own: I believe in consistency in coding, which has served me well so far.
[reply]

        I saw it just the other day in Web::Magic 0.005, didn't bother me one iota. I have to lookup the documentation either way. Web::Magic

[reply]

In Section Seekers of Perl Wisdom