著者|あみます
Zebian |呉Xingling
制作|ライフ・プログラム（ID：coder_life）
彼自身の人々に加えて、経験の一種である、コードが理解できる書いていませんか？
シニアプログラマーとして私が掘り下には、これがどのように行われるか皆に教えて？あなたはより多くの次の時間、いわゆるより良い選手を練習することができる場合、私はあなたが他の人が維持できるだけでなく、一日も独自のコード至上のスキルを書くことができるかもしれコードを書くことができます確信して維持されていません。
困難であること、保守コードを書くことができないがコーディング標準、難しいことではありませんし、コア・ポイントは、我々はこれに基づいて、彼女自身の経験上のいくつかを追加する場合、それはより完璧になる、反対です。
ポイントは習得十分ではありませんが、また、1つの原則に注意を払う：我々のコードは一目を維持することができません聞かせてはいけないフォーマットはまだに注意を払わなければならない、と私たちは、これは表面的な面ではありません追求したいに、維持することができないように、私たちが欲しいの本質は維持できないです。
他の誰かがあなたのコードを見ることができた場合は維持し、あなたのコードを書き換えたり再建する必要があるリスクがあること、そしてそれが取り消さがものの痛み、憎しみ、迅速なものの事を愛してはなりませんすることはできません。
再起動思考の従来のプログラミング方法を明確に理解します！
「アートオブウォー」我々は完全に心理的なメンテナンス担当者からのフォローアップのコードを倒すためにしたい場合は、我々はいくつかの従来のプログラミングの考え方を理解する必要があり、「自分自身を知って、自分自身を知っている」行きます。
まず考えて、それは私たち自身のプログラム、およびより大きなコードを引き継いだ場合、一般的に我々はそれがコードを理解することができないと言って、ラインでフィニッシュラインに最初からそれを読む時間がありません。
できるだけ早く地面に線を横断することができるようにするために、一般的な方法は、すぐにコードの一部を変更する必要があるロジックを見つけるために、プログラマのニーズに基づいており、このテストのコードの一部を変更します。このような修飾のみ、ジグソーパズルのピースをコードの小さな部分を見ることができます。
だから我々は何をする必要があり、そのコードの保守担当者は、常に保守担当者は、彼がそれを見つけたいコードのその部分を見つけることができないことを保証しようとする私たちはコードを書く全体像、コードを見ることができないようにすることです。これは、最も重要なの変更が、彼はもののいずれかを無視しませんでした知っているようにすることです、最も重要ではありません。
私たちのよく設計されたトラップの各これらの小さなコードは、我々は慎重にコードのすべての行を読んで、虫眼鏡のようなとのような守備を強制します。
一部の学生は、これがカウンタープログラミング仕様することができ、上記の原理による限り、非常にシンプルであることを考えることがあります。しかし、実際には、だけでなく、私たちの前に注意深く誤用と、それほど単純ではありません。ここでは、いくつかの共通のコア技術のために行くことができます。
Pythonの：コードの半分のメモリフットプリントラインで減らします！
最初の1：注釈のすべての深刻さで無差別使用
このセクションでは、最初の注釈の下で、通常の使用を理解する：注釈は、後に、開発者がすぐにコメントとコードの実際の役割を理解することができ、特にために、開発者がプログラムを理解するために使用されています。
必要な場合はコメント通常の状況下で、コードのコメントの原則は、通常はコメントしています。これは、コードの非常に明確な説明も時間がかかるのコメントを見て、後にすべてのコメントを読むことができるようにするつもりはないされている、非常に正確なナンセンスです。
もう一つの原則は、必要なコードのコメントのアクションに記載されており、コードの実際の役割は同じです。
実際には、一緒にコードのコメントでも、あなたのコードを以下のように変更して修正する必要があります。ここで私たちの役割に関するその他のコメントは我々だけのものと十分にあった、これ以上言うことはありません。
コードを書くために、コードを使用する方法の人々がそれを理解することはできませんコメント？
まず、全体のマルチ役に立ちません
私は作品が2例、2回の治療、強力な実用性に対応した2例を説明分け。
-
クリアスタイルのコメント
守備は明らかにコメントを見て時間を無駄にしてみましょう。
この原則は、目的は人々がコードを読んで誤解している「以上のコメントより読みコードより簡単に」というコメントを読んだ後、守備の部分です。コードを見るときディフェンダー、コードで非常に明確で見て触れますが、コメントをもう一度見があるかもしれません。
このとき、人間の心のコードを読むことの下でつぶやいすることが確かである：コードは私が思ったほど単純ではないようです。
その後、我々は長いコメントを書き、そして最後に読者に、優柔不断の時間変化を読み取ることができません。
あなたはそれを余裕があるなら、あなたはどのようなコメントでのプログラミングの守備を教えることができ、この一般的な破壊が上記よりも高くなり、書き込み、プログラマは、おそらくあなたは、特に彼はそう単純で教えるために、どのようにプログラミング彼を教えるために持っている最も嫌ですプログラミング、致死は倍増しました。
例では次のようになります：
-
放棄されたコードのコメント
文字通りの意味は、通常の状況下では、コードは一般的ではない私たちの即時のコメントの一部アウトまたは削除、コードは、将来の使用には影響しませんにもかかわらず、あなたはバージョン管理ツールからそれを取り戻すことができます、という非常に明確です。
ターゲットアプローチがあり、このコードは、それがコメントしている理由を示す長いコメントを削除するコードを追加するために、このコードは、「捨てられた」されていないこと、また擁護者にメッセージを送信するが、 「一時的な」最初に行います。
コードはこのコメントを見ているかもしれませんほとんどの人は、それがコードを注釈を付けることが無視され、実際の経験に基づいて、ノートプラス注釈だけでなくなり、コードにメモを追加した場合、殺害ポイントでこれを行うには、コードを見て、または他の重要などの情報不足している、すべての後に、コードが彼によって書かれていません。
定型コード：
第二に、この場所は、将来的に変更される可能性が
このタイプのコメントは、私たちはしばしば言及し、「TODO」コメントタイプです。通常の状況下でTODOコメントは、このようなプロジェクトのリリースは、一般的に処分される特定の何日に記載されるように、必要に応じて一般的な必要性を維持するために削除することを推奨されている場合、プロジェクトの初期化TODOコメントは、非常に便利であるときなど、メリットがないわけではありません。プロジェクトのコードに固執する、通常の処理ロジックは、一般的にコメントすることなく除去バグ、その後、できるだけ早く修正のバグを追跡する必要があり、一般的にはお勧めしませんTODOの注釈型です。
上記の説明を通じて、私たちはすでに、コンクリートの一部に対処する方法を知っていると信じています。個人的な勧告が改訂され、より多くのことがあるTODOコメントを書くことが理由、および変更とプランの時間変化を示すものではありません、ので、最後にこれを見て、次の保守要員がさらに混乱している裏返しする必要はありそうにありません、そう、のも殺す効果があります。
定型コード：
第三に、エラーメッセージのコメント
これが原因の一部は、コードとコメントと一致していないことを意味し、注釈情報が正しくありません。
私たちは、変更が行のコメントを変更しません後にコードを完了されなければならない少し余分な作業をしない、比較的容易に、このように、価格は少し、最高のは、そのようなコメントで特殊なを追加することであることに注意することマークは、内部に自身の周りに見て、自分のフォローアップタイムを防止します。
あなたが地面にエーカーの独自の第三に農業ときにそれを増加させないでしょう。このモデルの例としては、シーンが多すぎる、あなたが即興することができます。
第四に、物語
単に、書き込みコードは、もちろん、確かに単純な理由ではない理由を述べています。一般的に、一定期間として、事態のコメントで書くことをお勧めして、誰かが特定の場所でこの問題を取り上げた理由のほかに、誰かがあなたは問題が、このような治療として扱われるべきではないと述べ、これはに対処すべきかと言います、後、彼は両方作っ一定の評価を議論するようにしてそうなので、そのための議論に参加しました、そして最終的に、この機能を実現するために、現在のコードを使用することにしました。
要するに、原理が明らかに優れ、さらに詳細な事項の詳細を記述することです。一部の学生に提案することができるにも書き当日の天気、そこにS *名の賭け金の議論があるが、また持って、私は個人的に天気が適宜追加することができると思いますが、名前はS *に書かれているが奨励されていません、すべての後、同僚は、自分の会社の実際の状況に応じて、すべてが特定のアプローチ、それを選択するために、お互いの世話をします。
定型コード：
第五に、その理由を書いていません
コメントの規範に従うときに、より重要なのは、理由コードは、はいそう書かれたものをと述べた書き方を表現の意味のコメントだけでなく、通訳、。
このような対策は複雑な手続きのために、明らかにされている理由を書き込み、特定の境界値を決定するために、このような決定プログラムの唯一の文字通りの意味を書き留めるためにいくつかの特別な境界条件として、人々が維持されるように、なぜこの値は、無視することができていますそれを推測楽しみます。
第六に、些細な
このプログラムは、コメントの大半がこれよりも一般的に少ないことが示される必要があるでは、一般的にいくつかの複雑なアルゴリズムを説明するために推奨され、より複雑なアルゴリズムより多くの勧告は、原則的には、この部分が書かれるべきです文書に書かれたコードの内容。
詳細設計のすべては、それぞれの数字を追加提案し、アルゴリズムは段落間傾斜するように、サブ段落の注釈内容に書かれていなければならないので、あなたは基本的にその内容コードのコメントやドキュメント一貫性を保証することができます。継続的なメンテナンスは、このようなコメントを表示する際の基本的な保証大きな頭の周りに、多くのそのようなコメントをより良く、そして効果があるかどうか。
コメントの空間モデルの一例を示す図で増加が長すぎるではありません示しています。
七、ユニットの問題
このユニットや時間などの特定のビジネス関連のシナリオ、一般的にピクセル・シーンのサイズ、インチなどに関連する、ミリ秒、秒、分、時間、日、月、年などに関連しているの一部、ファイルサイズは、このようなシーンとして、バイトであります、KB、MB、GBなど。
コードのこのタイプは、私たちの原則はある単位に注釈を付けることではない、ちょうど使用し、あなたがコードで様々なユニットを混在させることができれば、それは当然、より顕著です。
例えば、処理されたファイル上のシーンで、混合使用のKB、MB、GB複数のユニット、順にので、その後のメンテナンススタッフが一部で行われるこのユニットのコードの本当の意味を知るために。
私たちの通常のロジックによると、あなたが理解する必要があり、各データユニット初のコードのこの部分を変更したい人の背後にあるロジックは、確かに以前に明らかに自由に変更できないが、一般的なケースでは唯一のソリューションであり、それはあります何度も何度もデバッグに、各ユニットの実際のデータを計算するためのテストプログラムは、自然にそれがかかる非常に多くの時間です。
八、脅迫
この動きは、キラーレベルのアノテーションであると言うことができますが、プログラムのコードのオプションの一部を追加することができ、そしてそれは明らかに必須ではコメント状態は」と、このプログラムにコメントを追加しますそうでない場合は、プログラムが異常になり、このコードを削除するかコメントアウトしないでください!!!」、注意を払う必要が発生した異常の種類を説明できません。
だから、一度に保守要員は確かにこのコードは最初に自身が前に見た記事のいくつかを考えるだろう見て、しっかりとこの「ナンセンスコードは」確かに削除できないことを信じています。このコードは、複数のコメントはより良い存在する場合。
カバーアップの記事
I.はじめに
めまい、その後、確かに直接リッピングオフ力がする場合、人々はただ無意味な力が完了した後に、コードを見て、主な目的は嫌以降の擁護者である、エントリーレベルのコードステガノグラフィとみなすことが、あなたのコードやメモを一緒にブレンドしてみましょうその後、吐き気の波。
ロジックコードが正確に同じ株であると自然に、より良いそれをダウンコメント場合、具体的な操作は実施例以下のサンプルを参照することができます。
モデル例：
第二に、同義語
このような動きは、一般的にマクロクラスCプログラムで使用するために推奨されている、比較的単純な使用のための原則は、つまり、マクロ名と使用できる雑種の具体的な値は、あなたは私を持って作成し、私はあなたの両方のビューを持っています感じ。
モデル例：
第三に、命名の矛盾
この部分は主に、たとえば、誰もが私はこれを見に関係なく、直接ではないことを信じて、そのような郵便番号のためのWebインターフェイスに表示郵便番号、郵便番号という名前の変数のコード名として、明確で、フロントエンドの開発に使用されていますコードを変更し、それが最終的に変数に対応する郵便番号を確認するために繰り返す必要は郵便番号ではありません。
第四に、マクロ定義は隠されました
これは、ここで注意しなければならない隠されたマクロ定義を非表示にする場所を見つけることができない、それは確かに動作しないことを言っているわけではない、多分私たち自身がそれを変更する必要があります。
ここではマクロ定義はマクロ定義に書き込まれるマクロ定義を隠していないことを意味し、のは、これはマクロ、その後、少し過ぎないと思う一目でコードを見てみましょう。
いくつかの単語の男がモデルに言いました：
第五に、変数名を包みます
私はそれが本当に微々たるものであるため、このトリックは唯一、重要でないとして記述することができます。効果は、その変数名を検索するにはあまりにも困難を読み取ることは難しいです。
モデル例：
第六に、グローバル変数
グローバル変数を区別することは困難であるように、ここでグローバル変数を隠されている、方法は、内部のグローバル変数を使用するときに、関数内で直接使用されるが、パラメータの受け渡しの形で渡された後に使用されていません。
七、関数のオーバーロード
特徴と機能が過負荷にする必要があり、通常の関数のオーバーロードは、近いはずの後、我々はしなければならないです、パフォーマンス関数のオーバーロードと機能オーバーロードは何の関係もありませんしましょう。
この時間は、人々は、コードベースを見れば強力ではありません、それは知識の関数のオーバーロードをブラッシュアップする必要があり、彼の過去の間違ったではありません。
八、演算子のオーバーロード
彼はあなたのコードがある限り、基本的なコードの混乱を用いて、以下の方法として、芸術のレベルに直接取得することができ、非常に奇妙になりようになりますので、演算子のオーバーロードは、非常に異常な動きであり、芸術は、ルーチンを破るためにあります、限り、それはあなたが予期しない結果を受け取ることができます使用する方法を演算子オーバーロードの推奨用途に応じて、一般的ではないとして。
例えばモデル:!クラスオーバーロード演算子、リロード機能しかし、そう!!使用する場合は最初の否定次に、整数を返し、関数がオーバーロードされた呼ぶ、リターンに整数を取ることを許可されていません最後に、ブール値を返し、無知な力を見て。
九、混乱の#define
私は老犬古いドライバが叫びであるべきほど固体でない場合は、コードを見ている人々を過ごすためにこのトリックの後だと思います。私は、これは定型的なコードの下に見ることができるとは思いません。
モデル例：
variableコマンドの記事
まず、任意の大文字と小文字を交互に
这种基本上就是一种骂娘的命名方式，为啥会这么容易引起怒火，看个例子就知道了：gGEtpRoDucTnaME，有没有脑裂的感觉？
二、单字母变量
名称上毫无逻辑可言。
样板代码：
三、字母+数字很配
如果字母a – z 不够使用，可以考虑字母+数字的组合，这样一般就足够使用了，毕竟数字是无限的。
样板示例：
四、故意拼错
变量名称拼错并不是随意一个单词就拼错，此处指的是比较有创意的拼写错误。
因为随意的拼写错误是很容易被发现的，高级的拼写错误由于很难看出来，所以在进行变量搜索的时候根本搜不出来。 比如：SetPintle、SetPintalClosing。
五、重复名称
函数或者方法的内嵌结构中使用和函数或者方法层面中同名的变量名，变量名多的话可能会一阵眩晕。
进阶篇
前面的注释和变量命名可以说是本文的基础篇，主要是较大家一些基本的编程技巧。这一篇作为进阶的一篇，我会给大家介绍一下常见的一些稍微高端的编程技巧，废话不多说，一起看下：
一、void*
不管什么类型的指针一律都用声明定义为void*，当实际用到时再转换为需要的类型。
二、条件表达式
条件表达式这块可以发挥的空间就比较大了，从实际编码情况来看，每个简单的条件表达式都可以进行拆分，看个例子就明白了。
10 == num，拆分为 num >= 99 && num <= 101
三、长代码
什么，一行最多80个字符？ 不行，这才哪到哪，一定要跨行，而且要跨多行，不能因为换行影响了我们写代码的那股激情。
原则就是越长越好，这样后续阅读代码的人就需要来来回回地读，想想都觉得累。
四、嵌套
一个优秀的程序员必须能够在一行代码中使用超过10个小括号()，如果觉得很难得话在一个函数里面使用超过5层的大括号也是可以的，还不行的话把嵌套的条件语句if … else 转为[?:] 也是可以说明你是个优秀的程序员的。
五、不要break
不要在代码的循环中使用break，更不要使用goto，这样可以保证一行break可以处理的代码最少要写5层的if … else 来解决，一遇到break 就多出百十行代码，想想都过瘾，一天下来光看看新增的代码行数就觉得充实。
六、尽量使用XML
XML 的强大是无人能及的，不是JSON、Yaml这些所能及的。项目中使用XML 可以帮助我们将原来只需要10行的代码变为100行(可能还不止)。XML是无所不能的，哪怕是自己封装自己也是可以做到的，信XML 得永生，信XML 的自信!
样板代码：
七、测试
测试，不存在的。
一般建议不要测试，测试是一种懦夫的行为，作为一个优秀的程序员我们必须保持这种对自己代码的自信，再者测试会影响你的生产力，直接影响你写代码的行数，所以测试这一步直接跳过就好啦。
作者简介：阿木，目前就职于国内某知名互联网公司，担任云计算技术部高级工程师，近3年云计算从业经验，爱读书、爱写作、爱技术。
热 文 推 荐
☞V神已抵京, 倒计时4天! 6大理由告诉你为什么要参加"2019以太坊技术及应用大会"
☞Flink最锋利的武器：Flink SQL入门和实战 | 附完整实现代码
、元のテキストを読んでキーワードを入力し、CSDNの記事を検索するにはクリックしてください。
それぞれ「見た目」のあなたのポイント、私は真剣に好きなように