現実にこういうコードを書く人がいたので、真似しないでねの意味で書いておきます。
実例がx86-64 CPU + Linux + C言語 + GNU gccの環境で書かれていたので、内容もそれに基づいています。
(技術の問題というよりは人や組織の問題になってしまったけど…)

(追記)
ここでのことは、上記環境にて「Webアプリケーションを開発している」という文脈で話しています。

コードの書き方のここが駄目

インデントがグチャグチャ

よくいますね、こういう人。
既存コードのインデントルールを無視して、自分ルールを適用するならまだマシです。
ひたすらにルールがなく、「タブキーを押すのが面倒臭い」くらいの理由でインデントを壊してくれます。

で、こういう人に限ってviやEmacsとか使って「自分はvi/Emacs使えるんだぜ(ドヤァ)」な感じを出しながら、その機能はちゃんと使えてなかったりします。
(vi/Emacsはもちろん素晴らしいエディタです)
コード整形ツールなんて結構あるし、IDEだって一杯あります。でもそういうツールに頼るのは「ズルい」とか言ったりします。

{} 省略記法を多用する

コードが読み辛くて仕方がない。
「括弧を打つのも面倒臭い」くらいの理由です。

変数名が不適切

プログラミングってのは究極的にはネーミングと言っていいくらい名前付けは大切です。
その名前が実体に即したものでないと読んでいる人が混乱します。
ループカウンタでi、j、kとか使うのは別に良いんです。その変数のスコープが限られていた上でなら、それがカウンタだってことは分かりますから。

実例を言うと…

r1、r2、r3…とかいう変数をint型で用意しておく。
各変数に、どのような意味の値が入るかは決まっていない。
- ループカウンタかもしれないし、何か処理対象となるデータかもしれない。
- ある時点で同じ変数名にどのような意味のデータが入っているか…それはコードを先頭から読まないと理解できない。
型が異なる場合には、キャストで強制変換して解釈する。

…難読プログラミングチャレンジでもしてるのかっつ〜の。

「rって何?」って聞くと「registerのrですよ(当然だろ?)」みたいな返答をしてくる。

バッカじゃねぇの!?

8bitや16bitの時代のコード書いているんじゃないんだぜ?

コードフローが階段状になっている

私が良いコードフローと思うことが多いのは…

mainが処理Aを呼び出す。
mainが処理Aの結果を受け取る。
mainが処理Bを呼び出す。(そのパラメータに処理Aの結果が用いられるかもしれない)
mainが処理Bを呼び出す。
プログラム終了。

みたいな形で処理Aと処理Bが独立したコードになっている時です。

対してダメなコードは…

mainが処理Aを呼び出す。
処理Aが処理Bを呼び出す。(そのパラメータに処理Aの結果が用いられるかもしれない)
return → return …
プログラム終了。

こんな感じで処理Aと処理Bが独立しておらず、個別にデバッグすることも分離することも出来なくなってます。
これは関数に分けて設計するとかモジュール性を高めるってことが全く分かっておらず、長大な1個の関数を適当にブツ切りしているだけの書き方です。

こうすれば速くなるんですよ!! (証拠は無い)

「早すぎる最適化」はプログラミングで戒めるべきであるということは周知の事実ですが、未だに理解していない人もあります。
プログラムが高速に動くんであればそれに越したことは確かにないんですが、高速化したというなら証拠(比較結果)を出してくださいな…
ましてやその高速化が…

インラインアセンブラを使えば速い!
C言語(ネイティブコード)だから速い!

程度の浅はかな対処だったりするもう、何と言ってよいやら。

設計のここが駄目

外部プログラムとのデータ交換に使うデータのフォーマットはC言語の構造体をバイナリダンプしたもの

… 1970年代の話でしょうか、これは?
エンディアンとか知ってる?
しかも、このバイナリダンプの内容をWord文書にシコシコと表にして書いて、「データフォーマット仕様書です」とか…orz

ビットがもったいない(と言いつつ現実は見ない)

バイナリデータの設計をするにあたって、「データ長」 + 「データ内容」という構造があったとします。
ここで「データ長」を実際の値を1bit右シフトすることで、「型のサイズの2倍までデータ長を表現できます!」とか息巻いている。
…あのね、そうすると当然データ長は偶数にならなければならないわけだ。
なのにデータ内容は1byte単位で増減するので、必ずしも偶数byte長にはならないわけだ。
その時はどうする?と聞いたら…
「末尾に1byteのpaddingを入れればいいでしょ?」
と返答された…(唖然)
1bitを節約するために、1byteの無駄データを入れるわけですよ。

あるデータをどう解釈するかは、データ先頭から読み込んだ場合の状態遷移で決まるので、データの特定箇所だけを見ても分からない

…まぁ、そういう複雑なデータ構造があるというのは理解します。
ただ、それはどうしてもそういう難しいデータ構造でなければ表現できない場合に使うべきであり、徒に用いるべきではないと思いますね。
また、こういうデータ構造をどうしても使いたい場合には、途中にwater markとかを設けてエラー検出できるようにしておかないと後で困ります。必ず。

以上