インデント/空白についてはどの程度厳しくすべきですか？[閉まっている]

私たちの開発プロセスは次のとおりです

タスクのコーディング->他の誰かのQAコードとドキュメント->タスクはトランクにマージされます。

最近、インデントと空白の問題のために、同僚がコードQAの合格を拒否しています。

これらの問題の例を次に示します（構文はSAS）。

追加の空白：

        %if &syserr gt 0 %then %goto err; /*last line of code*/




/* Footer area*/

余白の余分な行、およびproc sort内でインデントされていない：

 /* End Of header * * * * * * * * * * * * * * * * * * * * * * * * * * * * * */


    proc sort data = %dataset ;
    by id; 
    run;
    %if &syserr gt 0 %then %goto err; 

    proc sort data = &second_dataset.;
    by id;
    run; 
    %if &syserr gt 0 %then %goto err; 

ステップ間の余分な空白：

        /*join all details on for each record*/
        proc sort data = &data out = data_srt ; 
              by &conditions; 
        run;
        %if &syserr gt 0 %then %goto err;

        proc sort data = &data2.;
              by &conditions.;
        run; 
        %if &syserr gt 0 %then %goto err; 




        /*cartesian join*/
        data new_data;
              join data 
                          &data2.  ;
              by &conditions; 

        run;

問題は、優れたプログラマーであるあなたのコードを見て、このようなことをすべて修正することが正しいことなのか、それともとんでもないことなのでしょうか。

さらに複雑な点があります。継続的な統合や自動テストがないため、QAerがこれらの問題をすばやく修正してコードをコミットすることができず、セミコロンなどを誤って削除してしまう危険があります。（公平を期すために、リスクは最初の開発者がこれらの変更を行う際に適用されるため、このミスが発生した場合は、修正して先に進む必要があります）。

はい、それは正しい応答です。インデントスタイルは、すべてのコードで一貫している必要があります。

一貫したインデントの価値の大きな部分は、それが一貫しているということです。そうすれば、人々はそれを簡単に読むことを学び、それにより全員がスピードアップします。

私の経験則では、機械的に適用できる限り、チームが望むどのようなインデントスタイルも適切です。機械的に適用するということは、標準の詳細を学んだり、空白をいじったりする必要がないことを意味します。

機械的なフォーマットは、エラーが目立つもう1つの方法にもなります。コードをブロックで囲んだと思われる場合は、フォーマットツールがインデントを解除し、めちゃくちゃになっているのは明らかです。これにより、リファクタリングも簡単になります。コードのブロックを関数に抽出すると、オートフォーマットによって余分なインデントが削除されます。

オートフォーマットとは、他の誰もが使用する標準に本当に耐えられない場合でも、コードを好きなようにフォーマットし、チェックインする前に再フォーマットできることを意味します。レビューのステップがあるので、レビューの前にそれを行ってください。そうしなかった場合は、それがピックアップされます。

GNUインデントは、ほとんど何でもオートフォーマットできるツールの1つです。私は簡単に検索しましたが、SAS コードを自動フォーマットするツールがあるようですが、SASツールはそれを行いません。

これは絶対に正しいことです。コード品質の最大の要素の1つは、その読みやすさです。コードを適切にインデントしておらず、どこにでもランダムな空白がある場合、コードの可読性が低下します。

一般的に、インデントと空白に関しては、開発チームはすべて同じコード品質基準に従う必要があります。コードベースの他のモジュールがステップ間に余分な空白を入れない場合は、これも含めないでください（もちろん、読みやすさが向上します）。

私はSASプログラマではありませんが、コードをレビューしていて、インデントがすべて整然としていて、整然としていないようであれば、フォローアップのためにコメントします。本当に悪い場合は、レビューに失敗します。

ボブおじさんが自分の本で述べているように、書式設定（空白も含む）は非常に重要です。ソフトウェアは、書かれたものよりもはるかに頻繁に読み取られる傾向があるため、クリーンで読みやすいものにする必要があります。それはコミュニケーションの方法です。

理想的には、チームで作業しているときに基準を決定し、誰もがそれに従うことが理想的です。理想的には、個々のコードレビューで標準を細かく選ぶのではなく、適切なツールをセットアップしてください。（あなたのケースでどのツールが機能するかわかりません。JavaのcheckstyleやC＃のStyleCopなど）。

だから私はあなたの同僚とチャットして、空白に関するいくつかのガイドラインが思い付かないかどうかを確認します。コードのクリーンアップに数分かかることは、将来的に一貫性を保つために価値があります。

何年も前の経験から、インデントが壊れたF-16C / Dコードを読んだとき、インデントを正しくすることは非常に重要だと言わざるを得ません。

手作業で行うべきではなく、手作業で修正してはならないほど非常に重要です。これがコンピュータの目的です。

彼らはあなたの会社の好みのスタイルに合うようにソースコードを自動的に再フォーマットできるコンピュータプログラムを作ります。それらの1つをソースコード管理システムに接続して、チェックインするたびにコードが自動的に準拠するようにします。