GitHub には、「最良のガベージ コード」に関する 19 の重要な原則を説明するプロジェクトがあります。変数のネーミングからコメントの書き方まで。これらのガイドラインは、できる限り悪いコードを作成する際のガイドとなります。
元の GitHub プロジェクトと同じスタイルを維持するために、以下では変換はありません。読者は反対の視点からあらゆる視点を理解できるため、ゴミコードの作成を避けるのに最適な方法です。
プロジェクトアドレス:
https://github.com/trekhleb/state-of-the-art-shitcode
Ofもちろん、ジャンク コードを記述するための次の 19 のガイドラインはすべてを網羅したものではありません。読者が耐え難い悪いコーディング習慣を見つけた場合は、自分の意見を表明することもできます。
? 第一のルール: 入力する回数は少ないほど良いです
入力する回数が少ないほど、時間は長くなりますコードのロジックやその他の問題について考える必要があります。以下に示すように、「Good」はルールに従っている例を示し、「Bad」はルールに従っていない例を示します。
? 記事 2: 変数/関数の混合命名スタイル
名前付けの多様性を反映できるように、名前付け方法と変数を混合する必要があります。
? 第 3 条: コメントを書かない
コードは理解できるのに、なぜメモを書いたほうがいいでしょうか?言い換えれば、どうせ誰も私のコードを読んでいないのに、なぜコメントを書く必要があるのでしょうか?
#?ルール 4: コメントは母国語で書く
ルール 3 に違反した場合は、少なくともコメントを書くときは母国語または他の言語で行う必要があります。あなたが英語を母国語とする場合は、このルールを破ることになります。ほとんどのプログラミング言語は英語なので、他の言語を使用してコメントしてみてはいかがでしょうか?#?第 5 条: 可能な限り異なる形式を混在させる 同様に、コードの多様性を確保するために、一重引用符や二重引用符など、異なる形式を可能な限り混在させる必要があります。同じセマンティクスを持つ場合は、混合する必要があります。 #?第 6 条 コードはできるだけ 1 行で記述する #?第 7 条: エラーが発見された場合は沈黙を守る #?第 8 条: グローバル変数を広範囲に使用する グローバル変数の使用は「グローバリゼーション」に不可欠な部分です。 #?項目 9: バックアップ変数の構築 #?第 10 条: 型の使用には注意が必要です通常、変数は指定しないでください。型チェックを行うか、頻繁に実行します。どの型も最適な型ではありません。 ##動作しない 到達不能なコードは、「プラン B」として機能します。 #?第 12 条: ネストされた三角形のルール #?項目 13: 混合インデントインデントを避ける必要があります。そのため、複雑なコードがエディター内でより多くのスペースを占めることになります。インデントを使用する必要がある場合は、混合インデント戦略を使用してください。もちろん、この戦略は、コードの構造化にインデントに依存する Python では機能しません。 毎回新しいライブラリをインストールし、既存の依存関係を更新します。以前のバージョンを維持する理由は何ですか? 常に最新のサードパーティ コード ベースを維持する必要があります。 #?第 15 条: 長い関数は短い関数よりも優れています プログラムの全体的なロジックはいくつかのコード ブロックに分割されていますが、IDE が突然失敗し、必要なファイルや関数が見つからない場合はどうなるでしょうか。したがって、main 関数にコードを記述し、追加の関数インポートやコード ファイルを維持しないのが最も安定した方法です。 単一ファイルのコードが 1 万行であっても問題ありません。また、単一関数のコードが 1,000 行であっても問題ありません。 #?第 16 条: コードには特定のテストは必要ありません #?第 17 条: コードの重複を避けるようにしてください特に少人数のチーム、これは結局のところ「自由」の原則です。
プロジェクトの初期段階では、この状態を一時的に維持できます。 #?第 19 条: 不要なコードを保存する
以上がクソみたいに悪いコード、気に入っていますか?の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。