クソみたいに悪いコード、気に入っていますか?

GitHub には、「最良のガベージ コード」に関する 19 の重要な原則を説明するプロジェクトがあります。変数のネーミングからコメントの書き方まで。これらのガイドラインは、できる限り悪いコードを作成する際のガイドとなります。

元の GitHub プロジェクトと同じスタイルを維持するために、以下では変換はありません。読者は反対の視点からあらゆる視点を理解できるため、ゴミコードの作成を避けるのに最適な方法です。

プロジェクトアドレス:
https://github.com/trekhleb/state-of-the-art-shitcode

Ofもちろん、ジャンク コードを記述するための次の 19 のガイドラインはすべてを網羅したものではありません。読者が耐え難い悪いコーディング習慣を見つけた場合は、自分の意見を表明することもできます。

? 第一のルール: 入力する回数は少ないほど良いです

入力する回数が少ないほど、時間は長くなりますコードのロジックやその他の問題について考える必要があります。以下に示すように、「Good」はルールに従っている例を示し、「Bad」はルールに従っていない例を示します。

? 記事 2: 変数/関数の混合命名スタイル

名前付けの多様性を反映できるように、名前付け方法と変数を混合する必要があります。

? 第 3 条: コメントを書かない

コードは理解できるのに、なぜメモを書いたほうがいいでしょうか？言い換えれば、どうせ誰も私のコードを読んでいないのに、なぜコメントを書く必要があるのでしょうか?

#?ルール 4: コメントは母国語で書く

#?第 5 条: 可能な限り異なる形式を混在させる

同様に、コードの多様性を確保するために、一重引用符や二重引用符など、異なる形式を可能な限り混在させる必要があります。同じセマンティクスを持つ場合は、混合する必要があります。

#?第 6 条 コードはできるだけ 1 行で記述する

#?第 7 条: エラーが発見された場合は沈黙を守る

#?第 8 条: グローバル変数を広範囲に使用する

グローバル変数の使用は「グローバリゼーション」に不可欠な部分です。

#?項目 9: バックアップ変数の構築

#?第 10 条: 型の使用には注意が必要です通常、変数は指定しないでください。型チェックを行うか、頻繁に実行します。どの型も最適な型ではありません。

##動作しない 到達不能なコードは、「プラン B」として機能します。

#?第 12 条: ネストされた三角形のルール

#?項目 13: 混合インデントインデントを避ける必要があります。そのため、複雑なコードがエディター内でより多くのスペースを占めることになります。インデントを使用する必要がある場合は、混合インデント戦略を使用してください。もちろん、この戦略は、コードの構造化にインデントに依存する Python では機能しません。

毎回新しいライブラリをインストールし、既存の依存関係を更新します。以前のバージョンを維持する理由は何ですか? 常に最新のサードパーティ コード ベースを維持する必要があります。

#?第 15 条: 長い関数は短い関数よりも優れています

プログラムの全体的なロジックはいくつかのコード ブロックに分割されていますが、IDE が突然失敗し、必要なファイルや関数が見つからない場合はどうなるでしょうか。したがって、main 関数にコードを記述し、追加の関数インポートやコード ファイルを維持しないのが最も安定した方法です。

単一ファイルのコードが 1 万行であっても問題ありません。また、単一関数のコードが 1,000 行であっても問題ありません。

#?第 16 条: コードには特定のテストは必要ありません

#?第 17 条: コードの重複を避けるようにしてください特に少人数のチーム、これは結局のところ「自由」の原則です。

プロジェクトの初期段階では、この状態を一時的に維持できます。

#?第 19 条: 不要なコードを保存する