良いコードを実行する：良いコードの8つのルール

プログラミングを学んだ事実上誰もが、Steve McConnellの本Perfect Codeを知っています。 まず第一に、印象的な厚さ（約900ページ）で常に印象的です。 残念ながら、現実には、印象がこれに限定される場合があります。 しかし、無駄に。 プログラマはさらに専門的な活動を行う中で、本に記載されているほとんどすべての状況に遭遇し、経験的に同じ結論に達します。 知り合いが近ければ、時間と労力を節約できます。 GeekBrainsでは、トレーニングへの統合アプローチを採用しているため、優れたコードを作成するためのルールに関する学生向けのウェビナーを実施しました。







Habréの最初の投稿へのコメントで、ユーザーは情報認識のチャネルを積極的に議論しました。 優れたコードの基本原則は、どの言語で書くプログラマーでも同じであるため、「完璧なコード」のトピックを作成して記述すべきだと考え、決定しました。

すべてがこのように機能するのに、なぜ良いコードが必要なのですか？

プログラムはマシンによって実行されるという事実にもかかわらず、プログラムコードは人によって、そして人のために書かれています-高レベルのプログラミング言語が人間に優しい構文とコマンドを持っていることは偶然ではありません。 現代のソフトウェアプロジェクトは、プログラマーのグループによって開発され、オフィススペースだけでなく、大陸や海洋によって分けられることもあります。 幸いなことに、技術開発のレベルにより、雇用主の所在地に関係なく、最高の開発者のスキルを使用することができます。 この開発アプローチでは、コードの品質、特に読みやすさと理解しやすさについて、深刻な要件が課されます。



コード品質基準には多くの有名なアプローチがあり、遅かれ早かれほとんどすべての開発者が知るでしょう。 たとえば、KISSの設計原則（Keep It Simple、Stupid！-Make it easy、dumbass！）に従うプログラマーがいます。 この開発方法は非常に公平で尊敬に値し、優れたコードの普遍的なルールであるシンプルさと明快さも反映しています。 ただし、単純さには境界が必要です。プログラムの順序とコードの可読性は、単純化の結果であってはなりません。 単純さに加えて、いくつかの単純なルールがあります。 そして、彼らは多くの問題を解決します。

• テストとデバッグで簡単なコードカバレッジを提供します。 ユニットテストは、モジュール、つまりプログラムの一部である関数とクラスをテストするプロセスです。 プログラムを作成するとき、開発者はコードの作成作業の最初からテストの可能性を考慮する必要があります。
  
  
  
  
• コードの認識とプログラムの使用を促進します。 これは、論理的な命名と優れたインターフェイスと実装スタイルによって促進されます。
  
  
  
  
• メンテナンスを容易にします。 考え抜かれ実装されたプログラムの構造により、新しいハードウェアまたは新しいプラットフォーム上のプログラムに関連する問題を解決できます。
  
  
  
  
• さらに変更を加えるプロセスを簡素化します。 構造が最適化されるほど、コードの変更、新しいプロパティの追加、パフォーマンスの向上、アーキテクチャの変更が容易になります。
  
  
  
  
• プログラムの持続可能性を確保します。 変更したり、問題が発生した場合は、簡単に修正できます。 正しいエラー処理により、ソフトウェア製品の操作が大幅に促進されます。
  
  
  
  
• 複数の開発者またはコミュニティ全体でプロジェクトをサポートする機能を提供します（特にオープンソースプロジェクトにとって重要）。

エンターテインメントの作成、企業ソフトウェアの作成、プログラミングスキルの開発、産業用ソフトウェアの作成など、明確な目標を持つ開発者のアイデアをコードで実現します。大規模プロジェクトが届きます。

GeekBrainsによる8つの優れたコードのルール

単一のコードスタイルに従います。 プログラマーが組織、特に大規模な組織で働くようになると、ほとんどの場合、特定のプロジェクトでコードを設計するための規則が紹介されます（コードスタイルに関する合意）。 これは雇用主の偶然の気まぐれではなく、深刻なアプローチの証拠です。



以下に一般的なルールを示します。



中括弧とインデントを観察する-これにより、コードの個々のブロックの認識が大幅に向上します

垂直ルールに従う-1つのリクエストまたは条件の一部をインデントする必要があります

if (typeof a ! == "undefined" && typeof b ! == "undefined" && typeof c === "string") { //your stuff }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

放電を観察する-コードの可読性を向上させる場所にスペースを入れます。 これは、複合条件、たとえばサイクル条件で特に重要です。

 for (var i = 0; i < 100; i++) { }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

一部の開発環境では、別のファイル（Visual Studioで利用可能）に設定を読み込むことで、最初にコードのフォーマット規則を設定できます。 したがって、プロジェクトのすべてのプログラマは自動的に同じタイプのコードを取得し、これにより知覚が大幅に向上します。 長年の練習の後、再訓練して新しいルールに慣れることはかなり難しいことが知られています。 ただし、どの会社でも、コードスタイルは厳密に守らなければならない法律です。



マジックナンバーを使用しないでください。 マジックナンバーがアンチプログラミングパターン、つまりプログラムコードを記述しない方法のルールとして分類されることは偶然ではありません。 ほとんどの場合、アンチパターンとしてのマジックナンバーは、コードで使用される定数であり、その意味はコメントなしでは不明です。 このような数値は、コードの理解を複雑にし、可読性を損なうだけでなく、リファクタリング中に問題をもたらします。



たとえば、コードには次の行があります。

 DrawWindow( 50, 70, 1000, 500 );
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

明らかに、コードにエラーを引き起こすことはありませんが、その意味は誰にも明らかではありません。 怠けすぎず、すぐにこのように書くのがはるかに良いです：

 int left = 50; int top = 70; int width = 1000; int height = 500; DrawWindow( left, top, width, height );
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

一般に受け入れられている定数を使用するとき、たとえば、数値πを書き込むときに、マジックナンバーが発生することがあります。 プロジェクトが作成されたとします：

 SquareCircle = 3.14*rad*rad
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

何がそんなに悪いの？ しかし、悪いことがあります。 たとえば、作業中に高精度の計算を行う必要がある場合、コード内のすべての定数の出現を探す必要があり、これは労力の無駄です。 したがって、次のように記述する方が適切です。

 const float pi = 3.14; SquareCircle = pi*rad*rad
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ちなみに、仲間のプログラマーは、使用した定数の値を覚えていない場合があります。その場合、彼らはコードでそれを認識しません。 したがって、変数で宣言せずに数値を記述することは避けた方がよく、定数値でさえ宣言する方が適切です。 ところで、これらの定数はほとんどの場合組み込みライブラリにあるため、問題は自動的に解決されます。



変数、関数、クラスには意味のある名前を使用してください。 すべてのプログラマーは、「コード難読化」という用語を知っています。難読化アプリケーションを使用して、プログラムの年度を意図的に難読化します。 実装を非表示にし、コードを不明瞭な文字セットに変えたり、変数の名前を変更したり、メソッドや関数の名前を変更したりします...残念なことに、変数や関数の無意味な名前が原因で、難読化なしでもコードが混乱して見えることがあります：var_3698、 myBestClass、NewMethodFinalなど...これは、プロジェクトに参加する開発者を防ぐだけでなく、コメントの数が無限になります。 一方、関数の名前を変更することで、コメントを取り除くことができます-その名前自体がその機能について語っています。



その結果、いわゆる自己文書化コードが作成されます。これは、コードを見たときに変数や関数がどのように機能するかが明確になるような名前が付けられている状況です。 自己文書化コードのアイデアには、多くの支持者と反対者がいますが、その議論は検討する価値があります。 通常は、バランスを保ち、コメントと「話す」変数名の両方、および正当な場合には自己文書化コードの可能性を賢明に使用することをお勧めします。



たとえば、次のようなコードを使用します。

 //  ,   r if ( x != null ) { while ( xa != null ) { x = xa; r = xn; } } else { r = ””; }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

解説から、コードが正確に何をするかが明確になるはずです。 しかし、xaとxnが何を意味するのかは完全には不明です。この方法で変更を加えてみましょう。

 //  ,    leafName if ( node != null ) { while ( node.next != null ) { node = node.next; leafName = node.name; } } else { leafName = ””; }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

この段落では、コメントについて個別に言及する必要があります。リスナーは常に、その使用の適切性と必要性​​について多くの質問をするからです。 コメントが多いと、コードの可読性が低下します。 コメントの必要性がなくなるように、コードにそのような変更を加える機会はほとんど常にあります。 大規模なプロジェクトでは、APIを使用する場合、サードパーティモジュールのコードの接続を指定する場合、論争の的となるポイントまたは追加の処理が必要なポイントを指定する場合、コメントが正当化されます。







さらに2つの重要なルールを1つの説明にまとめます。 意味のある名前を持つ新しい抽象化レベルとしてメソッドを作成し、 メソッドをコンパクトにします。 一般に、今日、すべてのプログラマーはコードのモジュール性を利用できます。つまり、可能な場合は抽象化を作成するよう努力する必要があります。 抽象化は、機能の実装の詳細を隠す1つの方法です。 プログラマーは、個別の小さなメソッドを作成することにより、各関数の実装を含むブロックに分割された優れたコードを取得します。 このアプローチでは、多くの場合、コードの行数が増加します。 メソッドの長さが10行以下であることを示す特定の推奨事項もあります。 もちろん、各メソッドのサイズは開発者の自由裁量であり、多くの要因に依存します。 私たちのアドバイス：簡単です。メソッドをコンパクトにして、1つのメソッドが1つのタスクを実行するようにします。 個々のレンダリングされたエンティティは、たとえば、メソッドの最初に入力検証を挿入するなど、改善が容易です。



これらのルールを説明するために、前の段落の例を取り上げ、コードにコメントが不要なメソッドを作成します。

 string GetLeafName ( Node node ) { if ( node != null ) { while ( node.next != null ) { node = node.next; } return node.name; } return ””; }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

最後に、メソッドの実装を非表示にします。

 ... leafName = GetLeafName( node ); …
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

メソッドの先頭で入力を確認してください。 コードレベルでは、すべてまたはほとんどすべてのメソッドで入力検証を行うことが不可欠です。 これは、ユーザーの行動によるものです。将来のユーザーは、プログラムの誤動作を引き起こす可能性のあるデータを入力できます。 どの方法でも、一度しか使用されなかった場合でも、データ検証を整理し、エラー処理を作成する必要があります。 メソッドは抽象化のレベルとして機能するだけでなく、再利用にも必要なため、これには価値があります。 原則として、検証を行う必要があるメソッドと検証する必要がないメソッドにメソッドを分割することは可能ですが、完全な信頼と「andなユーザー」からの保護のためには、すべての入力データをチェックする方が良いです。



以下の例では、入力がnullにならないようにチェックを挿入します。

 List<int> GetEvenItems( List<int> items ) { Assert( items != null); List<int> result = new List<int>(); foreach ( int i in items ) { if ( i % 2 == 0 ) { result.add(i); } } return result; }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

継承によって「is」関係のみを継承します。 その他の場合-構成。 合成は、コードの認識を容易にすることを目的とした重要なパターンの1つであり、継承とは異なり、カプセル化の原則に違反しません。 クラス舵とクラスホイールがあるとします。 CarクラスはAncestorクラスWheelの相続人として実装できますが、CarにはWheelクラスのプロパティも必要です。



したがって、プログラマは継承を生成し始めます。 しかし、哲学的論理の観点からすれば、Carクラスは要素の複合体です。 継承を使用して新しいクラスを作成するときにこのようなコードがあると仮定します（ScreenElementクラスはCoordinateクラスのフィールドとメソッドを継承し、このクラスを拡張します）。

 lass Coordinate { public int x; public int y; } class ScreenElement : Coordinate { public char symbol; }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

構成を使用します：

 lass Coordinate { public int x; public int y; } class ScreenElement { public Coordinate coordinate; public char symbol; }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

構成は継承の優れた代替手段であり、このパターンは記述されたコードをさらに理解するために簡単です。 このルールに従うことができます。目的のクラスが祖先クラスに類似しており、他のクラスのメソッドを使用しない場合にのみ、継承を選択します。 さらに、構成によってプログラマは別の問題から解放されます-継承中に発生する名前の競合がなくなります。 構成には欠点もあります。オブジェクトの数を複製すると、生産性に影響する可能性があります。 ただし、これもプロジェクトの規模に依存するため、それぞれのケースで開発者が個別に評価する必要があります。



実装からインターフェイスを分離します。 プログラムで使用されるクラスは、インターフェース（外部からクラスを使用する場合に使用可能）と実装（メソッド）で構成されます。 コードでは、インターフェイスを実装から分離して、OOPの原則の1つであるカプセル化に準拠し、コードの可読性を向上させる必要があります。



クラスを取る：

 class Square { public float edge; public float area; }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

別のクラス：

 class Square { public float GetEdge(); public float GetArea(); public void SetEdge( float e ); public void SetArea( float a ); private float edge; private float area; }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

2番目のケースは、プライベートアクセス修飾子を使用して実装を隠すため、望ましい方法です。 コードの読みやすさを改善することに加えて、小さなインターフェイスを作成する規則と組み合わせて実装からインターフェイスを分離することは、別の重要な利点を提供します：プログラムの誤動作の場合、障害の原因を見つけるためにチェックする必要がある機能はわずかです。 開いている関数とデータが多いほど、エラーの原因を追跡することが難しくなります。 ただし、インターフェイスは完全であり、必要なすべての操作を実行できるようにする必要があります。そうしないと役に立たなくなります。



ウェビナーの中で、「あなたは正しく書くことができ、それをリファクタリングすることはできませんか？」と質問されました。おそらく、数年または数十年のプログラミングの後、特にプログラムのアーキテクチャの初期ビジョンがある場合、これが可能になります。 しかし、いくつかのリリースと改良の繰り返しを通じてプロジェクトの最終状態を予測することはできません。 そのため、プログラムの開発の持続可能性と能力を保証する上記のルールを常に覚えておくことが重要です。



ビデオを通じて情報を認識し、ウェビナーの詳細を聞きたい人-ビデオ版：







他のウェビナーはこちらでご覧いただけます 。