Q&A
画像は自作でしょうか。そうであれば、不愉快ですので取り除いて下さい。自作でないのでしたら、出所を明示して下さい (明示できないのなら、当然取り除いて下さい)。
インデントにタブを使うことのデメリットはありますか？
タブを使うことのメリット・半角空白を使うことのデメリットとしては
・半角空白を複数で1インデントとすることにより、少ない文字数で表現でき、ファイルサイズが小さくなる
・1インデントが正しく構成されているか一目でわかる
→例えば半角空白4つで1インデントとするルールで、3インデントのはずの個所で半角空白11個とか13個で書かれているケースをしばしば見かけるが、ぱっと見ただけでは正しいインデントなのか判別しにくい
・タブならエディタの設定で、自分の見やすい表示幅に調節できる(ことが多い。エディタによるが)
・インデント中をカーソルで移動する際やインデントを削除する際に、少ないキー押下回数で済み楽に操作できる
・エディタの表示設定で、半角空白・全角空白・タブを表示するようにしたときに、半角空白でインデントをしているとうっとうしい
→「半角空白・タブの混在」や「全角空白の混入」を避けるために、非表示文字も見分けがつく設定にしておくべきだと思う
・半角空白でインデントを表現する場合、2個派と4個派とその他派で対立が起こる
が挙げられ、一言で言えばタブを使うことは、メリットが多くデメリットは無く、合理的だと思っています。
ところが、以前先輩と話したときに「タブは制御文字だから問題が起きることがある」というようなことをいわれたことがあります。そのときに明確に確認できず、またもう話す機会が無いので確かめられません。
それが正しいかどうかは別とし…
(1)インデントにタブを使うことにデメリットはあるか
(2)インデントに半角空白を使うことにメリットはあるか
(3)現実問題として問題が発生することはあるか。あるなら具体的に。
についてご意見ください。
プラットフォーム特有・言語特有の場合には、その旨を明記していただきたいです。
よろしくお願いします。
※ここで言う**「インデント」とは、「ネストの階層構造を表現するために行頭に非表示文字を挿入し字下げすること」**とします。行中の位置揃えや装飾を「インデント」と呼ぶ人もいるようなのですが、本質問では無関係とさせてください。
※また、スペース派の方は「タブ幅が8文字になっていたとき」を引き合いに出す人がなぜか多いのですが、本質問は「文字数の比較」では無く「タブとスペースの比較」です。ので、「タブ幅が8文字になっていたとき」を引き合いに出すのならば「タブ幅が8文字になっていたときは問題が起きるが、タブ1文字を半角8文字に置き換えたら問題は起きない」ことを前提条件として考えていただきたいです。
※プロジェクトの方針等でルールが定められていた場合に、ルールに従うのは当たり前の話です。ので、そのようなケースはここでは考えません。単独のプロジェクト等で、方針を決める際の選定理由などと考えていただければいいと思います
※一応、最近私が扱う言語は、PHP, Java, JavaScript, HTML, CSS、開発対象はWebシステム, Webサイト, Androidアプリ, Chrome拡張です。一応このあたりをターゲットとしていただきたいですが、上記以外でも「この言語ではタブではエラーになる」 等の情報がありましたら教えていただきたいです。
※インデントにタブとスペースを混在させることは、少なくとも私にとってはありえないことで、必ずどちらかに統一すべきだと思います。なので基本的には議論の対象から外したいのですが、「混在も許すべき」「場合によっては役に立つ・必要」「混在も選択肢に入れるべき」などというご意見をお持ちの方は、そのお考えを教えていただきたいです。
この議論でよくつかわれる画像を添付しておきます。
回答33件
0
こんにちは。
私はタブ派ですが、プロジェクト内でどちらを使うかルール化されており、
実装者によって混在していなければどちらでも問題ないと思っています。
さて、私が経験したデメリットですが、
以前のプロジェクトで納品物にExcelシートにコードを全て張り付けるという
謎の納品物がありました。
その納品物ではExcelシートのA列に全てのコードを張り付ける必要があったので
タブインデントされている場合にB列、C列とネストされていってしまうという
デメリットはありました。
そういった成果物は稀かもしれませんが、もし存在するのであれば
空白タブを選定する理由にはなり得ます。
言語でのタブ、空白インデントの相違による問題点については
経験したことは無いです。
投稿2015/05/27 00:07
総合スコア4791
> 以前のプロジェクトで納品物にExcelシートにコードを全て張り付けるという
謎の納品物がありました。
ホラーですね・・・。
Excelに貼り付けですか…。まぁそれは大変でしたね…。
万が一そのようなプロジェクトに当たった場合には気をつけます…。
>実装者によって混在していなければどちらでも問題ないと思っています。
>言語でのタブ、空白インデントの相違による問題点については
>経験したことは無いです。
まぁそうですよね。通常問題は発生しませんよね。
ありがとうございました。
それは、別次元の問題では・・・
0
私は スペース で インデント します。
みる人の環境に左右されないようにするためです。
参考情報
-
コードのインデントはタブ？スペース？ クォートはシングル？ダブル？ 人気のあるコーディングルールの統計 http://coliss.com/articles/build-websites/operation/work/popular-coding-convention-on-github.html
-
タブによる字下げの問題点 https://www.grapecity.com/tools/support/powernews/column/clang/041/page01.htm
-
インデントをスペースにするメリット http://ziddy.japan.zdnet.com/qa5069205.html
-
グーグル社内は2文字インデント http://omake.accense.com/wiki/GoogleTwoSpaceIndent
投稿2015/05/26 21:39
総合スコア22328
リンクの内容をまとめていきますね。
「コーディングルールの統計」は無理やり「タブ派」と「スペース派」の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 が作者の設定したタブ幅にあわせられないことがあります。
0
タブなら表示幅を好きなように変更できるのでタブの方が好きです。ただ最近は非主流ですよねぇ。
2スペース幅が好きなので、4スペースインデントのソースとか見ると違和感があります。
タブでインデントされていればうれしいんですけどね。
投稿2015/05/26 22:59
総合スコア759
>2スペース幅が好きなので、4スペースインデントのソースとか見ると違和感があります。
そうですか。私は逆ですね。
2スペースだとネストを認識しにくく、見にくく感じでいらいらします。
この辺はやっぱり宗教なんですよね。
ありがとうございました
同意見です。2スペースのタブはネスト構造が見にくくて嫌いですね。
すみません、幅が2か4のどちらが優れているという意図ではありませんでした。
タブでインデントされていれば、エディタの設定で2でも4でも好きなタブ幅で表示できるのでタブがいいですよね、という話でした。
スペースでインデントされていると表示が変更できないので。
0
良いエディタと、EditorConfigによる適切な設定、適切なフォーマッター、適切なリンター、適切な表示設定をしていればどっちでも何も問題ないと思っています(タブに制限や非推奨の理由がある一部の言語を除く)。
・半角空白を複数で1インデントとすることにより、少ない文字数で表現でき、ファイルサイズが小さくなる
ソースコードのファイルサイズが小さくなることにメリットはほとんどありません。コメントを入れない方がファイルサイズが小さくなって良いなんて誰も言わないのと同じです。
また、HTML、CSS、JavaScriptは最終的に圧縮(minify)するのが普通なので、インデントに何を使っていようがファイルサイズは一緒です。
・1インデントが正しく構成されているか一目でわかる
→例えば半角空白4つで1インデントとするルールで、3インデントのはずの個所で半角空白11個とか13個で書かれているケースをしばしば見かけるが、ぱっと見ただけでは正しいインデントなのか判別しにくい
良いエディタを使っていれば、インデントラインが表示できます。スペースだろうがタブだろうがインデントのずれはすぐにわかります。
・タブならエディタの設定で、自分の見やすい表示幅に調節できる(ことが多い。エディタによるが)
タブだからこそ幅を指定しないと、想定幅をこえてしまい、見難くなります。むしろタブの場合は、EditorConfigでタブの幅を指定すべきです。結局EditorConfigで指定すれば何も問題ありません。
また、自分の好みのインデント幅で無ければ、好みになるようにフォーマッターを使えば良いだけです。
・インデント中をカーソルで移動する際やインデントを削除する際に、少ないキー押下回数で済み楽に操作できる
まともなエディタはインデント幅を一回で移動したり削除したりできるようになっています。スペースもタブも関係ありません。
・エディタの表示設定で、半角空白・全角空白・タブを表示するようにしたときに、半角空白でインデントをしているとうっとうしい
→「半角空白・タブの混在」や「全角空白の混入」を避けるために、非表示文字も見分けがつく設定にしておくべきだと思う
そもそもうっとうしい表示にしかできないようなエディタが悪いです。表示が控えめであるか、自分で調整できるのが良いエディタです。なお「全角空白」が表示できないようなエディタは使う価値がありません。
・半角空白でインデントを表現する場合、2個派と4個派とその他派で対立が起こる
タブでも2幅派、4幅派、8幅派の対立が起きます。ただ、何幅派の人が作ろうが、フォーマッターでフォーマットすれば良いだけなので、みんな仲良く過ごせるはずです。
ということで、どっちもどっちだと思います。
そもそも言語によってインデントが2幅、4幅、8幅のどれが良いのかは異なると考えています。2幅だとわかりにくい言語もあれば、8幅だときつい言語もあります。ただ、スペースであろうがタブであろうが、適切な設定とフォーマッターやリンターがあれば、言語毎の切り替えもできるので、何も問題は無いと思います。
【最近の悩み】
C++は8幅のタブでインデントしているですが、public:とprivate:とかをどうインデントすべきか悩んでいます。今はスペース4文字にしているのですが、スペースとタブが混ざってすごい違和感が…。
C++
1class A { 2 int num; // タブ1文字8幅(ここではスペースで表現しています) 3 public: // スペース4文字 4 int GetNum(); // タブ1文字8幅(ここではスペースで表現しています) 5};
「混在させるのは論外」とのことなので、私のような人の回答はそもそも論外になるかと思います。
投稿2016/12/13 22:31
総合スコア21784
>自分の好みのインデント幅で無ければ、好みになるようにフォーマッターを使えば良いだけ
チームで開発しているときに「半角空白4個を1インデントとする」と定められたとします。しかしAさんは2個が好きと。この時Aさんが編集するときに2文字にフォーマットして、コミットする際に4個にフォーマットしなおしてコミットすればいい、ということですよね？編集時とコミット時で、2個の設定・4個の設定を変更したうえで、フォーマットをかけなおさなければならないので、手間が発生しそれはデメリットだと思いますけどね。
>スペースとタブが混ざってすごい違和感が…。
・気付かずに混在させてしまった
・チームで開発の際に、コーディングルールを定めないあるいは守らないために混在が発生
というのはよくありますが、わかっていてあえてやる人もいるのですね…意外でした。
・良いエディタ・まともなエディタを使う
・minifyする
をすれば、半角空白のデメリットはなくなるということですね。
私はEclipseやSakuraEditorを使うのですが、どちらも「インデント幅を一回で移動したり削除したり」「インデントラインを表示」する機能は、おそらくないと思います。少なくとも左右キーでは1文字ずつの移動になりますし、DELを1回押すと半角空白1文字の削除になります。どちらもあなたの定義の「良いエディタ」でも「まともなエディタ」でもないということですかね…。何か同時押ししたらジャンプしたり、インデント単位での削除になるのでしょうかね。
もしよろしければ「良いエディタ」「まともなエディタ」の例を教えてください。
> フォーマットをかけなおさなければならない
タブであっても、タブ幅を変えるのであれば、インデント後に入る文字数が変わるため、1行の幅に収まるようにフォーマットし直しは避けられないと考えています。どっちにしても同じでは無いかと思っていますが、私はめんどくさがり屋なので、郷には入れば郷に従えでわざわざ変えようとは思いません。
> EclipseやSakuraEditor
Eclipseは設定やプラグインでできるようになるかも知れませんが、私は知りません。NetBeans派なので(と言っても、NetBeansではJavaしか触らないし、いつもタブ文字なのでどうなのかまではわかりませんが)。多くの人は行をインデントする逆インデントする、行頭に移動するなどのショートカットを使っているので、気にしている人はいないという可能性もあります。
SakuraEditorは**ただの**テキストエディタとしては優秀ですが、プログラミング用のテキストエディタとしてみるとあまりよくはありません。本格的なプログラミングを行うには機能が貧弱ですし、拡張性もそれほどありません。
> 「良いエディタ」「まともなエディタ」の例
少なくともEditorConfigに対応できないようなエディタは私はプログラミングに使いません。
横槍失礼します。
一点だけ、気になったところがありましたので。
> タブでも2幅派、4幅派、8幅派の対立が起きます
起きないんじゃないですか？
それこそまともなエディタなら自分の好みの幅になっているでしょう？
>tomcat0090さん
問題は一行の最大の文字数との兼ね合いです。半角文字換算で80文字または120文字を最大とし、改行を入れるというスタイルを採用した場合、インデントに使われているタブが2幅、4幅、8幅によって、どこで改行すべきかが変わってきます。タブインデント2幅で最大80文字のコードに対して、俺の好みは8幅だからといって8幅にすると80文字の制限を超えた行が多く現れ、コードが見難くなる場合があります。
コードを他人と共有する場合、タブ幅も強制するか、自分が好みのタブ幅にしてからフォーマッターで整形しないと行けないと言うことです。だから、タブだろうがスペースだろうが、結局同じと言うことです。
> raccy さん
> 問題は一行の最大の文字数との兼ね合いです。（後略）
なるほど、その点についてはそうですね。
初めてタブが可変表示であることに由来する問題点にあたった気がします。ありがとうございます。
0
タブインデントの最大のデメリットとしては、正しく使えるユーザ数が極端に少ないということでしょうか。
miu_ras 様が、予め断っているにも関わらずインデントと位置合わせを混同する意見などが散見されますし、同じく論点のずれた意見が「タブスペース論争」の検索結果でも同じような記事はたくさん見かけます。
つまり正しく理解して、それを使える人間がごくわずかしかいない。
→ 正しく使えないのであれば、スペースの個数を指定するというごく単純なルールだけによる運用のほうがスムーズである。
というのが世間の流れではないでしょうか。
しかしながら、この後ろ向きな風潮は、エンジニアとしては残念でたまりません。
かつてXPを使っている人がいるからという理由で、レガシーブラウザ対応し続けてきたWEB業界のような、とても後ろ向きな標準化であると感じてしまいます。
せめてタブ派の方々だけでも、インデントと位置合わせの違いぐらいはきちんと理解して、スペース派に余計なツッコミを入れられる状態をなくしていけたらもう少し市民権を得られるのでは？と思います。
投稿2016/09/06 06:56
総合スコア66
つまり「インデント」という言葉自体を理解していない・できないもしくは、「インデントにはタブを使いましょう。ただしインデント以外には使わないでください」といっても文の意味が理解できない人がかなりの数いて、その影響が大きいということですね…。
「正規表現禁止」とか「条件演算子禁止」などと同じようなものなのかもしれませんね。
かなり本質をとらえていると感じました。ありがとうございました
0
並び順が回答の都合上悪いのであべこべに回答しますよ。
あと、全部のレスをさっと読んで、感覚的な話だなと思ったので感覚的なことを書きます。
私はタブインデントが大嫌いですからその理由を感情的に書きます。
コメント上の貴方はかなり情熱的な感じなんで、その方がなんか貴方と話し合える気がしたからです。
#(3)現実問題として問題が発生することはあるか。あるなら具体的に。
この話はインデントそのものとは関係ないことに注意してください。
まず、単純にタブ文字そのものに困ったことが私はあります。
成熟していない米国の開発環境のエディタが2バイト文字に対応しておらず、日本語の右にタブを入れるとインデントがズレてしまうというのに遭遇したことがあります。
これには困りました。
ShowDialog( "確認", // タイトル "CSVを出力します。"); // 本文
これ、自分にとっては「タブの本質的な問題」そのものなんですよ。
エディタが悪いっていうかもしれないけど。
複数人で作業するだけでなく、エディタも含めて読み手側に制御をゆだねるような作りが私は好きじゃありません。
タブ文字っていうのは、マジックナンバーと同じで、正当な扱いを書手と読者両方に求めてる奴です。
プログラミングを初めて1年の間は好んでタブ文字を使っていました。しかし、私個人はこの経験を経てタブ文字そのものがノイズであるという認識に変わりました。
#(1)インデントにタブを使うことにデメリットはあるか
まずタブ文字が「画一的でない。状態が固定されていない。」というデメリットを持っています。
「読者が好きに幅を設定できる」はメリットではありません。
タブ文字を使うことによる、動作上のデメリットは今となってはほとんどありません。
エディタから見ればタブも空白もただの文字です。
しかも、タブ文字の利用が貴方の内容なら相当限定されている。
この限定条件下でインデントそのものがタブかどうかははっきり言ってほとんどの読者には関係ありません。
貴方のやり方なら人間の目から見て即座にタブとスペースの互換に問題も起きないでしょう。
しかし。ですよ。
だからこそタブでインデントしたらデメリットがあるかと言われれば、私は「ある」とはっきり言いましょう。
なんでそこまできっちりこだわったのに、インデントが「可変長」なのかがまったく理解できません。
可変長インデントじゃなくて、固定長インデントでソースコードは共有してほしいんですよ。
プログラマーはどうしたら読みやすいかについて頭をひねってコーディングします。
重要なのはインデント幅から受ける書き手としての感覚的な影響です。
タブ文字で整形をしてしまうと、「組んだ誰かにとって最適であったような状態」が読む環境でブレてしまいます。これはね、「2/4/8文字タブスペースの問題」とかじゃまったくないんです。
「こいつは…タブ幅2文字だったのか？4文字だったのか？」この悩み自体がナンセンスです。
2幅で書いたソースは2幅で最初から見えているべきなんですよ。
タブは言わば、ソースコードの共有時に紛れ込む唯一の脆弱性です。
受け手によって見た目が変わるなんて存在そのものが不合理です。
タブ文化っていうのは、それ全てが言わば書き手と読み手の蜜結合です。
これが私には、酷く醜いものに見えます。
#(2)インデントに半角空白を使うことにメリットはあるか
私たちは皆物書きです。最高の見た目でコーディングします。
そこで「タブ幅の自由」みたいな話題を読者側の私に振るなと。
むしろ自由なんだ。好きに設定してくれ。必要であればインデント幅なんていくらでも改変してコードは読む。
だから、書き手のお前が2幅が良いと思ったなら2幅で見えるようなものを提出しろと。
最初の一歩として、私は貴方が書いた時に見ていたものをそのまま見たいわけです。
少なくとも、空白埋めにはそういうブレの入り込む隙がありません。
#終わりに
といっても、まあ実のところタブ文字で提出されて困ることはほとんどないはずです。
貴方ぐらい神経質に拘って書いてるなら特に問題は起きないはずです。
それが読みやすいかどうかは、ソース見なきゃわかんないもん、文句のつけようもありません。
確かなのは、タブってのは曖昧ってことです。
むしろ貴方ぐらいちゃっかりかっちりを求めているのに、なんでタブはOKなんだって疑問で私はいっぱいです。
投稿2016/12/14 09:38
総合スコア1593
>私たちは皆物書きです。最高の見た目でコーディングします。
>そこで「タブ幅の自由」みたいな話題を読者側の私に振るなと。
この表現にすべてが集約されているような気がしました。
見ている方向が違うのかなと。
ラーメン屋の頑固おやじと、好きなように食べたい客の関係のようなものかなと思いました。
「俺のラーメンは最高なんだ。スープを飲む前にコショウを振りかけるような奴は食わなくていい、今すぐ出ていけ」
「コショウをかけるのは習慣なんだよ。俺は客なんだ、好きなように食わせろ」
みたいな。
あるいは「細麺・太麺、油多目・少な目、味濃い目・薄目」が選べる店との違いか。
>むしろ貴方ぐらいちゃっかりかっちりを求めているのに、
>なんでタブはOKなんだって疑問で私はいっぱいです。
私の場合は選べる店の方が好きですし、もしラーメン屋をやるなら選べる店にします。自分にとっての「最高」が、すべての人にとっても最高だとは限らないと思っているから、でしょうかね。
何かわかった気がします。
ありがとうございました
なんとなくレス返してなかったけど付け加えておきましょう。
いつまでもなんか話題がホットなので。
私はタブが使われてなくても太麺、細麺とか油多め、少な目は自由に変更できます。
タブ文字は僕からするとラーメンのメニューに「たぶん普通麺（4文字幅）。」と書かれてる気分です。
しかも食べ始めてから「あれ、これ細麺（2文字幅）の方が美味しいじゃん」と気づいた時が最悪。
自分の環境じゃタブ幅が４文字固定なんです。でも多分相手は２文字幅だった。この場合、大体のエディタがタブ幅なんて全体で一つしか設定できないので、ファイル全体をフォーマットしなおします。これによって結局タブ文字などなかったことになるし、インデントとかその他の細かいものも全てなくなります。
結果、ラーメンは台無し。
0
タブのデメリット
・Githubで8文字に表示されるので見るに堪えない
投稿2016/12/08 13:14
退会済みユーザー
総合スコア0
Githubでは「?ts=4」を付ければ、タブ幅の表示を自由に変更できることをご存知ですか？
半角空白8文字でインデントをしているコードも「見るに堪えない」はずだと思うので、そうだとするとタブか半角空白かは関係なく、タブのデメリットの話ではなく、インデントに8文字分とることのデメリットの話ですかね。
あるいは、表示幅を変更する方法が分からない人がいる、もしくは設定を変更するのが面倒だということですかね…。
ありがとうございました
勿論知ってますがその作業を見る人全員に毎回やれというのは建設的ではないですね。
今日び8文字インデントなんて見かけませんし、固定幅のGithubでは横幅が突き抜けます。
まぁ言いたいことは、自分だけなら何でもいいけど、最近は外部サービスを使うことも多くなったので自分のエディタだけではなくそういうのも考慮する必要があるということです。
> 今日び8文字インデントなんて見かけません
まじかよ。おれのgithubのC/C++のコードは全部8文字インデントなんだが、少数派だったのかよ。Linuxカーネルコーディング規約に乗っ取ったつもりだったが、もう時代遅れだったのか…。ちょっとショックです。
web、アプリ系が話の対象らしいですけど..
ここの質問の一番最初のバージョン時にちゃんと読んだきりだったので、Web系限定になったのに気付きませんでした。やけにPythonの話が出ていたし、他の人の回答も普通に色んな言語の話をしていたものでしたので。
>Web系限定になったのに気付きませんでした。
一応の目安として「Webシステム, Androidアプリなど」と書きました。しかし話を限定する制約ではありません。ただの目安です。そのあとの文で書いてあるようにそれ以外でも構いません。当然、C/C++でも構いませんし、Pythonでも汎用機でもドットインパクトプリンタでも構いません。
ただし、
・タブと半角空白を混在させる
・コーディング規約を守らない
・そもそもコーディング規約を定めない
・インデント(行頭)以外にタブを使う
なんて話は論外と考えていただきたいです。
0
自分の経験ではタブのインデントで問題が起きたことはありません。
デメリットとしては、その「自分の好みの幅に出来る」というメリットがそのままデメリットにもなると思います。
つまり、作成者が意図した表示が出来ない。
投稿2015/05/26 21:46
総合スコア1293
ここについて、もう少し教えてください。
>作成者が意図した表示が出来ない。
これは具体的にどういうことですか？よく言われる「80桁など定められた幅を超えてしまう」という話でしょうか。それともそれ以外のデメリットがあるのでしょうか？
「インデント」を「ネスト1つ分」という論理的意味合いで使用している限り問題は起きないと思っているのですが。ネストと無関係に位置そろえ目的でタブを使用した場合の話でしょうかね。
0
自分は「よく使われる画像」の中の叩かれる人です...
ただ, 実際のところ自分としては「インデント」にはタブしか使っていないのです.
ですが「視覚上の位置合わせ」にスペースを使う人間なため,
「インデント」に限らなければ「タブスペース混在」なので叩かれる, という構図です.
参加する場合はそのプロジェクトに合わせますが, プライベートでは ([TAB]=タブ文字, _=半角空白):
C
1//※あくまで説明のためのコードですのであんまり良いコードではないですが. 2[TAB]///_コメント 3[TAB]///_a___引数a 4[TAB]///_bb__引数bb 5[TAB]///_ccc_引数ccc 6[TAB]int_func1(int_a,_int_*bb,_int_ccc)_{ 7[TAB][TAB]func2(a, 8[TAB][TAB]______bb,____//※1 9[TAB][TAB]______ccc);__//※1 10[TAB][TAB] 11[TAB][TAB]if_(a_<_0_||_ccc_<=_a)_return_-1; 12[TAB][TAB]else___________________return_func3(bb[a]); 13[TAB]}
インデントと位置合わせはこのように完全に別物として区別したいのです.
ただこれ, サポートしてくれるエディタがほとんどないのが苦しいところ...
※1なんてインデント調整の操作したらどっちか片方に統一されてしまったりしますし.
投稿2019/05/31 03:59
総合スコア354
まさかの混在派ですか…。
このタイプの整形を好む人はだいたいスペース派なのですけどね。
ありがとうございました
…ところでfunc2の名前を変えたときには、どうするんですかね？呼び出し箇所すべての空白を調節しなおすんですか？あるいはリファクタリングは禁止ですかね？
調節し直します...が, 実際のところ, この整形が使えるのが
個人でのプログラミングだけなので何とかなっちゃうだけ, という感じですね.
共同で編集するソースではどちらかに統一になってしまいますし,
もし採用できたとしても「複数行に渡る呼び出しでは第1引数から改行」とかが落とし所でしょうか.
混在とは言っても, 例外なく「タブ=ブロックレベル」「スペース=見た目上の調整」であるので,
エディタのタブ幅がどれだけ変わっても, ブロック間の崩れはありませんし,
見た目上の調整はスペースで統一されているため, 固定幅フォントなら引数の位置合わせもズレません.
0
私はタブ派です。
Windows上でC/C++のコーディングを10年以上やっていますが、
タブインデントで困った経験はありません。
miu_rasさんがおっしゃるようにメリットが多く、デメリットは無いと思います。
環境依存で可読性が下がると指摘されている方もいらっしゃいますが、
一緒に開発に携わるスタッフの中で、そのような極端な開発環境を採用している
プログラマに遭遇した経験もありません。
逆にスペースインデントで困った経験があります。
昔、引き継いだソースがスペースインデントだった時にインデントがずれていたり、
スペース２文字・４文字が混在していて読みづらく困った経験はあります。
当時はArtistic Styleというコード整形ツールを使って問題を解消していました。
どちらも、綺麗に整形されていれば、可読性に違いは無いと思います。
その場合、ファイルサイズが小さくなるタブインデントを私は選びます。
投稿2015/06/13 07:00
総合スコア57
0
わたしはスペースインデント派ですが
タブを使わないのは以下のような理由です。
- 表示がずれる
extra_args_func('arguments1' ,'arguments2' ,'arguments3');
引数が多いときにインデントしますよね？
タブでインデントするときれいに揃えられなかったり、
タブ幅によってずれたりします。
- 1タブ=8スペース前提になっていることがある
Unixでは伝統的に1タブは8スペースでインデントされるようです。
コマンドの出力に出てくるタブも8スペースでインデントされることを
前提としているものが多くあります。
vimとかで開発していると、そういうcuiとの絡みが無視できないため
タブを8スペースに設定したくなります。
(IDEとかだとぜんぜん関係ありませんが)
- めんどくさい
表示がずれるのは「タブ幅が環境によって違う」せいです。
最初からスペースインデントにしていれば
各々の環境なんて考えなくてすみます。
投稿2015/06/02 07:27
総合スコア68
> 引数が多いときにインデントしますよね？
少なくとも私はこのようなスタイルには絶対にしません。私の「インデント」という言葉は、「ネスト1階層を意味する」という論理的な意味を持っていることが絶対的な条件です。位置そろえや装飾が目的のスペースの連続は、少なくとも私はインデントとは呼びません。
そのケースのような位置そろえも加味しなければならないのなら、「1行80桁と定められたドキュメントで中央そろえに見えるようにスペースを入れたが、100桁で表示したら中央揃えではなくなった」という例まで考慮しなければならなくなると思います、がどうでしょう。
そのケースでわたしが「インデント」を行うならこうなります。
これが私の考える「インデント」です。
extra_args_func(
'arguments1',
'arguments2',
'arguments3'
);
論理的な意味合いをどのように表示するかなので、論理的な意味を持たせている限り表示が崩れることは無いはずです。
※上記の例の、各引数の行頭にはタブが入っていると思ってください。
私がどう思うかは別にして、「スペース派」の人は、論理的な意味合い以外で、つまり位置そろえ目的で「インデント」を使用したいから、タブは都合が悪いということなのですかね。
Googleのコーディング規約もそう書いてありました。ただ私には、関数名の長さによって「インデント」の長さが変わるというのが、どうも納得しがたいのですが、そこはまさに宗教・宗派の違いなのかもしれませんね。
ありがとうございました
私も、関数名の長さによってインデントを変えるのは、違和感があります。
通常インデントで十分分かりやすいし、最初の与え値だけ別扱いで「(」の直後に残す意味も分かりません。
論理構造的には、行を変えるのであれば全て行を変えるべきですし、インデントも関数によってインデント幅が異なるなんてことはせずに統一すべきだと思います。
これはおっしゃる通り構造に一貫性を持たせるか、見た目に一貫性を持たせるかの宗教のようなものかもしれませんが。
0
こんにちは。
盛り上がっているようなので、ちょっとだけ意見を述べさせて下さい。
(1)インデントにタブを使うことにデメリットはあるか
(2)インデントに半角空白を使うことにメリットはあるか
(3)現実問題として問題が発生することはあるか。あるなら具体的に。
(1)と(2)は「下記２つの条件を満たす場合にある」です。
- そのソースを見る人の間でタブ幅を固定する合意が取れない
- ソースを見やすくなるよう工夫する際、行中の桁揃えも採用している
1.は、オープンソース・プロジェクトは常に該当します。
2.も、成立することはそこそこあると思います。
私自身は、ソースを視覚的にもすっきり見えるよう工夫したい人なので、行中の桁揃えを気にしてコーディングすることが少なくないです。（インデントの深さが異なる行の間でも桁揃えします。）
そのようなソースを公開することがあるので、タブ・コードは使いません。
折角頑張った桁揃えが、見る人のエディタの設定により崩れるのは悲しいですから。
行中の桁揃えをするようなソースを書かない場合は、タブ・コードを使っても問題はでないと思いますが、桁揃えすると見やすくなる時に桁揃えしていないソースって不親切だなとは感じます。ま、絶対嫌と言うほどの拒否感はないです。
(3)のタブ・コードを使った場合の問題は、「桁揃えしたソースを公開すると恥ずかしい」、もしくは、「桁揃えしないちょっと見づらめのソースしか公開できない」ですね。
そして、オープンソースの世界ではスペース派の方がかなり多いようです。
投稿2016/12/14 10:57
総合スコア23274
0
ほかの回答をざっと読みましたが、質問者さんは「インデントにはタブを使うもので、スペースではインデントができない」という信条をお持ちのようにも見えます。もしもそうだとしたら、実際はそんなことはないです。
適当なCのソースコード (内容はでたらめ) を、GNU indentで処理してみると、結果は次のようになります。
C
1void 2func (void) 3{ 4 while (i) 5 if ((((i < 2 && k > 0) 6________ || p == 0) 7________ && q == 1) || n = 0) 8 { 9________i--; 10 } 11} 12
なお、結果をわかりやすくするため-l30オプションを与えています (ほかのオプションはないです)。また、結果に現れるタブ文字を「________」で表しています。
ここで注目してほしいのは、
- 制御構造よりも微細な構文のレベルに応じて、1文字単位の字下げを行う流儀もある (
||や&&に注目)。 - 基本的なインデント幅が8文字でなくても、字下げの手段として一定幅 (ここでは8文字) を表すのにタブを使う流儀がある。
という点です。なお、これは比較的歴史のあるindentというツールの初期設定 (行長を除く) を使った結果ですから、このような流儀が、一般的でない特定の環境を前提としているとは考えにくいです。
ちなみに、「スペースを使うとスペースの幅の整数倍がタブと同じにならないことがあるから、インデントにスペースを使わない」あるいは「タブとスペースを混在させない」といった主張をされるかたがあるのでしたら、ちゃんと幅が同じに表示できる環境で作業することをお勧めします。
個人的には、かつて長い間、言語を問わず「4文字単位のインデントをするが、8文字分を表すのにはタブを使う」という習慣を持っていました。
しかしあるとき、複数人で共同でプログラミング (お金をもらう仕事以外で) した際に、「4文字単位のインデントをするが、タブ幅を4文字に設定しているのでタブでインデントしている」という人や「タブは一切使わないがインデントは4文字単位 (タブの表示幅は8)」という人、しまいには「インラインコメント (行末につく一行コメント) もタブでそろえる」という人などがいて、収拾がつかなくなりました (一つのソースを「一人目の人」、「私」、「二人目の人」の順で編集したらどんな悲惨な結果になったかは、ご想像にお任せします)。
結果どうしたかというと、次のように決めました。
- 幅の解釈に相違が生じるタブ文字の使用は推奨しない。
- コミットの際のインデント幅や改行ルールは各自の自由。
- ただし、リリース前にソース整形ツールで形式を統一する。その結果にはみんな文句を言わない。
ともかく、個人的には現在、タブを使わないほうに宗旨替えしています (インデント幅は4のまま)。理由のひとつは上のように、タブ幅が人によって一定しないことに懲りたからです。
もうひとつの理由は、当ページでもすでに実例があるように、入力時にタブ文字が無視される事例が増えている (ように思う) からです。これは、タブキーがしばしばアプリケーションのウィジェット間の移動に用いられるため、それとの干渉を避けるためではないかと考えています。
投稿2016/12/11 09:10
編集2016/12/11 09:45総合スコア4441
> 質問者さんは「インデントにはタブを使うもので、スペースでは
> インデントができない」という信条をお持ちのようにも見えます
それは勘違いです。もしそんなことを思っているのであれば、初めから選択肢はタブしかないはずで、メリットデメリットを考えることなどありえませんので。
宗教かもしれませんが、同一ソース内で1インデントが何文字分でもいいことにするなんてルールは私にとってはありえないことなんですけどね。そういうスタイルが好きな人もいるのですね…。「1インデントが何文字分でもいいことにする」というルールを採用する場合に限っては、半角空白を選択すべきですね。
ありがとうございました
「1インデントが何文字分でもいいことにする」なんて、書いてないと思いますが。どの点のことを言っていますか。
すみません確認させてください。
「制御構造よりも微細な構文のレベルに応じて、1文字単位の字下げを行う流儀」で、
1インデント半角空白4文字で「GNU indentで処理」した場合にはどうなるのですか？
行頭から最初の表意文字が現れるまでの間の半角空白の個数は
(1)「必ず4の倍数になる」のですか？
それとも、(2)「5や6や7になることがある」のですか？
(1)と(2)のどちらですか？
indentはソースの内容を変えずに整形するだけなので、上の例を使ってオプションを変えて実行すればいいです。ご自分でいろいろ試してみてください。
あなたの展開している話の内容を確認しているだけです。その確認のためだけにわざわざ実際に試すつもりもありません。
(1)と(2)のどちらかだけを答えていただければ結構です。
(1)と(2)のどちらですか？
0
インデントにタブの使用することに関しては致命的な欠点はないという点は同意です。プログラムを書く場合は Xcode のように折り返しも含めてエディタが面倒を見てくれるのが理想ですよね。
今さらですが、ここでも他所でもあまり触れられていないスペースのデメリットがあるので述べたいと思います。
おそらくスペース派の方は、コードを編集するときに使用するフォントは固定ピッチであることが前提条件になっていると思いますが、すべての方が固定ピッチフォントを使用しているとは限りません。少なくとも私はそうです。
固定ピッチフォントでは、スペースの幅は所謂全角の 1/2 か、欧文専用のフォントだとそれより大きいくらいですね。なので、2スペースや4スペースがちょうどいいという話をよく聞くわけです。
しかしながら普通の欧文フォントではスペース幅は所謂全角の 1/4～1/3 程度の幅です。この時点で「環境に左右されないようにする」という意図は意味をなしていません。行中の位置揃えは言うまでもなく、行頭のインデントに関しても環境によって表示は変わってきます。
以上のような理由から、エディタで幅を変えられるタブを使うほうが親切だと思います。
追伸）昔は diff, patch コマンドでタブを扱えないからスペースにすべきという意見もありましたね。
投稿2016/03/16 03:02
総合スコア12
プロポーショナルフォントでのコーディングですか…。やったことがなく、想像もできないのですが。むしろどんなきっかけで始めたのか気になります。
それから、「昔は diff, patch コマンドでタブを扱えなかった」のですか。あくまでも昔の話なのかもしれませんが、だとしても昔は使えなかったのですね。
ありがとうございました
0
タブは制御文字として使われるものなので、
見栄えのためのインデントにはスペースを使うほうがいいと思ってスペース(2個)を使っています。
(タブにしたときのプログラムとしての問題には遭遇したことがないです。)
タブでインデントをしたときに起きる面倒なこととしては、
プロジェクトによって想定している表示タブ幅が違うことです。
コード中のコメント(PHPDocのようなもの)が見づらくなることがあります。
些細な問題ではありますが。
投稿2015/06/14 12:23
総合スコア18
> コード中のコメント(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文字では区切りません。
ということなら、そもそも普通はタブでも区切らないと思いますけどね。
0
行中の位置揃えや装飾を「インデント」と呼ぶ人もいるようなのですが、本質問では無関係とさせてください。
「インデント」の直後で「前の行の文法要素に合わせた位置揃え」を行う場合、すべてタブで行おうとしても、揃えるべき桁がタブだと中途半端な位置になって、目的の位置に入れられないということが発生します。この状況でタブとスペースの混在を許さないとすれば、インデントもスペースに揃えるしか手段がありません（さすがに、行頭から連続するスペースに対して「インデント分だけタブにして、残りはスペースで」というような打ち分けは難しいでしょうし、エディタで自動判定するのも困難だと思います）。
AirbnbによるRubyのスタイリングにも、途中の位置揃えをするスタイリングが入っていますが、全体のインデントは2スペースとなっています。
ruby
1module SomeModule 2 # 奇数桁なので、スペースで位置揃えするしかない 3 def self.some_method(phrase_id, 4 phrase_key, 5 target_locale, 6 value, 7 user_id, 8 do_xss_check, 9 allow_verification) 10 ... 11 end 12end
投稿2018/07/04 03:27
編集2018/08/09 01:21
総合スコア146706
使う言語の文法が許容すれば、そのようなことをしたい場合は常に
hoge(
a,
b,
...
のような書き方にすることを受け入れる、という選択肢はありそうです。
このような書き方をする場合、some_methodの名前が変わったときにはどうするんですか？some_methodの呼び出し箇所すべてのスペースを調整しなおすんですかね。あるいはリファクタリング禁止でしょうか？
そもそもこれは「インデント」なのでしょうか？もしもインデントだとするならば、そのケースでは1もしくは2インデント23スペースですよね。そして全体として1インデントのスペースの数は決まっていない、ということになります。そのようなカオスなコードにはしない方がいいように思えるのですが…。しかしそれを好む人もいるのですね。
ありがとうございました
> そもそもこれは「インデント」なのでしょうか？
「桁あわせ」部分が、テーマとしている「インデント」と別件であるのは間違いないですが、タブインデントだと「インデントであるタブの直後に、桁合わせのためのスペースという混在した入力を迫られる」という不都合のある例です（うまく打ち分けられる環境があるのであれば、もしかしたら問題ないのかもしれません）。
0
タブを使うのと何カラムごとにインデントするかはまた別ですね。
私は古いので、スペースタブ混在です。12カラムインデントならタブ1文字とスペース4文字。これはエディタがそういうふうに勝手にしてくれます(行の頭から8の倍数カラムはタブにして残りはスペース)。
GUI時代以降はタブが何カラムにあたるか想定できない時代になったので、
・複数人でソースを見る
・タブ設定の統一化を強制できない
という状況だとスペースのみを使ってインデントしないと共同作業に困ると思います。
タブを使った方がソースプログラムが短くなるのは、今どき利点とは言えないでしょうね。
投稿2018/04/12 07:40
総合スコア702
0
インデントにはTABを、インデント以外の桁揃えにはスペースを使うデメリットですが、それをすべての人が守れるようにするのが難しいというのがあります。
例えば、エディタにもよりますが、TABキーを押したらTAB幅に合わせた桁揃えをし、
そのときに使う文字としてスペースを使うかTABを使うかが設定できるようになっている事が多いです。
その場合、インデントをTABでするにはTABキーでTAB文字を入力する設定にする必要があり、
桁揃えにTABキーをついつい使ってしまうとインデントじゃない場所にTAB文字が入ってしまいます。
なので、特に多人数が関わるときは、インデントとインデント以外の桁揃えでTABとスペースを
適切に使い分けるよりも、スペースだけを使う方がずっと楽になります。OSSでスペース派が多いのは
この理由が大きいと思っています。
なお、 Go は標準で賢いコードフォーマッタ (gofmt) を用意することでこの問題を解決して、
TABインデントを標準にしています。
Go を使っていて TAB インデントが辛くなるのは、ブラウザ上でコードを書く
（こう言うフォームとか gmail とか）ときにTABキーが普通に使える事が少ないことくらいです。
そんなときばかりは、Goを書くときでもスペースでインデントしてしまいます。
（コピペされても、その人がちゃんと gofmt かければ解消されますしね）
投稿2017/02/02 23:38
総合スコア28
タブインデントでもスペースインデントでも私はどちらも難しくはないのですが
人によって難しいと感じる人もいるのでしょうね。
リテラシーの問題ということですかね。
「なんでこの人はルールを守れないんだろう」という人は良くいますからね。
ただ、レベルの低い人がいるからスペースにするでもいいですけど、
そういう人は他のコーディングルールも破りまくりなんだと思いますけどね。
ありがとうございました
0
古い記事ですが……。
自分はスペース派からタブ派に変わった口ですね。
結局、タブでのデメリットは「見た目」だけだったんです。
テキストエディタの融通が利かない、投入するサービスの融通が利かないなど。
しかし使ってみるとTABの方が自由度は高く、見た目も自在に変えられる。
例えばスペースである方が都合がいい時は、TABをGREPすればすぐにスペースに置き換えられます。
しかし、スペースで書いてしまうとTABに変更するのは行頭から2文字ずつという置き換えが必要になり
、負荷も時間も掛かりますしミスの可能性も増大します。
そもそもスペースはインデント以外でも多様しますが、TABをインデント以外で使うことは皆無ですもんね。
メガ単位のファイルなら大したことないんですけど、ギガ単位を超え始めることが多くなりスペースの容量がバカバカしくなりました。
Googleほど潤沢なスペックやリソースがあればいいんですけど（笑）
投稿2017/01/22 03:44
総合スコア28
>TABをインデント以外で使うことは皆無ですもんね。
「タブを正しく使う人」はそうだと思います。しかし、タブを空白文字の一種として自由に使いまくって痛い目に遭ってタブ否定派になったという人が少なくないように思いました。
またタブ否定派の人はインデントという言葉がそもそも通じない人が少なくないようです。もちろん、インデントを理解している否定派の人もいるのですが。
タイトルの先頭からインデントと書いているし、『「インデント」とは、「ネストの階層構造を表現するために行頭に非表示文字を挿入し字下げすること」』『行中の位置揃えや装飾を「インデント」と呼ぶ人もいるようなのですが、本質問では無関係』とわざわざ太字で注意書きしているのに、あえて行中の桁そろえの話を持ち出す人が少なからずいて驚きました。
tomcat0090さんが「タブインデントの最大のデメリットとしては、正しく使えるユーザ数が極端に少ない」とコメントれていたのですが、これはかなり大きいように感じました。
コメント遅くなりすみませんでした。
ありがとうございました
今さらなコメントにご返信ありがとうございます。
全部を読んだわけではなかったので気づきませんでしたが、『tomcat0090さんが「タブインデントの最大のデメリットとしては、正しく使えるユーザ数が極端に少ない」とコメントれていたのですが、これはかなり大きいように感じました』というお話しに非常に納得します。
なるほどですね。
論理的な構造のみに視点をおくならインデントに何を使おうが本来は等価なんですよね。
ユーザ毎の「視覚」に頼った位置揃えや装飾をするなら確かにスペース以外にはあり得ませんが、そもそもそのような視覚に頼る行為自体に一貫性が乏しいとも言えます。おっしゃる通り「正しく使えるユーザ数が極端に少ない」というのが、状況を最も適切に表現していそうです。
まあ、以下は愚痴みたいなもんですけど。
ガチガチな開発環境に依存しているなら、そもそも何もせずに開発環境に任せる方が良いぐらいなものですが、綺麗に位置揃えしている人も多いですね。値が変わるたびに揃え直しているし、こちらも揃え直さないとダメな気分になるんでやめて欲しいんですけど……。VisualStudioな人に多くて、同じく面倒だと思っている人も居るのか位置揃えNGなレギュを見たことがあるぐらい（笑）
0
ソースが見やすくなるくらいで、エラーの原因になったことがないので、
その会社の規約に合わせるのが良いですね。
投稿2015/06/22 06:45
総合スコア1021
>ソースが見やすくなるくらいで、
「くらい」ではなく「ソースが見やすくなる」というのならそれは大きなメリットだと思います。
どうだと見にくくて、どうだと見やすいのでしょうか？
そこが重要なので、できれば具体的に教えていただきたいです。
よろしくお願いします。
0
スペース派ですが、この記事は、なるほど！と思ったのでちょっと参考までに。
ちなみに私はここであげられているような例ではまったことはありません。
投稿2015/06/05 01:09
総合スコア1901
「なるほど！」ってなりました？そのページは、私にとってはイマイチ何が言いたいのかつかめない文章なのですが…。
おそらくは、インデントにタブとスペースのどちらがいいかという話とは全く関係が無く、混在を許すか許さないかの話をしているのではないでしょうか。
私にとっては混在を許すか許さないかは議論の余地無く、はじめから「混在は許さない」「どちらかに統一すべき」という選択肢しかありえないので…。出来れば混在禁止は前提条件として考えていただきたいです。
もし、そういう話では無く、そのページの作者は全く違う事をいっているという場合には補足で、何を言っているのか噛み砕いて教えてください。よろしくお願いします。
0
間違って投稿してしまったのですが、意見のまとめ用として使います。
■タブを使った場合に発生するデメリット
・Excelにコードを張り付けることを要求された場合に手間取る
・ドットインパクトプリンタでずれて印刷される場合がある
・ホストのCRT端末や初期のPC用エディタや、cat, less, vimなどだと、タブを使うとすぐに右端に達する
→タブは8文字固定で画面幅は72桁しか表示できないため
■スペースを使うメリット
・パンチカードや紙テープではタブは使えないのでスペースを使わざるを得ない
□表示が崩れる説 (ただし、本質問の対象とはしない)
・行中や位置そろえ・装飾にタブを使うと作成者の意図と表示がずれる
→**「インデント」とは、「ネストの階層構造を表現するために行頭に非表示文字を挿入し字下げすること」と私は考えています。インデント以外にタブを使うことを許すかどうかはまた別の問題だと思います。世の中にはそういう対立問題もあるのかもしれませんが、本質問では「 インデントにタブを使うことのデメリット」**だけを対象にさせていただきます。
・2文字で表示されることを前提としてコードを書いて、見た人が8文字で表示すると80桁を超えやすくなる
→「タブとスペースの比較」では無く「2文字と8文字の比較」をしており本質問の意図と異なります。文字数対決は別の機会に行っていただきたいです
※タブ否定派の方から**「行中の位置そろえや装飾にタブを使った場合に、別の人が観た際に作成者の意図とずれる」**という意見を何度かいただきました。タブ肯定派の私から見てもそれに関しては正しいと思います。「行中の位置そろえや装飾にタブを使う」ことは避けるべきだと思います。
ですが、行中に使うべきではないという話と、**「ネストの階層構造を表現するために行頭に非表示文字を挿入し字下げすること」**は区別して考えるべきだと思います。
■その他
・YAMLではタブは使えない
・Pythonでは、タブを使っても特に問題はない。ただし、半角空白と混在状態になると正常に動作しなくなる
投稿2015/05/27 08:32
編集2016/04/01 13:38総合スコア902
あと、出てないごく軽微なデメリットとしては、コマンドラインで、catしたような場合に、(普通は)端末エミューレーターが8文字タブと見なすので、横に広がってビックリするという程度。Unix/Linuxだと、expandコマンドがあるし、VT100上位互換の端末エミュレーターならタブ位置の変更も出来ますが。
0
読む側の環境によって、タブインデントだと著しく可読性が悪くなる場合があるので、半角英数字2文字インデントがベターかと思います。
例えば、読み手がvimでタブのインデント幅を8文字にしていると、8文字分字下げされ、次の行にコードをまたがって読みづらいということがあります。
投稿2015/05/27 08:00
総合スコア1161
>読む側の環境によって、タブインデントだと著しく可読性が悪くなる場合がある
一応確認なのですが、あなたのおっしゃる「著しく可読性が悪くなる場合」とは具体的にどういうことですか？1インデント＝スペース8文字でも起きる問題ですか？それとも1インデント＝スペース8文字では起きないけれど1インデント＝1タブだけで起きる問題ですか？
インデントを8文字とする人はあまり見たことはありませんが、2文字や4文字では見にくいと感じる人だから8文字で設定しているのですよね。そのような人なら1インデントが2文字スペースのコードなんて見せられたらそれこそ「著しく可読性が悪い」と感じるはずではないかと思いますけど。
0
スペース2つがベストだと思っています。
タブやスペース4文字だとgithubやエディタで見たときに行末が見えないので。
と、これは自分場合ですが、最終的にはタブでもスペースでもどっちでもいいとは思います。
人に優しく、チームに優しく、システムにも優しいなら。
ただ、最近のエディタはデフォルトでタブを打つとスペースになりますね。
世の中的にはそうゆう方向性になっているんじゃないでしょうか。
投稿2019/05/29 16:29
総合スコア548
0
- インデントを表現する文字コードとしてタブを使う
- インデント1段を表現するためにタブキーを打つ/ファイルにタブ文字を入れる。つまりインデント一段はタブストップ1つ分のカラムにひとしい
という二段階の話がありますね。
私はタブは8カラムに決まってるだろ派ですので、結構タブをインデントも使います(12カラムにインデントするならタブ1つ＋半角スペース4つ=viでインデント機能を使った時の挙動)。
結局タブでインデントすること自体に支障はないが、他人に渡したり共同作業するときには支障が生じる。特にタブ幅のカスタマイズが異なる人相手だと困る。ということでしょう。
teratailにキーボードからタブを打って入れられない(僕が知らないだけで実はできる？）という不便もあります。
なお、紙テープにはタブコードは入れられます。
投稿2018/08/10 02:21
総合スコア702
0
圧倒的に生産性良いのはタブですが説得が一番の問題です。
インデントなんだからタブが普通だし、スペースで凝り固まりすぎです。
非効率極まります。
スペースでの問題点
・ファイルのサイズが大きいことで重く大規模プロジェクトで調査とかをするとGrepに時間が
・スペース入力の手間が大きい
・SQLをログ出力していると圧縮できずそのままのスペースでるからログ肥大化して調査も手間
・よくずれる
・html圧縮する必要あり
・圧縮した場合ブラウザ上での解析が必要なシーンで厄介なので基本的にはそのまま使った方が良い。外部に公開するときは難読性を高めるため圧縮した方が良い。
タブでの問題点
・すでに広まってしまったスペースを標準とすることが多く、凝り固まった人達を説得しづらい
・エクセルに貼るときにsakuraでスペース置換必要
・iphoneで打てない
タブと混在させたいケース
↓これ
select
Aaaa
,Bbbb
From
のようなときに一行目を混在させるほうが綺麗です。
投稿2018/04/12 03:47
総合スコア20
0
デメリットはケースバイケースでしょう。
共同作業者がタブインデントを日常的に使っているところにわざわざ半角スペースインデントを使うメリットはないですし、使っているまたは使う予定のエディタのデフォルト設定がタブキーにタブが割り当てられている場合は、半角スペースに設定し直す煩わしさはデメリットになります、逆も然りです。設定変更可能でデフォルトの値が何かという意味に一度頭を巡らせてみるといいです。エディタの作者がそれが必須だという考えならそれがデフォルトから外れているはずがありませんよ。
デメリットはケースバイケースです。
投稿2017/07/21 19:49
総合スコア14
エディタで設定する煩わしさを取り除きたいのであればEditorConfigをお勧めします。
「ケースバイケース」というのは、全世界的に共通認識があると思います。それは前提にして考えていただきたかったです。
どちらか一方が「メリットしかない、デメリットは一切ない」、あるいは「メリットが一切ない、デメリットしかない」なんて考える人は極めて稀だと思います。
「ケースバイケース」は当たり前として、よくあるケース・回答者さまが経験したケースなどについて回答していただけるとありがたいです。
0
最近はソフト屋さんが以前の様なITリテラシーの高い人だけではなくなりつつあり、タブとスペースの違いが分からない人、気にしない人などがいます。それくらいプログラミングの敷居が低くなっています。
それに従いスペース派が多くなってきています。以前はスペースとタブが区別できるようにエディターを設定にしてましたが、混在しているのが気になるので、タブとスペースの区別がつかない設定を使用するようになりました。
1人で開発する分には当然タブで困る事はないですが、今はBoth派です。プログラミングは各人の効率を上げる事が重要だと思うので、各人が快適にコーディングするのが良いです。
コーディングする前に自分が好きな形式に整形するフォーマッターを適用して、コミック前には組織のルールに整形するフォーマッターで戻すのが良いかと思います。
投稿2017/02/05 04:38
総合スコア648
0
Linuxの設定ファイルの話はお呼びでなかったらすみません。
（質問では「一応このあたりをターゲットとしていただきたいですが、上記以外でも「この言語ではタブではエラーになる」 等の情報がありましたら教えていただきたいです。」とのことなので、テキストエディタで扱う対象の一つということでお許しください…)
(3)現実問題として問題が発生することはあるか。
についてです。
例えば、Raspberry PiのRaspbian、の/boot/config.txtですが、Githubにある説明では、
N.B. When editing this file, please preserve the indentation levels to make it
simple to parse programmatically. NO HARD TABS.
って書いてありまして、ハードタブ入れるんじゃないよ！って書いてあります。
ソフトタブだけしかインデントには使えません。
ブート時に読み込むファイルなので、余裕がなくてそういう制約がきついのかもしれません。
投稿2017/02/02 03:06
総合スコア155
「Raspberry PiのRaspbian」における「/boot/config.txt」1ファイルは、
タブ文字を許可していないという事ですね。なるほど。ありがとうございました。
一応確認なのですが、そもそも「/boot/config.txt」というファイルは、
「Raspberry PiのRaspbian」に限定した話なんでしょうか？
もしくはLinux全般に共通する話なんでしょうか？
あるいは、Linuxではタブ文字を許可しないファイルが他にもあるということなのでしょうか？
すみません、知らないなりに調べてみましたが、Raspbian以外ではインデントはタブ文字ダメなのかよくわからなかったです。
「Linuxの設定ファイル」ではなく「Raspbianの設定ファイル」と限定するべきでした。」
さも他にもイロイロあるかもと言うような書き方をしてしまいすみません。
0
Eclipseだとコードフォーマッタがあるので、プロジェクト参画時に適用してもらってタブ・半角スペース・タブ幅の統一はしますね。
あとは保管時アクションも、チーム内で揃えますね。
タブでインデントする際には特に目立ったデメリットはないでしょう。
あえてデメリットとするならば、タブ文字を画面に表示する際に半角スペースで自動変換するサービスでは、表示する際には何らかの文字幅を設定しないと表示が崩れるくらいかと。
別件ですが、CSVを扱う際には区切り文字をタブにするシステムもありますので、タブ文字をコードに入れるのを嫌がる人は一度だけ遭遇したことがあります。
投稿2016/12/14 05:48
総合スコア12011
TSVの話は…プログラミングとは本当は関係ないですよね。それがだめならCSVを扱う際は、プログラム中にカンマを入れてはいけないことになりますよね…。ちょっとあり得ないような気がしますが。
ありがとうございました
0
私はJavaScript(AltJS)は2スペース、PHPはタブ派でやっている特殊な例（というほどでもないか？）です。
エディターで使いやすいか否かが質問文のメリットにあるので
スペース派もエディターの設定等で対策出来る範囲は対策出来るという視点で質問文に対してちょっと気になるところに触れてみます。
- 1インデントが正しく構成されているか一目でわかる
→スペースだからといって増えたり減ったりする輩はタブでも1文字だけスペースが紛れ込んでるとかで同じ事やらかすのでノーコメントで…
→PythonやCoffeeScriptなどの言語は2スペースで安定運用します - エディタの表示設定で、半角空白・全角空白・タブを表示するようにしたときに、半角空白でインデントをしているとうっとうしい
→スペースインデント派は半角スペースのみ非表示にします。それでなれるとタブがうるさく感じます。 - 半角空白を複数で1インデントとすることにより、少ない文字数で表現でき、ファイルサイズが小さくなる
→基本的にはその通りですが、タブも\tと2文字文消費するので常にファイルサイズが小さい訳ではありません。 - インデント中をカーソルで移動する際やインデントを削除する際に、少ないキー押下回数で済み楽に操作できる
→エディターの設定次第で、ソフトインデントのファイルに対してタブと同じような操作が出来ます。
残った2つがでかいですね、
おっしゃる通りスペースは後から気軽に増やしたり減らしたりが難しいですからね。
Tabならば喧嘩が起きないですね。
・タブならエディタの設定で、自分の見やすい表示幅に調節できる(ことが多い。エディタによるが)
・半角空白でインデントを表現する場合、2個派と4個派とその他派で対立が起こる
他回答では挙げられてない点として、
エディターに於いてはTab≒インデントに使われる文字という認識が一般的ですが、
何らかの機能として実装されているケースがあり、Tabインデントが使えないケースが挙げられます。
（辞書登録したり、コピペで対応すれば入力することは可能ですが…）
- WebサイトのテキストエリアでTabキーを押すと、次のフォーム部品にフォーカスが移る
- Bash等でCat文を作ってる最中Tabがパスの補完として機能する
Bash
1$ cat << EOS > hoge.txt 2> [Tab] // カレントディレクトリのファイルの補完になる
投稿2016/12/13 15:23
総合スコア21484
>スペースだからといって増えたり減ったりする輩は
>タブでも1文字だけスペースが紛れ込んでるとかで同じ事やらかすので
なるほど。確かに…。
>スペースインデント派は半角スペースのみ非表示にします。
なるほど。許す文字は表示させず、許さない文字を強調させて表示するのですね。そういう機能のあるエディタに限定されますが、それはいい運用ですね。今後参考にさせていただきたいルールです。
>タブも\tと2文字文消費する
これは…正規表現や文字列リテラルとして表現する場合の話ですかね
>エディターの設定次第で、ソフトインデントの
>ファイルに対してタブと同じような操作が出来ます。
私はEclipseとSakuraEditorをよく使います。この2つでは、左右キーでは半角空白1文字ずつの移動だし、DELキーでは半角空白1文字の削除になります。私が知らないだけで、何か同時押ししたら一気に移動・削除できるのですかね。
>何らかの機能として実装されているケースがあり、
>Tabインデントが使えないケースが挙げられます。
>（辞書登録したり、コピペで対応すれば入力することは可能ですが…）
そうですね。Web上のエディタでタブを入力したいときなどは使いにくいですね。
Bash補完機能もそうですね。
ありがとうございました
>タブも\tと2文字文消費する
これは嘘です、大変失礼しました。
実際にtab5文字とスペース10文字のテキストファイルを生成して確認しましたが、
tabは6バイトでスペースは11バイトになりました。
> 私はEclipseとSakuraEditorをよく使います。
私が使用したことのあるSublime、Atom、Vimでは設定次第では行の先頭でBackSpaceを押すと2文字分のスペースインデントが削除されます(例：インデントを2spaceとして設定時)
スペースで運用しているプロジェクトの場合、そのプロジェクトは上記のようなエディターを強制しても良いかもしれませんね。
とりあえず、多くのエディターはShift+Tabで逆インデントされるので、BackSpaceで逆インデントを使用しないように後輩に指導しています。
0
私は半角スペース派です。
言語は主に C/C++。
タブキーによるインデントのデメリット...
Eclipse や VC++ で開発されている方はあまりデメリットを感じないかと思いますが、
メモ帳や TeraPad というようなテキストエディタ+ コンパイラ で開発している者としては
"扱いにくい"。
たとえば、VC++でDLL ( Javaだと メインメソッドがない jar ファイルといったところか。 ) を作成し、
MinGW ( javaだと javac にあたる。 ) で実行ファイルを作成した場合、
DLLのソースコードをテキストエディタで見ると、インデントがバラバラになっていたりする。
たとえば、
VC++ では
C++
1int a,b; 2for( int i = 0; i < 20; i++ ){ 3 a = i; 4 b = a*2; 5}
となっているはずなのに、テキストエディタでみると、
C++
1int a,b; 2for( int i = 0; i < 20; i++ ){ 3 a = i; // ここがずれているように見える 4 b = a*2; 5}
という感じになっていたり...
あと、
タブキーを 視覚的に見るために _ に置き換えると
__a = 0;_// コメント!
となっているとして、
a = 0; の 0 の部分を書き換えたとします。( それとも // のところだったか? )
すると、若干ずれているように感じます。
( テキストエディタで編集した場合。 )
なので 半角スペースがいいかなぁと。
投稿2016/11/08 09:26
総合スコア4962
>インデントがバラバラになっていたりする
それはタブと空白を混在させた場合に発生する問題ですよね。
タブだけを使った場合には発生しないはずだと思いますが。
タブか空白かの前に、混在は絶対に許すべきではないと思います。
>__a = 0;_// コメント!
>となっているとして、
それは行中の位置ぞろえの話ですよね。
質問文にも書いていますが、タブをそのような用途で使用するのも論外だと思います。
ありがとうございました
0
私は、正直迷っています。
個人的にはタブを使用したいのですが、やむなく空白を使用するときは2文字派です。
最近老眼が進み、文字を大きく表示して作業しますのでインデントは2文字で十分になりました。
文字が小さいときは4文字でないと見にくいかもれません。
このような変更がタブ文字なら可能なのですが、以下のような事情もあり、結局、プロジェクトによって変えているのが現状です。
タブ文字の表示方法が定まってなく、さらに、デフォルトでタブ文字が空白8文字として表示されることが多い?ことも問題があるように思います。
エディタだけではなく、ツール類もあるわけで、このデフォルトを変更する一手間が非常に高いハードルなんです。
お客様の環境下で作業をするとき、むやみにツール類の設定を変えることはNGです。 ましてや、お客様に、「見にくかったらタブの設定を変えて下さい」なんて言えないのです。
また、システムの奥深くにある古い融通の利かないツールなどを利用するとき、設定自体が不明またはできないなど不幸に遭遇することもあります。 そういうものに限って、外せない理由があったりします。
勢い、表示環境に左右されない空白文字をインデントに使う無難な道を選ぶことになります。
また、タブ文字を一切使用しないと決めると、「インデントにタブを使うことのデメリット」の話に限定するようなこともなく、「コメント欄の位置揃えにはタブ文字は使用しないでね」とわざわざ注意喚起する必要はありません。
タブは、タイプライターのタブキーからの由来で、本来タブ文字なるものはなく、印字ヘッドの位置決めに使われていたものです。 印字ヘッドを元に戻す操作:キャリッジリターン(CR),１行紙送り:ラインフィード(LF) と同じ部類(制御文字)に入ります。現在はほとんど使用されていない、垂直タブ,バーチカルタブ(VT コード0B)もまだあるくらいなので、位置決めに使うなと言っても、本来の目的が位置決めから始まっているので、伝わりにくいかもしれません。
さらに、プログラムだけに話を限定されているように思いますが、データにも階層構造があり、このインデントに空白を使うかタブを使うかは、読み込むプログラム側の実装依存になり大きな問題になります。(プログラムソースもコンパイラのデータですが・・・)
投稿2015/12/22 16:39
編集2015/12/22 18:47
総合スコア19
すみません結論がよく分かりませんでした…。
冒頭の「迷っている」が結論なのかもしれませんが。
しかし老眼の進行によりスペース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を使えばコンパイルチェックがかかるのである程度の品質は保たれると思います。
あなたの回答
tips
プレビュー
