Wow. I've taken a quick look and really like it!
Given my keen interest in this domain, I read the "Stylish Perl" chapter first.
This chapter is excellent as is, and very short (which is desirable).
taken from On Coding Standards and Code Reviews, you might consider adding more material derived from one or more of the following.
- If you must rely on cleverness, encapsulate and comment it.
- Establish a rational error handling policy and follow it strictly.
- Coupling and Cohesion. Systems should be designed as a set of cohesive modules as loosely coupled as is reasonably feasible.
- Data hiding. Minimize the exposure of implementation details.
- Minimize the use of global data.
- Interfaces matter. Once an interface becomes widely used, changing it becomes practically impossible (just about anything else can be fixed in a later release).
- Design the module's interface first.
- Design interfaces that are: consistent; easy to use correctly; hard to use incorrectly; easy to read, maintain and extend; clearly documented; appropriate to your audience. Be sufficient, not complete; it is easier to add a new feature than to remove a mis-feature.
- Minimize the scope of variables, pragmas, etc..
- The result of every file operation or API call or external command should be checked, and unexpected results handled.
- Generally, comments should describe what the code does, not how.
- Separate user versus maintainer documentation.
- Every non-local named entity should be commented.
- There should be a comment on any code that is likely to look wrong or confusing to the next person reading the code.