Beefy Boxes and Bandwidth Generously Provided by pair Networks
go ahead... be a heretic

Comment on

( #3333=superdoc: print w/replies, xml ) Need Help??

Do you feel the same way?

Partly. There is a need for commonly understood Perl code, so that not everything winds up obfuscated and unreadable, but there should also be recognition of the simple fact style is mostly personal. I may not like the way you use your whitespace, but if it doesn't affect readability, you usually don't hear me complain.

Of course, and I'll note this before anyone else does, I usually do think certain styles hinder readability. :)

I'm a bit of a hypocrit in this area. At the same time I find that everyone is allowed their own style, AND I think there are some important things that should be standard and followed by all Perl programmers.

What items do you unconciously look for as signals that what you're reading merits a closer look?

The usual red style flags:

  • spaghetti code
  • lack of indentation
  • lack of module use
  • lack of strict
  • declaration lists (e.g. my ($foo, $bar, $baz, $quux); or my $foo; my $bar; my $baz; my $quux;)
  • c-style foreach index (e.g. for (my $i = 0; $i <= $#array; $i++) { ... })
  • lack of encoding/escaping
  • everythingcrammedtogether
  • overuse of \-escapes (e.g. in regexes, /\>/)
  • stupid variable names (e.g. $data)
  • comments translating Perl to English (e.g. $i++; # increment $i)
  • subs called with &foo()
  • subs called with &foo without comment like "re-use @_"
  • prototypes, especially when meaningless (e.g. sub new ($$$) { ... bless ... })
  • symbolic refs where arrays|hashes could be used

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

Certainly. One might call them green flags.

  • strict, warnings
  • sane and short variable names
  • consistent indentation in the style I like
  • use of certain modules (e.g. and templating modules)
  • smart and useful comments
  • -T

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

Partly. If it's inconsistent, the author is inexperienced. If it's consistent, the author may be experienced. Do note that experience and skill are not the same thing and not always closely related.

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

Yes; it became more consistent and readable (mostly because of the consistency, though). I use more language features than I did before.

Do you think that the style of a piece of code can contribute to its maintainability?


Do you indent at all? If so, how?

Yes. If something is continued on a new line, I indent according to balanced brackets, like {}, () or []. The opening bracket is on the same line as the thing before it, the contents are indented, the closing bracket is in the same column as the last lesser-indented line, or explained differently: no longer indented.

Sometimes I indent long lines without using parens. Then it's after an operator, or after the name of the function I'm calling.

I indent complex ?:-structures. The first line has the condition and is not indented. The rest is indented, with ? or : each beginning a new line.

Indents are ALWAYS 4 spaces. There are no half-indents, outdents or tabs. I do not consider initial whitespace used for lining up vertically indentation.

How do you structure your logic?

However the logic makes most sense to me.

How do you call your subroutines?

Usually parenless on statement level (in void context), but often with parens if it's spread over multiple lines (because parens make indenting clear) or if it's part of a larger expression.

What kind of naming conventions do you use?

Variables are named after their contents, simple, and do not indicate type. Arrays and hashes are usually in plural. Names are all lowercase, except module names. Words are together, and when separated (very rare), with underscore. Sub names indicate return value (like int, not like hex) and when they do something, they're imperative and when used with an object, they're verb-object (like readline and encode_entities), not object-verb (like uri_escape).

What do you consider worth putting into a subroutine?

Everything that's called more than once or does a specific thing. In general: when it can be named without using generics.

How do you structure them?

Depends wildly on what they do.

Juerd # { site => '', plp_site => '', do_not_use => 'spamtrap' }

In reply to Re: Commonly accepted style guide? by Juerd
in thread Commonly accepted style guide? by dragonchild

Use:  <p> text here (a paragraph) </p>
and:  <code> code here </code>
to format your post; it's "PerlMonks-approved HTML":

  • Posts are HTML formatted. Put <p> </p> tags around your paragraphs. Put <code> </code> tags around your code and data!
  • Titles consisting of a single word are discouraged, and in most cases are disallowed outright.
  • Read Where should I post X? if you're not absolutely sure you're posting in the right place.
  • Please read these before you post! —
  • Posts may use any of the Perl Monks Approved HTML tags:
    a, abbr, b, big, blockquote, br, caption, center, col, colgroup, dd, del, div, dl, dt, em, font, h1, h2, h3, h4, h5, h6, hr, i, ins, li, ol, p, pre, readmore, small, span, spoiler, strike, strong, sub, sup, table, tbody, td, tfoot, th, thead, tr, tt, u, ul, wbr
  • You may need to use entities for some characters, as follows. (Exception: Within code tags, you can put the characters literally.)
            For:     Use:
    & &amp;
    < &lt;
    > &gt;
    [ &#91;
    ] &#93;
  • Link using PerlMonks shortcuts! What shortcuts can I use for linking?
  • See Writeup Formatting Tips and other pages linked from there for more info.
  • Log In?

    What's my password?
    Create A New User
    and all is quiet...

    How do I use this? | Other CB clients
    Other Users?
    Others imbibing at the Monastery: (2)
    As of 2018-05-26 18:34 GMT
    Find Nodes?
      Voting Booth?