Beefy Boxes and Bandwidth Generously Provided by pair Networks Joe
Keep It Simple, Stupid
 
PerlMonks  

Re: In Need of Mentoring

by repellent (Priest)
on Jan 16, 2012 at 07:13 UTC ( #948075=note: print w/ replies, xml ) Need Help??


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 :-)

    As I pointed out, perlbool teaches people who want to learn object oriented programming to use var and use @ISA. If I look at Perldoc, there's use parent.

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.

    I've gone from the age of ... from procedural to object oriented Perl. ... You're not even suppose to use @EXPORT_OK. Instead, your code is suppose to be object oriented.

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.

    However, should I make sure my code works with earlier versions of Perl? Are there still a lot of people out on Perl 5.6?

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.

    Are vstrings still used?

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.

    camelCase vs underscore_variables; for(;;) vs while (1) vs while ()

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


Comment on Re: In Need of Mentoring
Select or Download Code
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.

      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.
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 )

      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.

        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

      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.
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".

      $ perl -le " print $] 5.014001 $ perl -le " print $^V v5.14.1 .14 is 014 .1 is 001
        Other than showing Perl cares about backwards compatability, do you have a point?

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://948075]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others studying the Monastery: (5)
As of 2014-04-17 02:06 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    April first is:







    Results (437 votes), past polls