|
Re: In Need of Mentoring
by Anonymous Monk on Jan 15, 2012 at 22:22 UTC
|
First step is to publish the code on somewhere like github, bitbucket, etc. Then post on PrePAN.org. That site is specifically designed for CPAN code reviews.
I try to avoid using modules that require 5.10+, because I frequently use different perl versions, from 5.8.9 and up. It only makes sense to restrict the audience if you're relying on a feature of a newer Perl for functionality, not style. | [reply] |
|
|
| [reply] |
Re: In Need of Mentoring
by toolic (Bishop) on Jan 15, 2012 at 23:27 UTC
|
If your code is small (a couple hundred lines or less, not including POD), you could just post it in the Meditations section with RFC in the title.
Or, you could post small sections of your code and get advice.
You could use percritic to get automatic advice on style issues. You may not agree on all its advice, but at least you will get verbose explanations in many cases.
| [reply] |
Re: In Need of Mentoring
by repellent (Priest) on Jan 16, 2012 at 07:13 UTC
|
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.
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.
| [reply]
[d/l]
[select] |
|
|
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] |
|
|
| [reply] |
|
|
| [reply] |
|
|
$ perl -le " print $]
5.014001
$ perl -le " print $^V
v5.14.1
.14 is 014
.1 is 001
| [reply]
[d/l] |
|
|
|
|
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] |
|
|
Re: In Need of Mentoring
by eyepopslikeamosquito (Archbishop) on Jan 16, 2012 at 02:48 UTC
|
You might find some ideas to improve your CPAN module in: Writing Solid CPAN Modules.
Though this node is quite old, I've updated it a few times over the years.
| [reply] |
|
|
| [reply] |
Re: In Need of Mentoring
by JavaFan (Canon) on Jan 15, 2012 at 22:25 UTC
|
For example, I know what I am doing should work with Perl as old as Perl 5.8.8, and I do a <use 5.008008;> to verify this.
Eh, no. That use statement doesn't verify anything in that regard. It does prevent someone with 5.8.7 to run your code though.
However, should I make sure my code works with earlier versions of Perl?
That depends. Who are you programming for? Who are your customers? Do you have to make a sacrifice to support 5.6? If so, what do you get out of it?
many CPAN modules are fairly old, and their coding style is dated.
You know, if I'm considering downloading something from CPAN (or from anywhere else, whether it's free or paid), I seldomly give a flying fuck whether the coding style is outdated or not. The only thing that matters is "does it solve my problem"? If it solves my problem, I don't care whether it's written by someone old enough to remember perl4 (and written as it were perl4), or by a grasshopper easily impressed by the words "Modern::Perl". Hell, it doesn't matter whether it's written in COBOL, Haskell or Javascript. It either solves my problem (ok!) or not (not ok!).
If you buy some meat, do you care whether the butcher uses modern knives, and do you avoid a butcher who has used the same knife for 20 years? Would you refuse to have your packages delivered by FedEx if they'd use a plane which was designed in the 20th century, opting for the bicycle courier who has written "use strict" on his 2009 bicycle frame? Do you only listen to music produced in the past couple of months?
| [reply] |
|
|
You know, if I'm considering downloading something from CPAN (or from anywhere else, whether it's free or paid), I seldomly give a flying fuck whether the coding style is outdated or not. The only thing that matters is "does it solve my problem"
I normally don't give a FF either. It works, I'm happy. If it doesn't, I find a different module. However, I'm not using a module. I'm creating a new one, so I want to do it right. Coding style changes over time, but older modules don't reflect it. For example, many modules use @EXPORT which is now considered a bad technique because it invades the user's namespace. You're not even suppose to use @EXPORT_OK. Instead, your code is suppose to be object oriented.
I've seen modules that manipulate $^W to turn on warnings. I'm sure that was a good technique at one time, but we now have use warnings;. The use of the C Style for loop gets debated a lot. It's now considered bad programming, and I believe it's going to be removed from Perl 6. Yet, I was taught that for (;;) is a much better way to mark an infinite loop over while (1).
And, even basic coding styles change. We're now suppose to eliminating extra parentheses because it's more readable. When I learned programming, it was the more parentheses the better. Better adding an extra set rather than relying on a mistaken idea of operator precedence because it makes your code more readable. When I first learned Perl, I was taught the correct way to create variables was to $camelCase them. They're easy to type and very readable. Don't use $underscore_variable_names because it's no more readable, longer, and harder to type. Yet, Rule #27 by Conway is to use underscores for separating multiple words in Perl variable names.
Nor, can I rely on perldoc. How should I declare something is a base class? Should I use the @ISA list, use parent, or use base? I believe we're suppose to say use base, but if you look at perlboot, it tells you to use @ISA and use var.
This is why I've asked about mentoring. Like 90% of the Perl programmers out there, I'm isolated from the community. Most of the other people around me are C#, C++, or Java developers. They have no idea about Perl.
A few years ago, the head of development decided that my Perl scripts should too be put through a code review process. I thought it was a great idea. After all, our software depends upon it. It should be reviewed. The problem was finding someone who could review it. At my first code review, everybody else admitted they didn't know enough Perl to actually review my code. However, one person in the group had a friend at the bank, and his friend knows a good Perl programmer who's helped him out before. He'll have his friend forward the code to this Perl programmer for comments.
A few days later, I get an email from this friend asking me to review on my own code.
| [reply]
[d/l]
[select] |
|
|
You mention several "changes" that you perceive in code over the time, and you seem to imply that most of them are "improvements".
I for one do not see the move from what you call old style to OO-style an improvement if it is done only for that reason. OO-style has its merits in a lot of cases but it being more moderd by perception is never a good reason to refactor code. Never.
The thing I miss in you very elaborate and well readable posts is what I think is the most important thing in module code: consistency. Reading your posts, I have a gut fealing that your documentation is in good shape. You seem to be capable of explaining your thoughts and goals which imho is an indication that you do so in the docs too.
As others have said, your target audience is important. If you are backporting new(ish) features from perl5.12 to perl5.older, you really care about what versions run the code on what architectures. CPANTESTERS is your help there as I presume you do not have 100+ perl releases running on 40+ architectures. If you are indeed making your code to run on 5.6, some more modern syntax won't even be available.
If your code is aimed at maintenance by many (a public git repo is a nice start), make your style guide public. Explain where your decisions stem from and "force" a style on the other coders. Using Perl::Tidy (perltidy) - and providing a working .perltydyrc can help the others. With what I started: consistency is way more important to be able to read code from others that to follow the style-du-jour.
Enjoy, Have FUN! H.Merijn
| [reply] |
|
|
For example, many modules use @EXPORT which is now considered a bad technique because it invades the user's namespace. You're not even suppose to use @EXPORT_OK. Instead, your code is suppose to be object oriented.
Oh, this is such a load of bullshit.
If you're picking up things like this from your "mentoring", please, immediately log out to Perlmonks to never return, and cancel all your mailing list subscriptions. You would become a better Perl coder if you don't listen to people and parrot their unfounded opinions.
Exporter doesn't invade any name space. Exporter exports exactly what the user asks for. It just that some people cannot grasp the notion of defaults -- Exporter has a way for the user to say "gimme your defaults", and for the exporting module to say "these are my defaults" (@EXPORT). People confuse that with "invading your namespace". But they're either mistaken, or just parrot others without thinking.
Second, making code OO just to avoid using Exporter seems like very bad advice to me.
The use of the C Style for loop gets debated a lot. It's now considered bad programming, and I believe it's going to be removed from Perl 6.
I've no idea about the latter, but considering a C style for loop to be bad programming is of course, utterly crap. It's like saying "using keys and each is bad style programming, you should use values". There are many cases where it's useful to know the index, or where you actually may not process all the elements in order and in isolation.
We're now suppose to eliminating extra parentheses because it's more readable.
That's a new one to me. Which church did you go to, and which preacher said this?
Yet, Rule #27 by Conway is to use underscores for separating multiple words in Perl variable names.
You know, Conway isn't a prophet, and his book isn't a gospel. Read the introduction, he even says so. By all means, if you prefer camel case, use camel case.
This is why I've asked about mentoring.
Actually, it looks like you want a preacher. You seems to desperately trying to avoid deriving your own conclusions, and you seem to want someone who can think for you. Which is the entire concept of religion: having someone else think for you.
It's ok to listen to arguments. Listen to arguments from multiple sides. But do draw you own conclusions. Which neither implies going with the loudest people, or with the majority.
Given your state of mind, I'd say getting a mentor is about the worst that can happen to you.
| [reply] |
|
|
++ for that great story about the friend of a friend :)
| [reply] |
|
|
| [reply] |
|
|
It's both. 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. And, at one time I was told this is how you create a constant:
*PI = \3.14159;
our $PI;
Now we have use constant.
And, there is a fashion in coding just as much as there is in the dresses in Vogue. We use to tell people to parenthesize everything because it was more readable. Now, we tell people to eliminate unnecessary parentheses because it clutters code and makes it less readable. Variable names use to be camelCase, now we are suppose to use underscores. And, what is the best way to do an infinite loop? Do you use for(;;) or while (1)
Or should that be while ( 1 ) ; because the style is now to leave a space around parentheses and various punctuation marks because it's more readable. However, when I was learning C, I was told to get rid of spaces around parentheses because it made my code harder to read.
I'm just happy I never learned about use English; until I was told that it shouldn't be used because it makes your programs run slower and it doesn't really make your programs more readable anyway. | [reply]
[d/l]
[select] |
|
|
|
|
|
|
| [reply] |
|
|
|
|
|
|
|
|
|
|
|
|
Consider the difference between a C-style for loop and iteration.
Yeah, what about it? Is one of them incorrect? I know C programs with for loops that are correct, are you implying iteration is incorrect?
| [reply] |
|
|
|
|
|
|
|
| [reply] |
|
|
| [reply] |
|
|
|
|
Re: In Need of Mentoring
by luis.roca (Deacon) on Jan 16, 2012 at 02:10 UTC
|
So where do I go to get mentoring on my coding and programming style? I'm not looking for tutoring. I'm willing to pick up manuals and do that on my own. I simply want a code review, or a few hints. This isn't so much as How do I do such and such?, but whether I'm doing it correctly.
I always thought PerlMongers would be a great place to go and have some face to face code reviews, mentoring etc. I think each location runs their's a little differently. Our local chapter (New York City) keeps it to social events (aka: drinking) and lightning talks. It still might be worth a try and definitely a good way to meet other Perl programmers. :)
"...the adversities born of well-placed thoughts should be considered mercies rather than misfortunes." — Don Quixote
| [reply] |
|
|
My current job is in Morristown NJ...
So near, yet so far...
There's a group in Princeton, but I don't think they're very active. The calendar on their webpage dates from 2005.
| [reply] |
|
|
| [reply] |
|
|
You're right about the Princeton group: it's dead. We had a couple of starts, but never got going regularly.
I know there are active Perl programmers in NJ. Up until a few months ago, I worked with a handful of them, in Middlesex county (about 1/2 hr from Morristown). I know some who live in NJ and work NY city, too. I think the tough thing is finding people who are interested enough in taking time out of their schedules at night to get together and talk about Perl. So many of the Perl people that I've had in-person relationships with have moved to other primary languages, and though they still use Perl they are not passionate about keeping up with it. I myself am not doing hands-on development at my job anymore, but Perl is still my most familiar and reliable language when I do need to get something done.
I just moved up to North Jersey, I'm about 15 minutes NW of Morristown now, and I've started looking out for any kind of local programming or development meetups. There are a ton in and near NYC, but I haven't seen much around here. I'm toying with trying to start one. If you start one first, I'll join it :) ... I don't know if you do web development, but there's an active OWASP chapter in Bridgewater. I've been to a couple of their meetings before, and found them very interesting.
Something I came across today, which is both relevant to your situation (wanting to surround yourselves with great people to learn from), and geographically relevant: http://www.cs.virginia.edu/~robins/YouAndYourResearch.html
-- it's long, but I found it very inspiring.
I was lucky enough to be a full-time Perl developer for many years. It was my first programming job, and I had no good Perl mentors when I started. I really have to credit this site for my success and growth as a developer. There was such a great community here, and the ratio of real interesting discussions vs. name-calling and infighting was lower than I've ever seen anywhere on the internet before or since. We grew to a pretty big team of Perl people at my company, which was great to have in-person, but I guess what I'm saying is don't discount the online community.
| [reply] |
Re: In Need of Mentoring
by mrguy123 (Hermit) on Jan 16, 2012 at 10:00 UTC
|
Perl Best Practices by Damian Conway is a fantastic way to improve your Perl programming and programming in general.
Good Luck!
Mr Guy
He who is content with his lot probably has a lot | [reply] |
|
|
That book needs to be read with a bucket of salt.
The problem is that it mixes things that are purely individual style, issues that are definite bugs, and everything in between, and does not distinguish between them in the text/
For example, the author of the book favors K&R brace style. Fair enough that is his view, but not mine. I respectfully disagree. Also the author recommends me to write Some::Module::Name->new() not Some::Module::Name::new() because the latter form will cause bugs if Some::Module::Name is a subclass of another module, and does not define a constructor.
The problem is that style issues and real bug avoidance are mixed together without much in the way of distinction and labeling. Each bit of advice comes with a few paragraphs of argument, and if you read those paragraphs you can usually (but not always) deduce which suggestions are just style and which are important, but I would hate for the book to fall into the hands of manager who does not know perl and blindly dictates that the whole book will become the company coding standard.
| [reply]
[d/l]
[select] |
|
|
I completely agree with you that blindly dictating the book as coding standard is a mistake. I think there are some great guidelines in the book but also some I disagree with.
This book really improved my coding style and I recommend it for this discussion, but it is of course up to the user to decide which guidelines he/she wants to follow.
I think Larry Wall sums it up pretty well:
We do not all have to write like Faulkner, or program like Dijkstra. I will gladly tell people what my programming style is, and I will even tell them where I think their own style is unclear or makes me jump through mental hoops. But I do this as a fellow programmer, not as the Perl god...stylistic limits should be self-imposed, or at most policed by consensus among your buddies.
| [reply] |
|
|
I would hate for the book to fall into the hands of manager who does not know perl and blindly dictates that the whole book will become the company coding standard.
Never had a manager who thought there was a benefit of enforcing coding styles, but I've met many coworkers who started suggesting coding styles. Most of them, they say "perhaps we should start with PBP". Those people can be easily countered: if you have converted all your OO classes to use Class::Std, come back and we'll continue the discussion". I'm still waiting for the first person to do so.
PBP has some interesting arguments. But nowadays, I only use my copy of PBP to whack people who defend their style with "but PBP says so" over their head. My copy is quite tattered and bloody, as I'm not afraid to use it.
| [reply] |
Re: In Need of Mentoring
by aartist (Pilgrim) on Jan 16, 2012 at 08:32 UTC
|
- Make a list of all your concerns.
- Post sample code here that concerns you.
- You might just get all the answers here.
| [reply] |
Re: In Need of Mentoring
by tobyink (Canon) on Jan 17, 2012 at 10:28 UTC
|
Having now seen File::OFind (on github via prepan), I'd say your coding style is very unlikely to get you laughed off CPAN. The only thing that might be worth changing would be your Capitalised_Method_Names, but that's a minor niggle - at least you're mostly consistent.
That said, I don't think it's worth publishing File::OFind on CPAN. This time last year, perhaps, but as of a few months ago we have Path::Class::Rule which seems to do everything your module does (OO, iterator based, allows short-circuiting), and more (good framework for combining multiple tests, lots of handy built-in tests).
Of course, if a number of people are already using your module, then it might still make sense to publish it, so that they have an easy place to grab the latest version, and so that you can benefit from the many facilities CPAN offers (RT bug tracker, CPAN testers, etc). In that case though it's probably worth pointing prominently to Path::Class::Rule in a SEE ALSO section of your documentation.
| [reply]
[d/l]
[select] |
Re: In Need of Mentoring
by sundialsvc4 (Abbot) on Jan 16, 2012 at 17:04 UTC
|
My $0.02 ...
When I download a module from CPAN, I expect never to look at its source-code, and, most importantly, to never feel that I have to. Most of all, I want to see a long list of self-tests that rigorously exercise the module. Secondarily, I want to see thorough documentation that doesn’t require deep knowledge of the code (or, any knowledge at all of the code) in order to use it effectively. I do not want to get the impression from the POD that the code is half-baked: I have passed over many a module for that reason. The design of a module intended for public use must be very considerably more stringent than simply taking a piece of code that you wrote for a project and making it public. Obviously some serious thought must be given to how you intend for the module to be used, and for keeping the code as isolated from unwanted side-effects as possible. But I am not going to dive into your code and critique it. I’m not going to try to understand it. Indeed, the very reason why I am seeking code from CPAN is so that I don’t have to understand it.
One other thing that I look at is the CPAN bug-list. Are you fixing reported bugs in your code within, say, just a couple days of it being reported? If the code begins to fail CPANTS tests (e.g. because some original prerequisite module has changed), are you Johnny-on-the-spot?
| |
|
|
++ Most of all, I want to see a long list of self-tests that rigorously exercise the module.
and esp self-tests that show very clearly, in simple discrete blocks, how to use each function
| [reply] |
Re: In Need of Mentoring
by Anonymous Monk on Jan 16, 2012 at 02:47 UTC
|
I never look at the code... I only care if it works, and if the self-test suite that precedes its installation is, in fact, robust, rugged and as thorough as I expect demand it to be. | [reply] |