I generally define things more in terms of "not bad" or "less bad" - to me software development is too rapidly an evolving discipline to allow for a static definition of good.
But things like:
- don't copy, paste and tweak a piece of code when additional parameters are a better option,
- don't grossly overload a definition with parameters instead of breaking up a function.
There's nuance there, and the question of what amount of technical complexity is reasonable for a given problem - but if I start thinking about that I'll never stop digressing.
I have dealt with an entire office of people who seemed to code purely in bug-filled technical debt: you could tell when they clocked on because the build broke an hour later.
As far as FP is concerned, I think that the memory and performance penalties are often too heavy: there's certainly a place for mathematically provable programming - I just don't know what it is.