Beefy Boxes and Bandwidth Generously Provided by pair Networks
P is for Practical

Re: Commonly accepted style guide?

by chester (Hermit)
on Sep 25, 2005 at 06:11 UTC ( #494873=note: print w/replies, xml ) Need Help??

in reply to Commonly accepted style guide?

"Are there items that make you feel more comfortable with the code?"

There are things that definitely make me feel more uncomfortable. For example, cramming a dozen functions onto one line in some kind of clever but completely unreadable tangled chain. Of this sort:

@_ = join "\n", map {/$complicated_regex/} split '', join ',', reverse sort map {lc} map {do_backflips($_)} keys %{ $var->{$something} };

On the same token, massive amounts of referencing and dereferencing:

$data_ref = [ @{ @{ $ref->{ $sub->(\%hash, {key=>[@_[0..4]]}) }}[0] }[1..3] ];

I don't even know if that line is valid Perl, but I've seen that kind of thing given as a response here at PM sometimes. It might save you from allocating variables to store temporary references, and maybe you'll save 12 bytes of RAM and 15 nanoseconds of compute time, but I don't think it's worth the pain it causes my brain to try to parse it.

Isn't there some kind of natural limit to the amount of things a person can hold in short-term memory? One-liners are clever and fun, but probably don't belong in code that anyone else ever needs to read.

"Do you feel you can rate the experience level of the author by how the code looks, both in Perl and programming in general?"

When code is written with heavy use of Perl idioms, I tend to think the person is more experienced.

I agree with pg that this isn't always a good thing. Unless you're the only person who needs to read your code, it's not too useful to be really good at speaking a language no one else can understand. Some idioms, like $data = do {local $/; <FILE> }; or something, are useful and straightforward and simple enough that one could reasonably expect a "Perl programmer" to know what it means. More complex or obscure or inventive idioms are probably not a good thing (unless you can convince everyone else to use them. How's that for some logic. :) ).

"Has your style changed as you have improved as a programmer, both in Perl and in general? If so, how?"

The better I get at programming, the less work I (need to) do. I use more and more of the CPAN to do the dirty work for example. Or learn to take something I wrote and stick it somewhere I can reuse it. And learning to write clean code means I'm less likely to have to fix something or re-write something in the future.

I also find my code being longer, in the sense that I write more verbose code for the sake of making it easier to read and edit later. This is a good kind of longer. More typing in the short-term, less work in the long-term.

Lots of other things. There are so many ways to do things (especially in Perl) that you can't help but change the way you write code over time.

"Do you think that the style of a piece of code can contribute to its maintainability?"
Style is pretty much all that contributes to something's maintainability.

Replies are listed 'Best First'.
Re^2: Commonly accepted style guide?
by grinder (Bishop) on Sep 25, 2005 at 09:21 UTC
    cramming a dozen functions onto one line in some kind of clever but completely unreadable tangled chain

    I'm not quite sure I'm in agreement with this one. It's not tangled, it flows from right-to-left. It's such a nice idiom that Perl 6 introduces the ==> operator, in order to reverse the flow. It will go from left to right, and I suspect the result will be much more readable.

    And if you think it's a tangle, the style question at hand is that of the Correct Use of Whitespace. A well-indented chain of functions should be eminently readable.

    massive amounts of referencing and dereferencing

    No disagreement with this one. Programmers in C used to create intermediate typedefs in order to get around this problem (like a "pointer to array of functions returning an int with parameters of a pointer to a void function taking an int and an array of characters").

    While this exact problem doesn't arise with Perl, the problem of decoding what a massive dereferencing statement is doing can be pretty brain-melting.

    • another intruder with the mooring in the heart of the Perl

      I agree that whitespace can be a big difference. That's actually my problem; if that was broken up into lines, I'd say it was mostly OK. If you get this:

      @_ = join "\n", map {/$complicated_regex/} split '', join ',', reverse sort map {lc} map {do_backflips($_)} keys %{ $var->{$something} } ;

      Imagine some more assignments on the left and some more semicolons on the right and it's pretty much equivalent to reading any other code (except that you have to read it backwards).

      I agree that even my first example as it stands isn't nearly as confusing as my second with the referencing. At least the flow of the first is linear; nesting things is much worse.

      <RANT>Considering how twisted the syntax of C types gets as soon as pointers, functions and arrays are involved using typedefs is pure self-defense. Hey, what's the syntactical difference between the declaration of a function returning a pointer to int and a pointer to function returning int? Seems to me someone failed to envision the posibility of types more complex than an array to foo or pointer to foo.</RANT>

      XML sucks. Badly. SOAP on the other hand is the most powerfull vacuum pump ever invented.

Log In?

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

How do I use this? | Other CB clients
Other Users?
Others pondering the Monastery: (11)
As of 2016-08-30 19:43 GMT
Find Nodes?
    Voting Booth?
    The best thing I ever won in a lottery was:

    Results (420 votes). Check out past polls.