I myself got used (or still trying) to the following:

• Objects and modules names start with capital letter (eg: My::Module).

• Methods use underscore character ("_") as a word separator and start with the word, which describes the actrion (eg: get_value(), set_value(), print_report()).

• Something, I've learned from PHP - start methods/subs names which return TRUE/FALSE with "is" (eg: is_valid_type(), is_valid_age(), is_logged_in()). These makes code way more readable.

• If sub/method needs only one argument, don't use arrays, hashes, or references. Just call the damn thing! (eg:is_valid_type($type))

• If sub/method needs more then one argument, for maintainers sake, use named arguments in hash or hash reference. (eg: print_report({-colored=>1, -monthly=>0}))

• When it comes to parameter names, I like CGI.pm's style - with the dash. (eg {-colored=>1, -monthly=>0}).

• I like to keep inline documentation with POD and perl comments. All irrelevant staff, like AUTHOR, NOTES, BUGS, etc (grin) I usually move to the bottom of the module file.

• Document with POD only methods which can be called from outside. The rest should be documented with perl comments in the source. Otherwise - with POD, but should be marked explicetly.

One other thing I want to add is that coding style is not something that you think about, develop, and then use forever. It changes slowly, but constantly with the experience. Especially, if that experience is with someone else's code. :)

P.S.: In general, I don't like capitalization, since it requires me to press more keys then I need to. So I use it ONLY for significant names, which are obviously ONLY the modules. :)

P.P.S: And, yes, I beleive that set_value() is easier to read then setValue()

Leonid Mamtchenkov