I've been trying to stay out of this conversation. Mainly because folk have strong views about such things (and I have strong views too, which I might have expressed here once or twice ), and because I've worked in many, many places and have seen the best intentions wreak havoc in codebases.
My experience (and I'm old) is that many of our pithy statements of "good practice" can be misunderstood (usually through lack of experience and exposure to truly maintainable code -- I'm avoiding the use of "high quality" code, because, like driving skills, everyone believes they are in the best 50% ).
Perhaps the most commonly misunderstood pithy principle is DRY, mainly due to lack of understanding/awareness/comprehension of the difference between syntactic and semantic duplication. It's a far more subtle principle that it first appears.
Lack of understanding of DRY, but applying it verbatim, has created many a ball of string I've helped untangle; often to the bemusement of some developers.
With OO languages, I'd wager the most important principle is "Tell, don't ask". For sure, all the SOLID principles are good, but if you adhere to "Tell, don't ask" (i.e. use objects as objects), you'll probably have a codebase that can be refactored without too much pain.
The least important, and the most disruptive practice, ime, is enforced linting. This is imperialstic OCD imposition If you fly into a foaming-mouthed frenzy at someone writing
if ( ! blah) instead of
if (! blah), then you should probably change career. I've seen more hours spent over discussions of such heinous whitespace crimes than the provacateurs would ever spend learning to understand DRY or SOLID or "Tell, don't ask".
btw, if you run PSR-2 linters, then it will "fail" your code for
if ( ! blah) instead of
if (! blah). What a fabulous waste of someone's time that is.
The principles @pads linked to seem pretty sensible to me. The only problem being that a lot of devs won't really understand them. I know they think they will -- I work with devs too -- but they mostly don't. Folk mean well, but principles like those I've mentioned were formulated by folk who've spent their lives messing with software. You can't distil that experience into pithy sentences nor a wikipedia page.
Linting, ime, is the work of the devil. Devs care. Devs mean well. Most devs are really keen to learn, if folk take the time to coach. They'll create a consistent codebase without imperialstic OCD imposition, and be happier for it.
I also have strong opinions on this subject which I'd be happy to share