

プログラムの書き方について質問させてください。

仕事で他の方が書いたプログラムを見てると「=」の前後にtabが複数入れられていることがよくあるのが気になりました。  
例をあげると下記のような書き方です

[code]

    $hoge            =    array();
    $fuga        =        fugakansu();
    
[/code]

他にも宣言する変数があって、それらと「=」の場所を合わせている……とかならまだわかるんですが、変数1個だけ宣言しているところでもこの書き方でした。

かと思えば「=」の前後にスペースが1個ずつ入っている書き方もあったりするのでルールがよくわからないです。

私が書く場所については今のところ「=」の前後にスペース1つずつで書いているんですが、私が知らないルール？お約束？みたいなものがあれば教えていただきたいです。


CC BY-SA 4.0
2022-08-12T01:56:45.757
90514
2022-08-12T03:00:20.003
28635
question
プログラミング言語
なぜ「=」の前後にtabを入れるのでしょうか？


おそらく開発者の好みまたはコピペで書かれているだけでルールがないように見えます。

前提知識として、ルールや約束はプログラミング言語ごとに **コーティング規約** (Coding Styleとも)が決まっています。  
コーティング規約は言語ごとに強制力が異なります。

言語自体の規約は存在しない例が多いですが、  
言語の公式サイトが規約やガイドを出している[Kotlin](https://kotlinlang.org/docs/coding-
conventions.html)の例や、  
言語を利用する会社が外部向けにコーティング規約を公開している[Google C++
スタイルガイド](https://ttsuki.github.io/styleguide/cppguide.ja.html)の例、  
言語そのものが強力な規約を持つGo言語のような例もあります。

もう一つの前提知識として、公式のコーティング規約や有名な規約についてはコードを解析して自動的に整形してくれる **フォーマッタ**
が用意されている場合があります。  
Go言語の`go fmt`やPythonの規約である[PEP
8](https://pep8-ja.readthedocs.io/ja/latest/)に準拠する`autopep8`などが挙げられます。

さてご質問のルールですが、イコールなどの左辺と右辺をつなぐ代入演算子や比較演算子の前後にタブ文字を使う規約は少数派のはずです。(そもそも2010年以降はインデント[行頭をそろえるためのスペース/タブ]にタブ文字自体を使う例が減少している印象を受けます)  
ざっと調べたところ、[WordPressの規約](https://ja.wordpress.org/team/handbook/coding-
standards/wordpress-coding-
standards/php/#%E3%82%A4%E3%83%B3%E3%83%87%E3%83%B3%E3%83%88)では、インデントにタブ文字を使いますが、演算子の前後にタブを使わないことが明記されています。  
でもPHPのコーディング規約である[PSR](https://www.wakuwakubank.com/posts/416-php-
psr/)には「インデントには４つのスペースを使用し、タブは使用してはいけない。」と記載されていて、同一の言語でもルールが異なる場合があります。

規約が統一されない中で、開発者が最も重視すべきルールは **社内で決めたコーディング規約** です。  
明文化されたドキュメントがあるならばそれに従いましょう。  
一人だけ **俺ルール** にしたがって無視すると、まさに質問されているように後任の方が混乱します。  
また、厄介なことに社内の規約は明文化されていない場合や、部署によって方言がある場合が往々にして発生します。

> 変数1個だけ宣言しているところでもこの書き方  
>  かと思えば「=」の前後にスペースが1個ずつ入っている書き方

上記については、きれいに整形されているコードをコピペして謎のタブが発生したり、後日に別の人が改修してルールが変わったり、デスマーチで間違えたりします。

そのため、プログラムの書き方のベストプラクティスは

  * 明文化されたルールの存在を確認する
  * それ以外は何となく過去のコーディングスタイルに従う
  * 分からないところは先輩に聞く
  * 上記を行ったコードが大体完成したら **コードレビューを受ける**

ことだと思います。

なお、何となく未定義のルールが跋扈していると[鼻から悪魔が飛び出し](https://ja.wikipedia.org/wiki/%E6%9C%AA%E5%AE%9A%E7%BE%A9%E5%8B%95%E4%BD%9C)たりするので、この機会に社内のコーディング規約を明文化すると価値ある情報になるかもしれません。

ちなみにPEP
8には[一貫性にこだわりすぎるのは、狭い心の現れである](https://pep8-ja.readthedocs.io/ja/latest/#section-2)と記述されています。  
杓子定規に社内の規約が整備され続けている方がレアケースですので、あまり厳格にとらえすぎて **無駄な労力やリファクタリングのコストを払いすぎない**
ことも現実解として非常に有効です。


CC BY-SA 4.0
2022-08-12T03:00:20.003
90516
2022-08-12T03:00:20.003
9820
90514
answer