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. Fatal.pm 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?

Yes!

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.