in reply to Refactoring technique?

I'd be inclined to generalize the subroutine names to reflect the category of use.

For example, if these are axis coordinates, I'd be inclined to call the parameters $coord1, $coord2, and $coord3, or something similar. Since I'm a huge fan of the 2x3 naming standard, it would probably be more like $genco1, $genco2, and $genco3.

Replies are listed 'Best First'.
Re^2: Refactoring technique?
by BrowserUk (Patriarch) on Apr 24, 2015 at 14:13 UTC
    I'd be inclined to call the parameters $coord1 , $coord2 , and $coord3

    But imagine your coming into this code a year from now, aren't you going to mentally substitute $x, $y, $z for $coord1 , $coord2, & $coord3 respectively?

    Since I'm a huge fan of the 2x3 naming standard

    I don't think I've ever heard of that; and Google didn't find anything likely except your post?

    (Is that the US military thing of SecNav for Secretary of Navy?)

    it would probably be more like $genco1 , $genco2 , and $genco3

    As in General Coordinate N? (Yuck! :)


    With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'
    Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
    "Science is about questioning the status quo. Questioning authority". I'm with torvalds on this
    In the absence of evidence, opinion is indistinguishable from prejudice. Agile (and TDD) debunked

      Sorry, missed the other question in your post. 2x3was probably just a local name for the standard.

      Back when Chad an 8-character limitation on identifiers, the use of TLAs was common (TLA = Three-Letter Abbreviation). There were also odd occasions when it still made sense under the conventions of the day to have non-array repetitions (very rare, but greater than zero occurances).

      So the standard just sort of naturally developed out of the other coding standards in play at the time, where function/instance combinations just sort of rolled off our fingers. Variables started taking on forms like:

        inpfnm  Input filename
      outfnmOutput filename
      INPFILInput file handle (technically a stream pointer in C)
      OUTFILOutput file handle
      genpos01General Position 1
      genpos02General Position 2

      It was an ugly standard, seen from today's descriptive tendencies, but for old mainframe hacks and formatting pedants such as myself, it seemed a thing of beauty and joy; concise, predictable, and sensible.

      It was a marked improvement to the other mainframe tendency of the day to simply remove the vowels, yielding unwieldy names that begged for typos and were of inconsistent length in the source code ( MRCHNT_VNDR_ID -- yuck!)

      Like I said in another post, I try to be kind to normal people when others have to read my code; but if I expect to be the only user, all my blocks line up nicely, and I quietly revel in my control-freak haven of bliss.

      Yes, you've read me correctly. There are few who like my approach to naming variables, so I translate into those yucky inconsistent-length variable names when others are likely to be subjected to reading my code.

      One engineer, after modifying some of his code to match my naming convention, indicated he really did like the way his code lined up, but he just couldn't bring himself to de-Englishify his variables names just so the code lined up nicely.

      I don't Clark other people's code, and I do try to play along when the code isn't going to be strictly mine, but I find a serene and refreshing beauty in consistency and functional abbreviation.

      In that, I am definitely a Rare Bird.

        In that, I am definitely a Rare Bird.

        Should that be RarBir? :)


        With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'
        Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
        "Science is about questioning the status quo. Questioning authority". I'm with torvalds on this
        In the absence of evidence, opinion is indistinguishable from prejudice. Agile (and TDD) debunked