アカウント名:
パスワード:
インデントは必ず半角スペース4文字。環境によって表示がくずれるTABはあり得ない。インデントにTABを使うやつは協調性がないことを表している
まさに正論TABは環境依存というのを分かってない人が多すぎるスペースによるコード量の増加なぞ現代では気にする必要はまったくない
TABを4文字固定にするのが正義。コード量の増加なんかより、スペースでインデントされていると、カーソルが移動できる地点が増えちゃうのが鬱陶しい。
インデントの途中、3文字目、みたいなところにカーソルが留まるべき理由は一切ない。何かの操作でそんな中途半端な場所にはまり込んだ時に、矢印キーをたくさん押さないと脱出できないとか面倒くさい。左右の矢印キーなりを押したら、インデントの深さを単位としてカーソルが移動すべき。
おっと、「じゃあ、そこがインデントとして挿入された空白ならそのように飛び飛びで移動する設定にするなり、そのようなキー操作を追加で定義すりゃいいじゃん」とか言わないでよ。それより良いアイデアが有って、TABという特殊記号を使う、というのがそれだ。
各種IDEが、ソースコード中では今後はこの幅で固定、異論は認めない、というルールを押しつけりゃ良かったんだ。どうせ今後使わないなら、スペース4個分に当たる1インデントを表す便利な新たな記号を定義しましょう→ ああ、こないだ葬り去って過去のものにしたTABというキーがちょうど良いですね、で済むし。
最近の環境なら、カーソルキーなんぞで移動せんでもマウスで一発なのでは？
プログラム書いたことあるのか？
あるかないかと言われれば、プログラムは書いたことあるよ。ひょっとして、マウスは使わない派？なら、次の単語に移動みたいなキー操作でもいけるんじゃない？
矢印キーまで手を移動するならマウスまで行っても大差ないと思うけど。
#3229720 がそーいう環境の人なら
＞ 何かの操作でそんな中途半端な場所にはまり込んだ時に、矢印キーをたくさん押さないと脱出できないとか面倒くさい。
なんてセリフは出てこないかと。途中がTABだろうがスペースだろうが次のワードへの移動は一発だよね。
でも、元コメの人はカーソルキーをたくさん押すんでしょ？下手すりゃマウスの方が速いかもよ。まあ、次の単語へ移動のキー操作でもいいけど。
どちらかというとこのタブ派の主張に同意する方なのだが、
何かの操作でそんな中途半端な場所にはまり込んだ時に、矢印キーをたくさん押さないと脱出できないとか面倒くさい。
HomeとかCtrlとか、エディタの機能で簡単にナビゲーションできるのが現実ではある。スペースインデントは無駄にキャラクタ増やしてるようで気持ち良くないんだけど、拒絶するほどの理由がない。
タブは8文字と古の時代から定められています。
古の時代には、
入力したコードを表示するに、cat とか、type とか、more ,,,,, 使ってが、ここで、4文字タブが入ると不幸だった。印刷も同じ。タブコードが入ると、次の8文字目の位置に印字位置が移る。まあ、変更できるのは知っているが、ただのリストでそこまでする人は皆無。
一時、頑張っていたのを思い出した。只の悪あがきだったか。
昭和の時代のC言語の参考書はみんなそうだったなぁ
TAB派とスペース派は捕鯨やオスプレイの賛成派と反対派ぐらいには相容れなく、お互い相手の理屈が理解できない。
タブで何の表示がずれるのかはわからんが、何の表示がずれて何が困るのだろう。よくわからない。タブはインデントを表現するもので、そこにスペースを４つとか８つとか入れる理由がわからない。
インデントをスペースで行うと、『意味』が分からなくなる。
pythonは意味がわかってるみたいですよ
機能を理解している人のコードはタブでもスペースでも表示が崩れたりしないよね。スペースでも頭のおかしいコードはインデント奇数行が続いてるとか頭のおかしい事になってる。
要は流儀よりも、理知的なテキストを書いているかどうかだと思う。
それは機能を理解していない人がコードを書いてるんじゃなくてコーディングルールを徹底してないせいで、編集した人によってスペースかタブかがカオスなことになってるだけだと思うSVN管理すると下手に既存コードを変えると、重要な差分とそうでない差分がごっちゃになってdiffが取りづらくなるから下手に変えられないってことでカオスなコードがカオスなまま引き継がれるそういう状況になるからこそチーム作業でやるとタブ入れるやつは嫌われる
ここにぶら下げようかな。
社内・プロジェクトでコーディングルールを強制するなら、フォーマッタに任せれば良いんですよ。チェックインする前にフォーマッタに掛けるルールにするとか、チェックイン時に自動でフォーマッタが掛かる様にして置くとか。そういうルールが確立されていれば、フォーマッタを掛けた後にインデント等が崩れていたら、そのコードを書いたヤツを全員で思いっきり叱責・非難すれば良いんです。
ただ思うのは、8カラム以外でインデントしてるコードを書く人って、保守性の悪いコードを書く傾向があるのではないかと。つまり、コードの書き方とかの表層的な話ではなくて、アルゴリズムとか機能分割とかの面で劣ったコードを書くのではないかという話。ネストが深い、あまり見通しの良くないコードを書く素地があるから、インデント幅を4カラムとか2カラムとかにする必然性が生じるんじゃないかな。
そういう状況になるからこそチーム作業でやるとタブ入れるやつは嫌われる
いやいやいや、それ逆も然りでしょwルールがあればそれに従わないのは完全に頭おかしいけど、それ以前の話をしてるんじゃないのかね。
普段は空白無視するツールを使えばいいけど、ルール違反は発見次第すぐ修正コミット掛け(させ)た方がいいよ。空白の修正なんて人畜無害だから。
おそらくこういうやつvoid very_long_function_name(int a,\t\t\t\t double b)タブが4カラムか8カラムかそういうのでずれる
スペース派は↓こうなるからいいってこと？
void very_long_function_name(int a, double b);
残念ながら上はフォントが等幅フォントでないと意図通りに表示されないが、ようはint a,double b);の開始位置を合わせたいってことだよね。
確かに合わせたいというのはわかるが、俺は合わせない。二行にまたがる時点であきらめて、全部タブにする。
引数を揃えるなら、 void very_long_function_name( int a, double b ); こうじゃないかな…。
これはいいね！一つ目の変数から二行目に書く発想はなかった。これから使おう。
えっ・・・発想なかったって、流石にプログラマの適正がないよ。
まあ、そういうなよ。他の仕事の適正はもっとないんだからさ・・・。営業とか土方とか今更できん。
「適正がない」
営業や土方は正しくないってことさ・・・Microsoft IMEが悪いんだ！
K＆RなCに先祖返りしたみたいな……。
ちょっと誤解していた。タブサイズが可変だと、本来のインデント以外の部分がタブ幅設定によってずれるってことか。
タブ幅４イメージvoid very_long_function_name(int a, double b);
タブ幅８イメージvoid very_long_function_name(int a, double b);
上記はフォントで変わるので、一行目と二行目の変数の型の開始位置は合わないが。みたいな。
タブとかスペース以前に変なところに意味もなく改行を入れるのはやめてくれないかな？
あ・・・すいません気を付けますそれじゃ今までのも直しますか
コードの書き方の注意とか できればもっと早めに言っていただけると・・・
おっとここでエディタ横幅論争の場外乱闘だぁ!
変数の引数などはIDEの機能を使って確認するのでコード上でどう書いてあるかはきにしない。void caos(int num,int Num,int NUm,int NUM){}
もしかして:chaos
整形したい気持ちは分からなくもないけど手段がアレなのは方眼紙エクセルに通ずるものがある方眼紙エクセルを笑うのはプログラマやそれに近い人達に多いと思ってたけど案外そうでもないのかな
と、協調性のなさそうな主張されても。。。
＃ ツリですよね？
協調性ってのは他人に求めるものであって自分が発揮するものではないからね。
タブはストレージや回線が貧弱、高価だったテレタイプ時代からの負の遺産だな。今の時代こんなものに付き合う必要はない。
エディタ幅にしてもタブにしても、一つだけ言えることがある。不必要にこだわって、協調性が無いとか言い出すヤツは大体キティーで触ったらやばいことになる人w
インデントのスペースは2文字の方がいい。
インデント1回で4文字も使ったら、5回下になった時に20文字も幅を消費していることになる。そんなことやるとすぐに80文字を超えるから余計に見づらくなる。
インデント 2 は勘弁して欲しい。どことどこが対応してるのか、パッと見て解らない。4 くらいが好き。
たぶん、ブロック開始と終了が離れてる私のコードが問題なんだろうけど。
仮想端末上で vim でコーディングとかなら８０文字のこだわりも分かるが、今時のIDEなんかでは、もっと広い編集領域で作業するよね。まあ、深々としたインデント自身が見にくいので、関数にくくり出すとかした方がいいのでは。
俺はこれはLinusの言うことが正しいと思うな。インデントが5段になるコードはそもそもクソなので書き直せ。
namespace class method switch case break
言語がクソですよねわかりますん。
まあループの重多段はクソだけど、構造表現で深くなるのは悪では無いので、つまり本質的に↑の形のものを構文糖で浅く書けたところで意味は同じなので、インデントが深い＝クソとは言い切れないだろう。
未だに80文字制約に縛られた言語って、何なんですかね？C++でも下手すると変数型で80文字突破しますよ？
画面の横幅が増えても人間の短期記憶領域が増えるわけじゃないからな。一行に情報を詰め込み過ぎると読みにくくなる。特にdiffの前後を横に並べて表示すると、幅を決めておかないと行内改行ばっかりになって、Wikipediaの差分表示みたいになる。
https://ja.wikipedia.org/w/index.php?title=%E6%94%B9%E8%A1%8C&type... [wikipedia.org]
こういうやつね。1行が80文字だと差分を見る際の作業効率が段違いだよ。んで、世の中作業の大半は差分にしかないわけだから。パッチをメールで送る時も楽だしね。80文字制限を外すのがむしろ極論だと思う。
私も以前はそのように考えていました。コンパイル前にindentを使うようになってからは変換するので問題なくなりました。
タブだと矩形選択時に問題が出るエディタもあるので、スペース派。# 矩形選択というかフリーカーソル的な編集をしたいだけ
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
未知のハックに一心不乱に取り組んだ結果、私は自然の法則を変えてしまった -- あるハッカー
TABはありえない (スコア:0)
インデントは必ず半角スペース4文字。
環境によって表示がくずれるTABはあり得ない。
インデントにTABを使うやつは協調性がないことを表している
Re:TABはありえない (スコア:1)
まさに正論
TABは環境依存というのを分かってない人が多すぎる
スペースによるコード量の増加なぞ現代では気にする必要はまったくない
Re:TABはありえない (スコア:2, すばらしい洞察)
TABを4文字固定にするのが正義。
コード量の増加なんかより、スペースでインデントされていると、カーソルが移動できる地点が増えちゃうのが鬱陶しい。
インデントの途中、3文字目、みたいなところにカーソルが留まるべき理由は一切ない。
何かの操作でそんな中途半端な場所にはまり込んだ時に、矢印キーをたくさん押さないと脱出できないとか面倒くさい。
左右の矢印キーなりを押したら、インデントの深さを単位としてカーソルが移動すべき。
おっと、「じゃあ、そこがインデントとして挿入された空白ならそのように飛び飛びで移動する設定にするなり、
そのようなキー操作を追加で定義すりゃいいじゃん」とか言わないでよ。
それより良いアイデアが有って、TABという特殊記号を使う、というのがそれだ。
各種IDEが、ソースコード中では今後はこの幅で固定、異論は認めない、というルールを押しつけりゃ良かったんだ。
どうせ今後使わないなら、スペース4個分に当たる1インデントを表す便利な新たな記号を定義しましょう
→ ああ、こないだ葬り去って過去のものにしたTABというキーがちょうど良いですね、で済むし。
Re: (スコア:0)
最近の環境なら、カーソルキーなんぞで移動せんでもマウスで一発なのでは？
Re: (スコア:0)
プログラム書いたことあるのか？
Re: (スコア:0)
あるかないかと言われれば、プログラムは書いたことあるよ。
ひょっとして、マウスは使わない派？
なら、次の単語に移動みたいなキー操作でもいけるんじゃない？
Re: (スコア:0)
Re:TABはありえない (スコア:1)
矢印キーまで手を移動するならマウスまで行っても大差ないと思うけど。
Re:TABはありえない (スコア:1)
#3229720 がそーいう環境の人なら
＞ 何かの操作でそんな中途半端な場所にはまり込んだ時に、矢印キーをたくさん押さないと脱出できないとか面倒くさい。
なんてセリフは出てこないかと。
途中がTABだろうがスペースだろうが次のワードへの移動は一発だよね。
Re: (スコア:0)
でも、元コメの人はカーソルキーをたくさん押すんでしょ？
下手すりゃマウスの方が速いかもよ。
まあ、次の単語へ移動のキー操作でもいいけど。
Re: (スコア:0)
どちらかというとこのタブ派の主張に同意する方なのだが、
何かの操作でそんな中途半端な場所にはまり込んだ時に、矢印キーをたくさん押さないと脱出できないとか面倒くさい。
HomeとかCtrlとか、エディタの機能で簡単にナビゲーションできるのが現実ではある。
スペースインデントは無駄にキャラクタ増やしてるようで気持ち良くないんだけど、拒絶するほどの理由がない。
Re: (スコア:0)
タブは8文字と古の時代から定められています。
Re:TABはありえない (スコア:1)
古の時代には、
入力したコードを表示するに、cat とか、type とか、more ,,,,, 使ってが、
ここで、4文字タブが入ると不幸だった。
印刷も同じ。タブコードが入ると、次の8文字目の位置に印字位置が移る。
まあ、変更できるのは知っているが、ただのリストでそこまでする人は皆無。
一時、頑張っていたのを思い出した。只の悪あがきだったか。
Re: (スコア:0)
昭和の時代のC言語の参考書はみんなそうだったなぁ
Re:TABはありえない (スコア:1, 興味深い)
TAB派とスペース派は捕鯨やオスプレイの賛成派と反対派ぐらいには相容れなく、お互い相手の理屈が理解できない。
タブで何の表示がずれるのかはわからんが、何の表示がずれて何が困るのだろう。よくわからない。
タブはインデントを表現するもので、そこにスペースを４つとか８つとか入れる理由がわからない。
Re:TABはありえない (スコア:3)
インデントをスペースで行うと、『意味』が分からなくなる。
Re:TABはありえない (スコア:2, おもしろおかしい)
pythonは意味がわかってるみたいですよ
Re:TABはありえない (スコア:1)
機能を理解している人のコードはタブでもスペースでも表示が崩れたりしないよね。
スペースでも頭のおかしいコードはインデント奇数行が続いてるとか頭のおかしい事になってる。
要は流儀よりも、理知的なテキストを書いているかどうかだと思う。
Re: (スコア:0)
それは機能を理解していない人がコードを書いてるんじゃなくて
コーディングルールを徹底してないせいで、編集した人によってスペースかタブかがカオスなことになってるだけだと思う
SVN管理すると下手に既存コードを変えると、重要な差分とそうでない差分がごっちゃになってdiffが取りづらくなるから
下手に変えられないってことでカオスなコードがカオスなまま引き継がれる
そういう状況になるからこそチーム作業でやるとタブ入れるやつは嫌われる
Re:TABはありえない (スコア:3, すばらしい洞察)
ここにぶら下げようかな。
それは機能を理解していない人がコードを書いてるんじゃなくて
コーディングルールを徹底してないせいで、編集した人によってスペースかタブかがカオスなことになってるだけだと思う
SVN管理すると下手に既存コードを変えると、重要な差分とそうでない差分がごっちゃになってdiffが取りづらくなるから
下手に変えられないってことでカオスなコードがカオスなまま引き継がれる
そういう状況になるからこそチーム作業でやるとタブ入れるやつは嫌われる
社内・プロジェクトでコーディングルールを強制するなら、フォーマッタに任せれば良いんですよ。チェックインする前にフォーマッタに掛けるルールにするとか、チェックイン時に自動でフォーマッタが掛かる様にして置くとか。そういうルールが確立されていれば、フォーマッタを掛けた後にインデント等が崩れていたら、そのコードを書いたヤツを全員で思いっきり叱責・非難すれば良いんです。
ただ思うのは、8カラム以外でインデントしてるコードを書く人って、保守性の悪いコードを書く傾向があるのではないかと。つまり、コードの書き方とかの表層的な話ではなくて、アルゴリズムとか機能分割とかの面で劣ったコードを書くのではないかという話。ネストが深い、あまり見通しの良くないコードを書く素地があるから、インデント幅を4カラムとか2カラムとかにする必然性が生じるんじゃないかな。
Re: (スコア:0)
そういう状況になるからこそチーム作業でやるとタブ入れるやつは嫌われる
いやいやいや、それ逆も然りでしょw
ルールがあればそれに従わないのは完全に頭おかしいけど、それ以前の話をしてるんじゃないのかね。
普段は空白無視するツールを使えばいいけど、ルール違反は発見次第すぐ修正コミット掛け(させ)た方がいいよ。
空白の修正なんて人畜無害だから。
Re: (スコア:0)
おそらくこういうやつ
void very_long_function_name(int a,
\t\t\t\t double b)
タブが4カラムか8カラムかそういうのでずれる
Re: (スコア:0)
スペース派は↓こうなるからいいってこと？
void very_long_function_name(int a,
double b);
残念ながら上はフォントが等幅フォントでないと意図通りに表示されないが、ようは
int a,
double b);
の開始位置を合わせたいってことだよね。
確かに合わせたいというのはわかるが、俺は合わせない。
二行にまたがる時点であきらめて、全部タブにする。
Re:TABはありえない (スコア:3)
引数を揃えるなら、
void very_long_function_name(
int a,
double b
);
こうじゃないかな…。
ほえほえ
Re: (スコア:0)
これはいいね！
一つ目の変数から二行目に書く発想はなかった。
これから使おう。
Re: (スコア:0)
えっ・・・発想なかったって、流石にプログラマの適正がないよ。
Re: (スコア:0)
まあ、そういうなよ。
他の仕事の適正はもっとないんだからさ・・・。
営業とか土方とか今更できん。
Re: (スコア:0)
「適正がない」
Re: (スコア:0)
営業や土方は正しくないってことさ・・・Microsoft IMEが悪いんだ！
Re: (スコア:0)
K＆RなCに先祖返りしたみたいな……。
Re: (スコア:0)
ちょっと誤解していた。
タブサイズが可変だと、本来のインデント以外の部分がタブ幅設定によってずれるってことか。
タブ幅４イメージ
void very_long_function_name(int a,
double b);
タブ幅８イメージ
void very_long_function_name(int a,
double b);
上記はフォントで変わるので、一行目と二行目の変数の型の開始位置は合わないが。
みたいな。
Re: (スコア:0)
タブとかスペース以前に変なところに意味もなく改行を入れるのはやめてくれないかな？
Re:TABはありえない (スコア:2, おもしろおかしい)
あ・・・
すいません気を付けます
それじゃ今までのも直しますか
コードの書き方の注意とか できればもっと早めに言っていただけると・・・
Re: (スコア:0)
おっとここでエディタ横幅論争の場外乱闘だぁ!
Re: (スコア:0)
変数の引数などはIDEの機能を使って確認するのでコード上でどう書いてあるかはきにしない。
void caos(int num,int Num,int NUm,int NUM){}
Re: (スコア:0)
もしかして:chaos
方眼紙エクセル脳 (スコア:0)
整形したい気持ちは分からなくもないけど手段がアレなのは方眼紙エクセルに通ずるものがある
方眼紙エクセルを笑うのはプログラマやそれに近い人達に多いと思ってたけど案外そうでもないのかな
Re: (スコア:0)
と、協調性のなさそうな主張されても。。。
＃ ツリですよね？
Re:TABはありえない (スコア:1)
協調性ってのは他人に求めるものであって自分が発揮するものではないからね。
Re: (スコア:0)
タブはストレージや回線が貧弱、高価だったテレタイプ時代からの負の遺産だな。
今の時代こんなものに付き合う必要はない。
Re: (スコア:0)
エディタ幅にしてもタブにしても、一つだけ言えることがある。
不必要にこだわって、協調性が無いとか言い出すヤツは大体キティーで触ったらやばいことになる人w
Re: (スコア:0)
インデントのスペースは2文字の方がいい。
インデント1回で4文字も使ったら、5回下になった時に20文字も幅を消費していることになる。そんなことやるとすぐに80文字を超えるから余計に見づらくなる。
Re:TABはありえない (スコア:1)
インデント 2 は勘弁して欲しい。
どことどこが対応してるのか、パッと見て解らない。
4 くらいが好き。
たぶん、ブロック開始と終了が離れてる私のコードが問題なんだろうけど。
Re: (スコア:0)
仮想端末上で vim でコーディングとかなら８０文字のこだわりも分かるが、
今時のIDEなんかでは、もっと広い編集領域で作業するよね。
まあ、深々としたインデント自身が見にくいので、
関数にくくり出すとかした方がいいのでは。
Re: (スコア:0)
俺はこれはLinusの言うことが正しいと思うな。
インデントが5段になるコードはそもそもクソなので書き直せ。
Re:TABはありえない (スコア:1)
namespace
class
method
switch
case
break
言語がクソですよねわかりますん。
まあループの重多段はクソだけど、構造表現で深くなるのは悪では無いので、つまり本質的に↑の形のものを
構文糖で浅く書けたところで意味は同じなので、インデントが深い＝クソとは言い切れないだろう。
Re: (スコア:0)
未だに80文字制約に縛られた言語って、何なんですかね？
C++でも下手すると変数型で80文字突破しますよ？
Re:TABはありえない (スコア:1)
画面の横幅が増えても人間の短期記憶領域が増えるわけじゃないからな。一行に情報を詰め込み過ぎると読みにくくなる。特にdiffの前後を横に並べて表示すると、幅を決めておかないと行内改行ばっかりになって、Wikipediaの差分表示みたいになる。
https://ja.wikipedia.org/w/index.php?title=%E6%94%B9%E8%A1%8C&type... [wikipedia.org]
こういうやつね。1行が80文字だと差分を見る際の作業効率が段違いだよ。んで、世の中作業の大半は差分にしかないわけだから。パッチをメールで送る時も楽だしね。80文字制限を外すのがむしろ極論だと思う。
Re: (スコア:0)
私も以前はそのように考えていました。
コンパイル前にindentを使うようになってからは変換するので問題なくなりました。
Re: (スコア:0)
タブだと矩形選択時に問題が出るエディタもあるので、スペース派。
# 矩形選択というかフリーカーソル的な編集をしたいだけ