The physical layout of the program is consistent (internally and with my other programs). Module uses (including strict and warnings) are at the top, followed by the program flow, followed by subroutines (declarations excluded), and then the end of the program. Below is POD as needed. My indentation is consistent throughout, my brace style is consistent, etc. There shouldn't be a chunk of code that looks out of place.

All variables have the proper scope, and are declared when it is most fitting to do so.

No code is obfuscated, and any code that is less than intuitive is commented clearly.

The code is structured in paragraphs. I try to keep the number of consecutive non-empty lines to a sensible number. This way, comments can act as "headers" to my paragraphs of code.

Argument checking is done in most cases, and if I'm writing a module, I'll always use Carp's functions to raise errors.

I've probably left out some concepts, but it comes down to this: would I feel confident showing my code to my fellow developers (or peers in general), and would I expect them to understand the operation of my code without me intervening?

It's more of a relative thing: Something is "cleaner" than something else. There's no threshold beyond which something is considered clean or unclean. I suppose the definition of "cleaner" is "easier to maintain". Many thing can contribute to cleansiness, but the list is subjective. I'd say the foremost item on that list is consistency in style (whatever that style may be).

While the suggestions by other posters have much merit, to me, "clean code" is an elegant expression of an algorithm that stands by itself.

If I need to add comments, beyond describing the mechanism I'm implementing and its data structures, I'm writing dirt and it's time to take a break before I start burying bugs that'll take me days to dig out.

I stay away from a lot of Perl's MTOWTDI features because I'm not comfortable with their readability. I probably go way too far in that direction, but I prefer that my bricks be consistent and interchangeable more than being able to leap tall buildings at a single bound.

At my workplace, we have a requirement that all tools and data be reproducible, maintainable and recoverable for thirty years. That affects one's perspective considerably. :D

As you can see, there are as many definitions of "clean" as there are programmers (which means, according to my definition of "clean", that "clean" is not a very clean concept). Anyway, for me a "clean design" is one that exhibits, few extraneous dependencies (between its parts, between it and external modules, between the app and the OS, between the app and the phases of the moon, etc.). I.e. loose coupling.