Beefy Boxes and Bandwidth Generously Provided by pair Networks
Syntactic Confectionery Delight

Re: Silly code reviews and shift

by zigster (Hermit)
on Jan 18, 2001 at 14:59 UTC ( #52742=note: print w/replies, xml ) Need Help??

in reply to Silly code reviews and shift

In my experience code review is only a valid experience under one of two catagories.
  • The review refers to a defacto standard that has not been adhered to
  • The review offers at least basic reasoning behind a decision.
Neither apears to have occured in this case.

There are very few central core truths to programming. The rest are interpritation and implimentation, specifically of the core truthes. In my experience:

  • code should be as simple as it needs to be be and no more so.
  • code should be as efficient as it needs to be and no more so.
  • code should be as readable as it needs to be and no more so.
  • code should be as reliable as it needs to and no more so.
  • code should fulfil its technical design brief.
In my opinion all coding standards come from these. The question I would be asking is not what do other people do, because other people often know no better than you (or I) I would ask what core principle does 'not using shift' fulfil. Does it make code faster, simpler, more reliable? However as all decisions are a trade off I would ask myself do I need whatever advantage and can I accept the disadvantages that it would also bring.

On balance looking at the list I have given above to shift or not to shift. It dont matter one wit, tiss simply a matter of style, style being something that too frequenly is mixed up with a coding standard. Where do those brackets go again?


Replies are listed 'Best First'.
Re (tilly) 2: Silly code reviews and shift
by tilly (Archbishop) on Jan 18, 2001 at 23:22 UTC
    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.

      You must remember my audience. I was not writting a set of coding standards but explaining my thinking when writting coding standards. I agree completely that the statements I gave were not useful except to expert users but hay that is who I am talking too. We were discussing the merits of a particular standard that requires understanding of the origins of those standards. I feel very strongly that all too often people forget why software is written, it is written to perform a specific task. If the code performs that task then it is a success, if that task requires that the code be extensiable then cool as. The code must be written to be extensiable. If the code is for a one shot task then it does not. That is where the 'and no more so' come from.

      I feel that perl exemplifies this idea. It has the capiabilities to allow for write once code that can be quickly written. It also allows for long term maintanable code to be written. As a programmer it is my job to strike a balance between the two.


Log In?

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

How do I use this? | Other CB clients
Other Users?
Others imbibing at the Monastery: (3)
As of 2022-05-21 05:45 GMT
Find Nodes?
    Voting Booth?
    Do you prefer to work remotely?

    Results (76 votes). Check out past polls.