Yes, a lot of your patterns here are the same with me. These are the differences:
- I do like a space between the function name and the opening bracket - I find it aids eye-parsing. This is so ingrained now that it irks me when some SQL dialects prohibit it.
- Cuddled elses and elsifs for me. The alternatives just waste vertical space.
- No whitespace when dereferencing.
- I have only just recently started the "all POD at the end" technique and while I can see the benefit it in terms of compilation efficiency I'm still not sure it's better from a dev point of view. Ask me in another 5 years. :-)
- I use the same editor all the time (vim) because it is my IDE.
- I've only used PPI very rarely but that's likely more of a domain-related thing.
- I should use a bug tracker for everything. Habit instead results in a lot of small .txt files littering the place. Or worse, handwritten notes on the backs of envelopes.
- Parameter/argument validation is only done where the programmer deems it necessary/beneficial.
- I used to use pure perl OOP almost exclusively. Recently however, Class::Tiny has been beneficial in some situations in removing a lot of boilerplate. Might be worth a look for you too?
Over the years I have taken on board a lot of what are widely regarded as Best Practices. There are one or two exceptions which I still cling to:
- Don't use /x as a regex modifier willy-nilly, only when there is a real benefit. (similarly for other modifiers but I see a lot of occasions where x is used as a habit and actually has no bearing on the regex at all)
- Exporting symbols by default is OK. If people don't want their namespaces polluted there are easy ways to avoid it in the importing code.
- Implicit returns are fine, especially for subs expected to run in void context. Same for explicit return undef.
- Postfix dereference is just annoying. It's like a surprise twist at the end. Fine in a novel, not in code.