いたって主観的な形容で判断基準も個々それぞれだと思います。
(業務系と制御系では視点が異なる面がありますので、ここでは業務アプリとします。)
話題になる対立点として
・汚いけど確実に動く(製造が早い)
・綺麗けどバグが多い
・行儀が良いけど冗長(製造が遅い)
がよく言われたりします。しかし対立する項目でしょうか? そもそも三点を同列に位置付けて対立構図にすることに無理があるように感じるのです。
対立の意を考えると、「汚いけど動く」派の言い訳のように聞こえるのです。
確かに、その場限りのプログラムだと、汚く早く作ることもあります。(私も、使い捨てプログラムの時は、やったりします。後でソースをみて、これの意味はなんだ..と悩みます。...orz)
業務アプリのソースはプログラマー個人の所有物ではないことを考えると、良くないでしょう。他人が保守することを前提にするならば、他人に意図が的確に伝わる記述が必要です。
表現方法としての、コメントの在り方、コーディングルールの決め方は様々でしょうが、決まっている事に意義があります。
そこまで考えなくても、プログラム作成した本人も、1週間で他人になるのは承知の事実。自分のためにも読みやすくしたいものです。
教科書通りの綺麗な行儀の良いソースだが、エラーケースが抜けてたり、正常系しか考慮してない、業務的に破綻しているソースを書く人が時々います。(少数ですが)
上記の対立の前提条件は、この人たちと他の綺麗に書く人を同等にしている所にありますね。
まともなプログラマは違いますよね。行儀よく書けば必然的に綺麗な仕上がりになる、不具合が発生した際の追跡が楽(デバッグしやすい)。コーディングパターン化できるので他の開発に流用が効く。このような事を無意識の内に体得しているのでしょうね。
この意識付けは最初が肝心です。初心者の段階で体得しないと、悪癖が身に付いてからは修正が大変です。
確かに、身に付くまでは、作業も遅く非効率的でしょうが、長い目で良い技術者に育てるほうが本人/会社/業界の為だと思うのです。
主観的な経験則ですが。 行儀の良い綺麗なソースにバグは少ない。 汚いソースはヤッパリ、バグが多い。