Beefy Boxes and Bandwidth Generously Provided by pair Networks
Come for the quick hacks, stay for the epiphanies.
 
PerlMonks  

Re^2: coding rules

by punkish (Priest)
on Jun 09, 2005 at 04:30 UTC ( [id://464952]=note: print w/replies, xml ) Need Help??


in reply to Re: coding rules
in thread coding rules

Of course, the reason you posted them was so we could chime in, right?
indeed. I want to get feedback and learn from others. So chime away.

Re. using camelCase for subs, it is for the very reason stated above -- "different things should look different." That way subRoutines() look different $from_variables.

--

when small people start casting long shadows, it is time to go to bed

Replies are listed 'Best First'.
Re^3: coding rules
by herveus (Prior) on Jun 09, 2005 at 12:08 UTC
    Howdy!

    camelCase is tolerable when there are only two words. threeWordCamelcase is pushing it. havingReallyLongAndDescriptiveSubNamesThatRunHalfwayAcrossThePage is absolutely hideous, and the basis for my deep hatred for that part of the Sun Java Coding Standards *spit*.

    This was driven home recently with great force when I had cause to pore over some Java source that had method names that were three inches long with many words mashed together. It was painful to try to parse the words apart to make sense of it.

    It is, generally, far better to apply the "separate dictionary words with _" constraint to all symbol names. Most human written languages (and all that use the roman alphabet, I think) rely on white space to mark the spaces between words. Mashing the words together into a long word may be very German in its application, but it destroys the normal visual markers we rely on to parse the phrase, making it much harder to read. Using underscores connects the words with a non-whitespace character, but has a visual impact of nearly zero. The contour of the tops of the characters still has zero-height area, just as it would with spaces (or close enough as to add no appreciable load to the cognitive process).

    I also take exception to rules 5 and 6.

    Prefixing like that will tend to obscure the substantial part of the variable name. The sigils, being single, non-alphabetic characters, are easy to cope with. However, consider the mental processing in reading "$this_aref_foo" to discern the name of the variable.

    You see "this" and have to remember that this simply marks it as local to some narrower scope (but which scope? hmmm...). OK. Ignore the "this". Next you come to "aref". OK, we have an array ref, but we still don't know what it is about. Finally, we come to "foo". At last! A name conveying some sort of meaning!

    Recall "Hungarian notation", by which means one prefixes the "real" name with a series of characters that encode the data type. Nasty nasty nasty. Rules 5 and 6 go down that path, whence lies much danger and peril and nasty sticky bits that go ecky ecky ptoing niiiiiwha.

    yours,
    Michael
      Recall "Hungarian notation", by which means one prefixes the "real" name with a series of characters that encode the data type.

      Actually, that's apparently a common misconception (and I'm guilty of it as well :) in what Hungarian notation was supposed to be. There's an interesting post on this over on "Joel On Software" just recently.

      Update: Oh, yeah I agree "Systems Hungarian" is bad and that's what's being advocated by the OP. But it's worth noting that such approaches are an aberration of the original concept (thanks again, M$) and the underlying idea itself has merit.

      --
      We're looking for people in ATL

        Howdy!

        Having read Joel's column, I stand by my assertion, in that it reflects what came to be. Simonyi's original intent and usage was quite reasonable in that the notations were meant to help understand the usage of the variables in functional terms, not "raw data type".

        The "Systems Hungarian" that sprang from the fetid brains of documentation miswriters is the form I invoke as the bogeyman, having been ignorant of the original intent.

        Item 6 from the orignal post (and to a fair extent item 5 as well) both advocated a "Systems Hungarian" treatment, which adds little to no value. One could use different classes to keep the different domains distinct, although that could add it's own extra baggage.

        yours,
        Michael

      Recall "Hungarian notation", by which means one prefixes the "real" name with a series of characters that encode the data type. Nasty nasty nasty.

      Hungarian Notation isn't what most people think it is. There's a lot of sanity and clarity in real Hungarian. this article, Wrong, by Joel Spolsky, includes a description of what Hungarian was intended to be, one reason why the world diverged from Simonyi's original idea, and examples of how to use it as intended.

      Be Appropriate && Follow Your Curiosity
        Hungarian Notation isn't what most people think it is. There's a lot of sanity and clarity in real Hungarian. this article, Wrong, by Joel Spolsky, includes a description of what Hungarian was intended to be, one reason why the world diverged from Simonyi's original idea, and examples of how to use it as intended.

        There's even more sanity and clarity to be gained by using a language with decent support for types. This is exactly the sort of guff that computers are a whole lot better at keeping track of than humans.

      I agree with the idea of Rule 6 that it's handy to know what kind of thing a reference variable is referring to. I also agree with this comment that prefixing something like aref is irritating for holding up my perception of the variable in question. Instead, I get clarity and brevity by postfixing this info, i.e. for defining a scalar reference for @foo_bar I like to use the entire original identifier suffixed with an underscore and two letters as in $foo_bar_ar rather than $aref_foo. Expanded:

      _hr => hash reference _ar => array reference _sr => scalar reference _xr => executable(sub) reference
Re^3: coding rules
by QM (Parson) on Jun 09, 2005 at 04:41 UTC
    Re. using camelCase for subs, it is for the very reason stated above -- "different things should look different." That way subRoutines() look different $from_variables.
    But they already look different! Tell me what each of these are:
    foobar() $foobar @foobar %foobar
    To distinguish them more, I would probably have the subs named with some kind of action, like process_rows(\@rows) (as opposed to rows(\@rows), which is begging for trouble).

    But then I really hate camelCase. I'd prefer camel_case, Camel_Case, and CamelCase before camelCase.

    -QM
    --
    Quantum Mechanics: The dreams stuff is made of

Log In?
Username:
Password:

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

How do I use this?Last hourOther CB clients
Other Users?
Others making s'mores by the fire in the courtyard of the Monastery: (6)
As of 2024-04-10 21:33 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found