First of all my experience is that most of your "and no more so" statements address areas that are already shortchanged. People cut too many corners as it is, they don't (IME) need more encouragement to do so. Trying to work cleanly usually works out faster in the end.

As for shifting, yes, most of the time it doesn't make a big difference. If you have fairly meaningless rules (eg indent 4, not 2, using hanging braces, uncuddle your elses) to provide a common look and feel, that is perfectly fine. Look and feel issues affect ease of moving around your code base and consistency reduces bug rates. If cat2014 didn't use shift because of a style rule that she understood to just be a style rule, I would not be bothered. But she had trouble accepting a shift to be OK because she had it drilled in that it was a bad thing to do.

Now that is fine if the argument against - that you are losing track of what is at what index - really is important. But it is bogus. If you are thinking of Perl arrays as something to access by index, most of the time you are doing something wrong. They are things you access in order. Besides which if you write OO methods then the order of your argument list is already off by one. Repeating bogus arguments for meaningless details is bad.

Secondly while style is fairly arbitrary, it is good to not have rules which are not widely shared. The best references that any programmer at that company is likely to encounter all shift. That style is used in the top Perl books. It is used by good CPAN modules. It is used in core Perl modules. It is used by competent posters, in articles, etc. It will be used by most competent consultants, trainers, and hires. Do you really want to make reading all of that good advice a jarring experience? If not then your style should conform to the community.

Thirdly I ran across the argument for not shifting and believed it for a while. I changed my mind. Why you ask? Well I found that very frequently I have a few special arguments that I want to process one way and an arbitrary list I want to do something else with. For instance a wrapper method will grab the object and then for each parameter it will do something. Now yes, you can copy @_ into a few variables and a new temporary array, but why? First of all that copy goes by value not reference so it is more work for Perl. Secondly there are now more mechanics for the programmer to keep track of. Is, or isn't this new array important by virtue of its existence? This happened to me regularly enough that I found it cleaner to always be consistent and grab fixed arguments with shift.

So if I came to a new job and they wanted me to change how I indent, how I use braces, the capitalization style of variables and functions, naming convention, etc I would not object. I can adjust fairly quickly and I know that for those things, within reason, consistency matters far more than exact details. But I would argue if I was told to not use shift to process arguments in Perl. I have tried it both ways and I my experience says that it does make a difference.

---

---

• Are you posting in the right place? Check out Where do I post X? to know for sure.
• Posts may use any of the Perl Monks Approved HTML tags. Currently these include the following:

  <code> <a> <b> <big> <blockquote> <br /> <dd> <dl> <dt> <em> <font> <h1> <h2> <h3> <h4> <h5> <h6> <hr /> <i> <li> <nbsp> <ol> <p> <small> <strike> <strong> <sub> <sup> <table> <td> <th> <tr> <tt> <u> <ul>

• Snippets of code should be wrapped in <code> tags not <pre> tags. In fact, <pre> tags should generally be avoided. If they must be used, extreme care should be taken to ensure that their contents do not have long lines (<70 chars), in order to prevent horizontal scrolling (and possible janitor intervention).
• Want more info? How to link or How to display code and escape characters are good places to start.