受付中 インデントにタブを使うことのデメリット

> 以前のプロジェクトで納品物にExcelシートにコードを全て張り付けるという
謎の納品物がありました。
ホラーですね・・・。

Excelに貼り付けですか…。まぁそれは大変でしたね…。
万が一そのようなプロジェクトに当たった場合には気をつけます…。


>実装者によって混在していなければどちらでも問題ないと思っています。
>言語でのタブ、空白インデントの相違による問題点については
>経験したことは無いです。

まぁそうですよね。通常問題は発生しませんよね。
ありがとうございました。

>2スペース幅が好きなので、4スペースインデントのソースとか見ると違和感があります。

そうですか。私は逆ですね。
2スペースだとネストを認識しにくく、見にくく感じでいらいらします。
この辺はやっぱり宗教なんですよね。

ありがとうございました

同意見です。2スペースのタブはネスト構造が見にくくて嫌いですね。

すみません、幅が2か4のどちらが優れているという意図ではありませんでした。
タブでインデントされていれば、エディタの設定で2でも4でも好きなタブ幅で表示できるのでタブがいいですよね、という話でした。
スペースでインデントされていると表示が変更できないので。

リンクの内容をまとめていきますね。

「コーディングルールの統計」は無理やり「タブ派」と「スペース派」の2グループだけに分離するとそうなるのでしょうが、「スペース派」には主に「2個派」と「4個派」と「独自ルール派」に分かれます。しかしさらに少数派として3個派・6個派・8個派もあります。「インデントが多いと80桁からはみ出る」という理由で2個派・4個派の立場をとっている人から見たら、「6個派・8個派」の人はタブ派と同様に敵でしょう。また2個派と4個派もお互い敵同士だと思います。ので、スペース派内の派閥も区別すべきだと思いますけどね。


「タブによる字下げの問題点」の根拠は
・エディタの表示幅が8文字でそこから変更することが出来ない環境を使っている場合
・ドットインパクトプリンタを使用している場合
限定の話ということですかね。

私はSakuraエディタやDreamweaver , Eclipceを中心に、MKEditor, 秀丸などを使ったことがありますが、そのすべてでタブの表示幅を自由に変更できました。またドットインパクトプリンタについては30年位前に博物館でさわったことと、汎用機の実習で使ったことしかありませんし、私の仕事の方向としてはおそらく汎用機を扱うことはもうないと思います。

そのような人間には、タブのデメリットは特に無いという話なのでしょうかね。


「グーグル社内は2文字インデント」を書いた人のの根拠がよくわかりませんが、少なくとも「GoogleのJavaScriptスタイルガイド」では「インデント＝半角空白2文字」と決まっているわけではありません。2文字とすべき場合と、4文字とすべき場合と、カッコの位置にあわせてもいいという内容です。Googleは「スペース2個派」ではなく、「スペースだけど個数は独自ルール派」です

GoogleのJavaScriptスタイルガイド
http://google-styleguide.googlecode.com/svn/trunk/javascriptguide.xml?showone=Code_formatting#Code_formatting

「インデントをスペースにするメリット」では

No.1-4
「インデント」を「ネスト1つ分」という論理的意味合いで使用するのではなく
位置そろえで使用してしまうと崩れるという説ですね。

それはそうですが、
・インデントに限定してタブを使用する
・位置そろえを目的としている場合にはタブを使用しない
というルールにすれば問題ないということだと思います。


No.5
# スペースを利用している多くの人間は、「メリットがあるから」使っているわけではない
# 「タブでもスペースでも、実用上、まったく違いがないから」使っている
# 統合開発環境が…デフォルトで半角スペースが設定されているものも多い
# 自分ではまったく気がつかずに半角スペースをインデントに使っている、という人は多い気がする

統合開発環境のいくつかでは、タブと同様に使えるし、デフォルトでスペースを使うように設定されているし、スペースを使うことにデメリットは特に無いから、特に何も考えていない人は自然とスペースになるということですか。


# yamlでは、タブによるインデントは認識されない。またPythonでは、
# タブはすべて「半角スペース８文字」と認識して動くため、
# 下手にタブを混在させるとインデントが崩れ、シンタックス自体がおかしくなることが多々ある。

一方でYAMLやPythonを使う場合には問題がおきることがあるから気をつけろということですね。私はどちらもまだ使ったことはありませんが、もし使う際には気をつけようと思います。


No.6
# ホストのCRT端末でTSSのエディタを使っていた頃、タブは
# ハードウェアタブ(HT)しかなく、タブ幅は8キャラクタ(だったと思う)
# 固定でした。で、端末のエディタの画面は72桁しか表示しませんから
# タブに8桁を設定すると、あっという間に右端に達してしまいます

# パンチカードや紙テープではインデントは必然的にスペースでした

# 初期のPC用エディタも同様にタブ幅固定でしたから、


「インデントをスペースにするメリット」のNo.6さんの回答と「タブによる字下げの問題点」の根拠をあわせると
・ホストのCRT端末でTSSのエディタを使っていた頃
・パンチカードや紙テープを使っていた頃
・初期のPC用エディタ
・ドットインパクトプリンタを使っていた頃

など、基本的には20-30年前のことだが、今でもホストやパンチカードや紙テープやドットインパクトプリンタや初期のPC用エディタなどを使っている人は、タブは使うべきではないということなのですね。

ざっくりまとめると、
・昔はタブは問題があった
・今でもYAMLやPythonでは、タブは問題がおきることがあるから気をつけろ
ということですかね。

ありがとうございました。

あとここについて、もう少し教えてください。
>みる人の環境に左右されないようにするためです。
これは具体的にどういうことですか？よく言われる「80桁など定められた幅を超えてしまう」という話でしょうか。それともそれ以外のデメリットがあるのでしょうか？

> >みる人の環境に左右されないようにするためです。
> これは具体的にどういうことですか？

tag の表示幅が 8 に固定 (cat , less での表示だと indent が作者の設定したタブ幅にあわせられないことがあります。

ここについて、もう少し教えてください。
>作成者が意図した表示が出来ない。
これは具体的にどういうことですか？よく言われる「80桁など定められた幅を超えてしまう」という話でしょうか。それともそれ以外のデメリットがあるのでしょうか？

「インデント」を「ネスト1つ分」という論理的意味合いで使用している限り問題は起きないと思っているのですが。ネストと無関係に位置そろえ目的でタブを使用した場合の話でしょうかね。

ま、そうなんですよね。
どちらでもさほど差はないんですよね。
ありがとうございました

プロポーショナルフォントでのコーディングですか…。やったことがなく、想像もできないのですが。むしろどんなきっかけで始めたのか気になります。

それから、「昔は diff, patch コマンドでタブを扱えなかった」のですか。あくまでも昔の話なのかもしれませんが、だとしても昔は使えなかったのですね。

ありがとうございました

> 引数が多いときにインデントしますよね？

少なくとも私はこのようなスタイルには絶対にしません。私の「インデント」という言葉は、「ネスト1階層を意味する」という論理的な意味を持っていることが絶対的な条件です。位置そろえや装飾が目的のスペースの連続は、少なくとも私はインデントとは呼びません。

そのケースのような位置そろえも加味しなければならないのなら、「1行80桁と定められたドキュメントで中央そろえに見えるようにスペースを入れたが、100桁で表示したら中央揃えではなくなった」という例まで考慮しなければならなくなると思います、がどうでしょう。


そのケースでわたしが「インデント」を行うならこうなります。
これが私の考える「インデント」です。

extra_args_func(
'arguments1',
'arguments2',
'arguments3'
);

論理的な意味合いをどのように表示するかなので、論理的な意味を持たせている限り表示が崩れることは無いはずです。

※上記の例の、各引数の行頭にはタブが入っていると思ってください。

私がどう思うかは別にして、「スペース派」の人は、論理的な意味合い以外で、つまり位置そろえ目的で「インデント」を使用したいから、タブは都合が悪いということなのですかね。

Googleのコーディング規約もそう書いてありました。ただ私には、関数名の長さによって「インデント」の長さが変わるというのが、どうも納得しがたいのですが、そこはまさに宗教・宗派の違いなのかもしれませんね。

ありがとうございました

> コード中のコメント(PHPDocのようなもの)が見づらくなることがあります。

それは実際にはどのように書くと、どのように見づらくなるのでしょうか。
出来れば具体的に教えていただきたいです。
よろしくお願いします。

ここだとうまく表現できないのですが・・・
下のようにコメントがあったとして、
コメントの@param, string, 変数名, 説明の間がタブで区切られていたとします。
このときタブの表示幅を8にエディタで設定していたとしても
下のプロジェクトのタブの表示幅が4だった場合、整形されたphpDocは
崩れて見づらくなります。
/**
* @param string $abcdefg text text text text text text text text
* @param int $db text text text text text text text text
* text text text text text text text text
*/
複数のOSSにコミットしたりしていると、
プロジェクトによってタブ表示幅が違うという場面に遭遇することがあります。

>コメントの@param, string, 変数名, 説明の間がタブで区切られていたとします。

タブを行中で使用している場合の話ですね…。で、その話は「@param, string, 変数名, 説明の間」が「半角スペース8文字」で区切られていてもおかしいですよね。つまり、タブか半角スペースかの問題ではないですよね。もしかして半角スペース8文字の場合はおかしくならないのでしょうか？

結論としてインデントにタブを使う分には何も問題はないというご意見なのですかね。
ありがとうございました

>タブを行中で使用している場合の話ですね…。で、その話は「@param, string, 変数名, 説明の間」が「半角スペース8文字」で区切られていてもおかしいですよね。
半角スペース8文字では区切りません。どこに半角スペース8文字で区切ると問題がないと書いてありますか？

タブ(半角4文字表示)で記述した場合を書いてみます。Tはタブ、Sはスペースを意味します。
/**
S*S@paramTstringT$abcdefgTtextStextStextStextStext
S*S@paramTintTT$dbTTTtextStextStextStextStext
S*STTTTTTTTtextStextStextStextStext
S*/
これだと説明文はどの行でも33文字目から始まります。

しかし、タブの表示幅が8になっていた場合、説明文は1行目が41文字目から、2行目が57行目から、3行目が65文字目から始まることになります。

一方スペースを使っていた場合は下記のようになり、エディタ設定を変えるという手間がありません。
/**
S*S@paramSstringS$abcdefgStextStextStextStextStext
S*S@paramSintSSSS$dbSSSSSStextStextStextStextStext
S*SSSSSSSSSSSSSSSSSSSSSSSStextStextStextStextStext
S*/

『「タブの表示幅が8になっていた場合」に表示が崩れる』というご意見ならば「しかし、タブ1文字を半角スペース8文字に置き換えたときには起きない」事を最低限の条件としていただきたいです。そうでなければ「タブと半角スペース」の比較になりませんから。


S*S@paramTstringT$abcdefgTtextStextStextStextStext
の「タブ1文字」を「半角スペース8文字」に置き換えたら

S*S@paramSSSSSSSSstringSSSSSSSS$abcdefgSSSSSSSStextStextStextStextStext
となりますよね。

S*S@paramSstringS$abcdefgStextStextStextStextStext
とはどう考えてもならないと思いますけど。


そして基本的にはインデントつまり「ネスト時に行頭に非表示文字を挿入し字下げ」の話を対象にしていて、行中の装飾や位置そろえ目的の話はしていないつもりです。


>半角スペース8文字では区切りません。

ということなら、そもそも普通はタブでも区切らないと思いますけどね。

>ソースが見やすくなるくらいで、

「くらい」ではなく「ソースが見やすくなる」というのならそれは大きなメリットだと思います。

どうだと見にくくて、どうだと見やすいのでしょうか？
そこが重要なので、できれば具体的に教えていただきたいです。

よろしくお願いします。

すみません結論がよく分かりませんでした…。
冒頭の「迷っている」が結論なのかもしれませんが。

しかし老眼の進行によりスペース4つから2つにという話は初めて聞いたので参考になりました。同一人物でもスペース4個がよかったり2個がよかったり変化するということは、「これが見やすいはずだろ」と固定のスペース数を押し付けることはエゴであり、よくないことなのかなと思いました。

ありがとうございました


>お客様に、「見にくかったらタブの設定を変えて下さい」なんて言えない
のは分かりますが、インデント幅は人により好みが違うのに、固定してしまったら

>お客様に、「スペース2個が見にくくても文句を言わず我慢してください」なんて言えない
も言えると思います。まだ調節できるほうが親切だと思うんですけどね…。どうでしょう？


あと後半は
> 位置決めに使うなと言っても、本来の目的が位置決めから始まっているので、伝わりにくいかも

ということは「行中のタブは許可すべき」ということなのでしょうか？それはまた別の話になりますが、「タブ文字を一切使用しないと決めると」の話とは完全に矛盾しますね…。また、ルールを1つ削除するために「ざわわざ」ルールを1つ追加するのは合理的ではないと思いますよ。

言葉足らずで申し訳ございません。

>すみません結論がよく分かりませんでした
現在の私自身の結論は、ケースバイケースで使い分けなければならいないというのが結論です。
デバッガによってはソースにタブ文字があるとブレークポイントがずれる程度ならまだしも、腹痛を起こすものもあります。
また、安易にインデントとして使用するわけにはいかない、タブ文字が空白と異なり別の意味をもつ言語・スクリプトもあります。
最近ではあまり見かけないですが、FORTRANの固定フォーマットやパンチカード時代由来の言語のソース形式などはタブ文字は元々使用できないですね。

>まだ調節できるほうが親切だと思うんですけどね…。どうでしょう？
いまだに多い、タブは8文字で(ひどいときは一行80文字まで)というデフォルトの設定のまま(エディタだけではない)、その調節機能が活かされないのが問題なんです。

>> 位置決めに使うなと言っても、本来の目的が位置決めから始まっているので、伝わりにくいかも
> ということは「行中のタブは許可すべき」ということなのでしょうか？

いいえ。タブはインデントのみに使用すべきと言っても、本来の目的が位置決めから始まっているので、miu_ras さんの主意が伝わりにくいと言うことです。

>「タブ文字を一切使用しないと決めると」の話とは完全に矛盾しますね…。

後半へのつながりは、タブの使用を拡大解釈して、行中にタブを使用してずれると嘆く人が少なからず出てきてトラブルを起こし、それならば、シビアな仕事のときは多少は不便だけれど「タブ文字を一切使用しないと決める」とこのような問題は生じないという、私の「事なかれ主義」からくるものです。

Java, C, C++ などメジャー? な言語に限って、追加のコメントをします。

「インデントにタブを使うデメリット」というテーマですが、
このフォーラムの階層トップであるeclipse でJavaを使用する場合は、強力なフォーマッターがあるので、バサッとコーディング規約に準じたソースに変えることができます。　また、eclipseほど強力ではないけれど、C++のコーディングのとき私がよく使うIDEである、QtCreatorなどでも、オートフォーマットできます。
Visual Studioは最新のものでも、この手はかなり遅れています。脱線ですが、リファクタリングツールが貧弱なのが特に困るw。

つまり、eclipseなどのよく使われる環境では、インデントにタブ文字を使おうが空白n文字使おうが、一気に変更できてしまうので、「インデントにタブを使うデメリット」は、ほとんどない(フォーマッターを使用する手間を厭わなければまったくない)と言っても過言ではないでしょう。

インデントに限らず、いくらコーディング規約を作っても、それをチェックするのが目視というのは、クオリティが低いと言わざるを得ません。それは、コンパイルチェックしていないソースコードのような品質です。プログラマならコンパイルが通っていないソースがいかに信用がないかわかると思います。フォーマッターがあるのなら積極的に利用すべきだと思います。

コーディング規約の重要な要素である、コメントに関してもJavadocやDoxygenを使えばコンパイルチェックがかかるのである程度の品質は保たれると思います。

「なるほど！」ってなりました？そのページは、私にとってはイマイチ何が言いたいのかつかめない文章なのですが…。

おそらくは、インデントにタブとスペースのどちらがいいかという話とは全く関係が無く、混在を許すか許さないかの話をしているのではないでしょうか。

私にとっては混在を許すか許さないかは議論の余地無く、はじめから「混在は許さない」「どちらかに統一すべき」という選択肢しかありえないので…。出来れば混在禁止は前提条件として考えていただきたいです。

もし、そういう話では無く、そのページの作者は全く違う事をいっているという場合には補足で、何を言っているのか噛み砕いて教えてください。よろしくお願いします。

>読む側の環境によって、タブインデントだと著しく可読性が悪くなる場合がある

一応確認なのですが、あなたのおっしゃる「著しく可読性が悪くなる場合」とは具体的にどういうことですか？1インデント＝スペース8文字でも起きる問題ですか？それとも1インデント＝スペース8文字では起きないけれど1インデント＝1タブだけで起きる問題ですか？

インデントを8文字とする人はあまり見たことはありませんが、2文字や4文字では見にくいと感じる人だから8文字で設定しているのですよね。そのような人なら1インデントが2文字スペースのコードなんて見せられたらそれこそ「著しく可読性が悪い」と感じるはずではないかと思いますけど。

あと、出てないごく軽微なデメリットとしては、コマンドラインで、catしたような場合に、(普通は)端末エミューレーターが8文字タブと見なすので、横に広がってビックリするという程度。Unix/Linuxだと、expandコマンドがあるし、VT100上位互換の端末エミュレーターならタブ位置の変更も出来ますが。