Note: Most of my thoughts have extended from a main thought, which is: What are you trying to do by writing code, Perl or otherwise, and what kind of activity would you consider writing code to be?

In Knuth's Turing Award acceptance speech, he discusses computer programmer as an art. In his speech he discusses how computer programmer is closer to the same kind of process an artist goes through. He is careful to define art as more of the artisan style of art, where "technique" and "skill" are used, rather then more abstract, subjective concepts more closely related to "fine arts".

Knuth also views code akin to "Works of Art", where it is more difficult to simply look at a program and grade it based on a standard. In his mind, writing code is similar to composing music, so what one person finds repulsive, another might find very beautiful.

In this case, I would argue that there is no one "correct" way to write code. When I look at your code, I might find it quite ugly or obtuse, but as the writer, I would anticipate it made sense to you. Also, there are many small design decisions that get made that cannot be understood just by seeing the code. And, the code may be solving different small problems to get to the large solution then a corresponding program.

As an example, I am working on some code that has a low-technical userbase. Given this, I have shied away from the "normal" install method and "normal" Perl modules, choosing rather to hand-code most of the functionality I need. I realize this is re-inventing the wheel, but my goal is not code-reuse, but rather a low barrier of entry for the user. So, if all they have to do is download the program, and start Perl, rather then trying to install 3-4 CPAN modules, then I am willing to spend the time re-writing the code. Plus, the additional coding work means that my code is tailored to what I want to do, and I have a good understanding of everything that is going on inside the system, and, in most cases, I am able to have an overall faster system because my modules are tailor-made to solve my problems.

This may not be the most generic solution, or the solution that many others would follow, but in my case I have thought about the decisions I am making, and I chose one of many available paths.

All of this is not to say that when I look at a piece of code, that I do not have my own opinions about the style or the conventions. Every construct has trade-offs, and while there are some that I would consider obvious, not everyone agrees with me.

When I code-review code for work, I am quick to point out things that I see as "unclear", or "bad style". Given that our software is fairly mature at this point, an implicit style has arisen, but I would argue that it is a single "body of work", rather then multiple separate bodies, so consistency within the single body is reasonable.

Also, here are my answers to your specific questions:

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

Usually anything I don't understand merits a closer look... if only for my own knowledge, or confirmation of my suspicions.

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

When its closer to my style :). Honestly, when the code more closely follows how I would have solved the problem, it makes me feel more comfortable. Of course, this means that just because I am comfortable with the code does not mean that it is a good solution to the problem.

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

Definitely. I try to abstract things sooner, to try and make them more ubiquitous. I use more references to functions and closures. As I learn more, my "toolkit" gets bigger, and I find myself calling a wider variety of tools I become comfortable using them. For someone who is not comfortable with the same set of tools I am, I am sure my code could be constructed as confusing, or poor style, but when I knew very little Perl I would have considered most code confusing, and if pressed, in bad style, but only because I myself could not understand what was happening.

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

Yes, the closer you get to the lowest common denominator, the more people you allow to maintain the code. However, often times difficult problems can be expressed more cleanly with code that is more advanced, but it does reduce the number of people that can maintain your code easily.

* Do you indent at all? If so, how?

When I use emacs, I follow most of what e-perl wants to do. When I use VIM, I use mostly whatever auto-indent thinks. I used to be more specific about my indenting, but over time, I've found that I can read different styles of indentation without too much trouble.

* How do you write data structures? How do you access them?

More broad questions, good :). I'll say "it depends". It depends on how much I plan on using the datastructure, how large the code is, and how complex the interactions will be.

If its something "simple", I'll just AoAs or HoHs, or a combination of hashes and arrays. As it gets more complex, my datastructures get more complex, storing more and more state.

* How do you structure your logic?

I tend more towards a functional style of programming. I like the idea of programming without side-effects and strive to make my code perform that way when its reasonable. When its not, I tend to revert to more OO-style, with objects that store state.

* How do you call your subroutines?

usually foo(), at various times with or without (), but I've been trying to reserve ()-less invocation for built-ins only.

* What kind of naming conventions do you use?

Whatever seems appropriate. I know that's probably not very clear, but I try to name things tersely, with implied information, as an example, if I have a table named Book, I'll have a column called "name", rather then "book_name", as I feel that the "name" column on the Book table implies that its the name of the Book. In more complex systems, I have been known to be more explicit, as inferring can be more difficult, and its possible that someone will infer differently then you would.

* What do you consider worth putting into a subroutine? How do you structure them?

Anything that I expect to use more then once. Anything that I feel the code needs to be able to abstractly "know" about. I've made cube functions that take a len, wid, and height and just return l * w * h, just because I feel that the code needs to "know" how to calculate a cube from 3 dimensions.