07/03/09 14:02:01
自分は1行しか書かないつもりでも
あとでコードを足さなければならない事態なんていくらでもやってくる。
他人がきちんと中括弧補ってくれるかどうかはわからない。
1行文だろうがなんだろうが
最初から中括弧をつけるクセをつけろ
2:デフォルトの名無しさん
07/03/09 14:09:42
>>1
禿同!!
3:デフォルトの名無しさん
07/03/09 14:15:37
>>2
自演乙!!
4:デフォルトの名無しさん
07/03/09 14:25:56
アンケートとったんですか？
アンケートに答える暇がある人にのみ聞いたんですか？
5:デフォルトの名無しさん
07/03/09 14:35:17
>>4はVB使い
6:デフォルトの名無しさん
07/03/09 14:47:19
自分ひとりで書くときはつけないが、人と組むときはつけることにしてるな。
7:デフォルトの名無しさん
07/03/09 14:53:32
同じく。
でも自分が信用できないので最近は１行でも書くようにしてる。
今のところ（自分一人で使う範囲でも）
このおかげでバグが出たことはないけど。
8:デフォルトの名無しさん
07/03/09 15:14:17
>>6
スクリプトでポイポイ使い捨てのつもりで書いた物とかならともかく。
自分一人の時でもコーディング規約を適用するとそれほど縛りを感じないけどな。
むしろコーディング規約ナシで書いて半年後に眺めた日には泣ける。
規約があると、その規約を適用していた時のコードを振り返るときも楽だし。
9:デフォルトの名無しさん
07/03/09 15:35:12
そんなん明らかに実行結果違うでしょ。
コーディング後テスト出来ずに、すぐにリリースしなくてはならない環境だったり
中括弧の後の追加文が検証しにくい環境であることの方が問題。
10:デフォルトの名無しさん
07/03/09 16:26:38
＿＿ ＿＿ ＿＿＿＿＿ ＿＿＿＿_ ___ ___ ___
| | / / / | /＿＿ __/ [][] ＿| |_| |＿_ _| |_
| |. / / / /￣￣|. l / / | ＿ | |_ ﾚ'~￣|
| | / / / /. ／ / | |___ ￣| | / / / ／| |
| | / / / ￣￣ ／ ＼＿_| | | ￣ /_ / | |_
| |. / / / /￣￣| ＼ |＿| |__| ＼/
| |/ / / / ｜ |
|. / / / ／ / Powered By Visual Basic 6.0
| /. ./ ￣￣ ／ ｽﾚﾘﾝｸ(prog板)
￣￣￣ ￣￣￣￣￣￣
11:デフォルトの名無しさん
07/03/09 16:37:41
そもそも、そんなに入力めんどくさいモンじゃないじゃん
省略しないほうがメリット大なのに省略するやつって
インデントもグチャグチャなことが多い。
条件式も代入も全部インデントなしの位置で記述してたり
12:デフォルトの名無しさん
07/03/09 16:53:06
いつも省略しないで書くから、｛｝省略しているコードが非常に読みづらい
省略している奴らはなんか美意識とかあんのかなぁ
13:デフォルトの名無しさん
07/03/09 16:58:19
省略するだろ普通。
それだけ縦方向に圧縮できて情報量がふえる
インデントで対応するPythonやendをつけるRubyなんかはたしかにこの手の問題を意識してるのかな
14:デフォルトの名無しさん
07/03/09 17:19:38
if文1つにつき1行そこらで情報量が増えるとか言われてもねえ
15:デフォルトの名無しさん
07/03/09 17:48:07
>>1
俺も省略するが、それでトラブるのは莫迦だからじゃね？
>>13-14
そんな大層なもんじゃねえだろ。
16:デフォルトの名無しさん
07/03/09 18:10:40
馬鹿な奴ほど、なんでも省略したがる傾向にあるんだよな。
頭のいい奴は省略なんてしねーよ。重要なのは省略じゃなく最適化だろうが。
中括弧の省略は可読性を低下させるだけの悪習だろ。
そんなにソースの情報量にこだわるのなら、空白文字類をすべて省けよ。
ま、中括弧をつけないことに美を感じるとか趣味だとかそういう理由なら何も言わんが。
好きにすればって感じ。
つうか、中括弧ごときで騒ぐ奴のほうがおかしいんじゃねーのとか思っちゃうけどね。
17:デフォルトの名無しさん
07/03/09 19:21:37
開発ソフトでソース書けば全解決ではないのですか？
よくシリマセンガ！
18:デフォルトの名無しさん
07/03/09 19:21:54
省略できてしまう文法が悪い。
宗教戦争起こるのは当然。
19:デフォルトの名無しさん
07/03/09 19:22:38
ぜひともトラブルの７０％とかいうソースを出してもらいたい。
調査したの？
20:デフォルトの名無しさん
07/03/09 19:36:53
これは大いに賛成
省略して何がうれしいのかと思う
自分はミスしない、と言うやつは一人で
コーディングして、一切ソースを人に見せない人なんだろう
21:デフォルトの名無しさん
07/03/09 19:41:56
人間って、１０段階評価って出来ないですよね
22:デフォルトの名無しさん
07/03/09 19:44:05
評価されたら１か２ばかりつけられちゃうじゃまいか
いやん
23:デフォルトの名無しさん
07/03/09 19:44:11
まぁ、情報量増やしたい奴らは、改行しないでエディタの右端で折り返しとかすれば一度にみれる情報量一気にふえるじゃん
情報量というか、可読性とかをあげた方が最終的にはバグとか減って生産性も上がると思うんだがな。
24:デフォルトの名無しさん
07/03/09 19:46:57
数値で評価といっても、結果的に、あるものとの比較による評価だよね。
25:デフォルトの名無しさん
07/03/09 19:53:34
{}省略してる奴が
コメントアウトで//ああお腹すいた
とか書いてたりすると殺意を覚える
26:デフォルトの名無しさん
07/03/09 20:03:41
このスレには少々驚いたな。一行の方が基本かと思ってた。
省略してると解釈するものか・・・。
27:デフォルトの名無しさん
07/03/09 20:05:24
java言語すら存在しない時代のCの教育書には
>>1と同じことが書いてある
28:デフォルトの名無しさん
07/03/09 20:11:28
これが原因でトラブルを起こすような奴がコードを書いてることが問題
29:デフォルトの名無しさん
07/03/09 20:13:45
>>28
人間のミスのほとんどは、ケアレスミスだよ。
言い方を換えれば、ケアレスミスをしないですむ状況をつくればミスは減る。
30:デフォルトの名無しさん
07/03/09 20:13:50
マ板でやれ。
31:デフォルトの名無しさん
07/03/09 20:23:55
ケアレスミスを減らすために決まりを沢山作るよりも、
問題がすぐに発見/修正されるような仕組みを作ることが重要。
32:デフォルトの名無しさん
07/03/09 21:33:23
取り敢えず一切省略しない。
エディタがifを入れたところでブレースを含めて展開してくれるから、面倒もない。
33:デフォルトの名無しさん
07/03/09 21:34:48
俺は基本的に1行でも{}はつけるけどたまにつけない事もある。
つけない事が原因でバグが入った事は無い。
34:デフォルトの名無しさん
07/03/09 21:38:20
{}無くてもインデント付けてりゃまず見逃さないだろ
35:デフォルトの名無しさん
07/03/09 21:42:25
>>31
少なくとも省略して可読性を悪くする人間は失格ｄな
36:デフォルトの名無しさん
07/03/09 21:45:05
省略を許してしまうような言語が悪い
俺は悪くない
37:デフォルトの名無しさん
07/03/09 21:47:36
>>35
あんたにとって可読性が良いコードが万人にとって可読性が良いわけじゃないでしょ。
38:デフォルトの名無しさん
07/03/09 21:54:09
>>37
{}を使った方が可読性が良いって流れなんだけどな
39:デフォルトの名無しさん
07/03/09 21:55:34
だからそれは万人にとってじゃないでしょ。
間延びして読みにくいと感じる人もいるわけで。
40:デフォルトの名無しさん
07/03/09 22:03:16
{}付ける派だが、俺は
if()
{
// ...
}
って開きを綴じと同じレベルに置きたいから無駄になるのが1行じゃなくて2行なんだよな。
41:デフォルトの名無しさん
07/03/09 22:06:59
{{{{{{if(1)printf("Hello, world");}}}}}}
42:デフォルトの名無しさん
07/03/09 22:07:51
俺は状況によって色々
if (...) {
aaaaaa;
bbbbbb;
}
if (...)
{
int n = 0;
aaaaaa;
bbbbbb;
}
43:デフォルトの名無しさん
07/03/09 22:13:27
>>42
そういう決まりが無いのがトラブルを起こしやすいんじゃない？
44:デフォルトの名無しさん
07/03/09 22:13:33
そもそも省略不可な場合（複数行）が多くて、つけるのが癖になってる。
仮にものすごく低い確率でつけ忘れたってトラブルになる程でもない。
ちょっと実行してみて、あれおかしいな、ああここか修正修正って感じ。
この程度じゃトラブルになりようがない。
ワープロの文書コピー作業じゃないんだから。
45:デフォルトの名無しさん
07/03/09 22:16:34
>>43
決まりはあるけど？
46:デフォルトの名無しさん
07/03/09 22:21:06
関数の最初の方で早抜けするときはこうも書くな
if (...) return;
47:デフォルトの名無しさん
07/03/09 22:40:44
if (...)
if (...)
aho();
else
baka();
48:デフォルトの名無しさん
07/03/09 22:42:30
つまり Python を使えばコーディングトラブルの約70%を省略できると(w
49:デフォルトの名無しさん
07/03/09 22:50:01
if(...)
nurupo();
else
50:デフォルトの名無しさん
07/03/09 23:03:09
if(...)
b = a>>49;
else
gaxtu();
51:デフォルトの名無しさん
07/03/09 23:32:32
完全記述
if(...) {
} else {
if(...) {
}
}
52:デフォルトの名無しさん
07/03/09 23:34:33
こうだろ？ｗ
if (...)
{
}
else
{
if (...)
{
}
}
53:デフォルトの名無しさん
07/03/09 23:41:53
以前は>>51のスタイルだったけど
VisualC#を使い始めてから>>52になった。
54:デフォルトの名無しさん
07/03/09 23:42:50
甘い。正解はこれ。
if (...)
{
}
else
{
if (...)
{
}
else
{
//do nothing
}
}
55:デフォルトの名無しさん
07/03/09 23:43:10
JavaでもC++でも>>52みたいに書いてる学生だけど
今のうちに修正した方がいいんだろーかと悩むお年頃
56:デフォルトの名無しさん
07/03/09 23:45:04
インデントがプログラムの意味とずれてさえいなければ、どれでも問題なっしんぐ。
あと、人のコードをいじるときは周囲に合わせる控えめな心が大事ｗ
57:デフォルトの名無しさん
07/03/09 23:47:16
心に刻んでおきます
58:デフォルトの名無しさん
07/03/09 23:47:18
プログラミング歴20余年の俺は紆余曲折を経て最終的に>>52のスタイルに至ったんだが。
59:デフォルトの名無しさん
07/03/09 23:48:42
else if
だけはぶら下げちまえ。
ぶら下げ使ってくれ。
頼むから。
あと、俺は
if(..) {
}
派なんだけど、
if(...)
{
}
派が理解できない。
一行無駄だろ。
60:デフォルトの名無しさん
07/03/09 23:51:23
eclipse(ﾃﾞﾌｫ)は>51なんだが、君たちの開発ソフトはどんな記述だ？
61:デフォルトの名無しさん
07/03/09 23:54:17
>>59
ブロックの中でローカルな変数使うときだけは
if (...)
{
変数宣言
あれこれあれこれ
ずびずばぱやぱや
}
ってやりたくなる。
62:デフォルトの名無しさん
07/03/09 23:54:37
>>60
if (..) {
} else if (...) {
} else {
}
俺もeclipseだけど。
63:デフォルトの名無しさん
07/03/09 23:57:10
>>60 >>62
else の後の if を {} に入れてるかどうかで当然後の整形結果も違ってくるんだろ
64:58
07/03/10 00:01:39
else if は俺の場合こうだ。
if (...)
{
...
}
else
if (...)
{
...
}
else
if (...)
{
...
}
65:デフォルトの名無しさん
07/03/10 00:03:09
昔こうやってた時期がある。
あほか、とｗ
/**/ if (...) {
}
else if (...) {
}
else {
}
66:デフォルトの名無しさん
07/03/10 00:07:12
{}をつけないのは副作用のあるループで本体が空の場合だけかな
while (i--)
;
こんなの。
67:デフォルトの名無しさん
07/03/10 00:09:18
>>66
それはこうやるな
while (i--) {}
68:デフォルトの名無しさん
07/03/10 00:21:32
【ネガティブ派遣根性チェック】
3つ以上、思い当たる点があればアナタの性格はひん曲がっており、ネガティブ負け組人生を歩んでいます。
□派遣先の人事権のある社員の意見はたとえ間違っていてもマンセーする
□派遣先から「いつまでもここで仕事してくださいね(安い金でｗ)」と言われて嬉しい
□自社で仕事なんてできるわけがない
□派遣労働の問題点の話題が出ると感情剥き出しにして反論する
□派遣労働の問題を指摘する人は嫌いだ
□派遣先には仕事だけでなく自分のプライベートについても指示して欲しい
□奢ってくれる派遣先正社員は尊敬する
□自分の月額金額を知らないのは当然だ
□派遣先正社員より自分の生涯収入が低いのは当然だ
□派遣先に尻尾を振り、いつまでも派遣を続けることが大切だ
69:58
07/03/10 00:21:55
>>66
それでも、俺の場合はこうだ。
while(i--)
{
}
俺も青かったころは
while(i--);
とかやってたけどね。
70:デフォルトの名無しさん
07/03/10 00:25:32
典型的なレベルの低いスレだな。
こんなのは、「俺の場合」とかじゃなくて、決められたコーディング規則で書け。
71:デフォルトの名無しさん
07/03/10 00:27:37
これは恥ずかしいレスだな
72:デフォルトの名無しさん
07/03/10 00:27:40
>>70
趣味でやってる場合はコーディング規則なんてないし、
仕事でやってる場合でもそのコーディング規則とやらはたいてい誰かの「俺の場合」なんだが。
73:デフォルトの名無しさん
07/03/10 00:28:07
プログラミングは研究で使うだけで規則は決められてない
74:デフォルトの名無しさん
07/03/10 00:28:24
>>70
規約がある場面ならそれに従うのが前提だろ。
75:デフォルトの名無しさん
07/03/10 00:29:20
俺は縦方向にあまり引き伸ばしちゃうと、意味が俯瞰しにくい気がするんだな。
76:デフォルトの名無しさん
07/03/10 00:32:19
自信のない論拠を補強するために妄想で実体のない数字を提示する奴って、
すぐ言い訳や嘘をつくから一緒に仕事をしたくない。
77:デフォルトの名無しさん
07/03/10 00:34:12
うちは皆さんとは逆にif文にブロック禁止。
if(条件) 関数1(); else 関数2();
で書く。
78:デフォルトの名無しさん
07/03/10 00:35:09
コーディングレベルの低い奴に限ってコーディングルールの話をやたらとするんだよなｗ
そんな暇があったらコード書けよｗｗｗ
79:デフォルトの名無しさん
07/03/10 00:36:11
>>77
(条件) ? 関数1() : 関数2();
80:デフォルトの名無しさん
07/03/10 00:37:32
>>77
俺の場合、どうしても１行に納めたい場合は if 文使わずに
(条件 && (関数1(), true)) || (関数2(), true);
とかってする。
81:デフォルトの名無しさん
07/03/10 00:40:16
コードフォーマッタで括弧も自動で付けてくれる奴ってある？
82:デフォルトの名無しさん
07/03/10 00:40:37
チーム平均レベルが低い問題の100%は>>1が原因
83:デフォルトの名無しさん
07/03/10 00:44:26
>>80
詰め込みすぎだw
84:デフォルトの名無しさん
07/03/10 00:45:10
ていうか手段と目的が入れ替わってる
85:デフォルトの名無しさん
07/03/10 00:46:09
>>78 みたいなヤツが、小汚くてメンテナンス性ゼロなコードをまき散らしてんだろうな。
86:デフォルトの名無しさん
07/03/10 00:47:05
そんなに１行にしたいなら改行しなきゃいいだけじゃん。
87:デフォルトの名無しさん
07/03/10 00:48:04
みんな好きだねこういうスレ。
レスの伸びること伸びること。
88:デフォルトの名無しさん
07/03/10 00:49:25
>>85
お前はコードレビューの時につまんない俺流コーディング規則を得意げに解説したりするんだろｗ
聞いてる人うんざりだろうなｗｗｗ
89:デフォルトの名無しさん
07/03/10 00:50:02
>>87
知識が無くても話せるからねｗ
90:デフォルトの名無しさん
07/03/10 00:50:24
コーディング云々よりも、嘘つきの方が遙かに厄介。
91:デフォルトの名無しさん
07/03/10 00:52:52
>>88
お前にいいものやるよ。
つ [鏡]
お前の書き込み見てる人うんざりだから。
92:デフォルトの名無しさん
07/03/10 00:58:18
>>1のように自分のミスを他人のコードのせいにして、非を認めずに言い訳し続けたり、
何の根拠もない数字を持ってきて嘘をついたりする人間がプロジェクトに混ざっていると、
非常に迷惑極まりない状態になる。
93:デフォルトの名無しさん
07/03/10 01:03:59
有名ソフトや書籍でも、一行の場合は{}は省略してるのは多いな。
まあ、コーディングルールでも、どうでもいい部分だろな。
これは。
94:デフォルトの名無しさん
07/03/10 01:10:14
>>77
えええええええ
そんなあほらしい規約があるのか。。
驚愕
95:デフォルトの名無しさん
07/03/10 01:14:03
>>94
多少、あほな規約でもちゃんと一貫して守られてさえいればおk。
まぁ、厳しく管理してない限り、たいていなし崩しになっちゃうんだけどな。
96:デフォルトの名無しさん
07/03/10 01:17:27
>>95
> あほな規約でもちゃんと一貫して守られてさえいればおk。
そんなことねーよ。
97:デフォルトの名無しさん
07/03/10 01:19:23
linuxカーネルは、1行の場合は省略だね。
そうじゃないと、コミッタに罵倒されてパッチを受け付けてくれなかったり。
まぁlinuxの場合、インデントは8でタブで無いといけないという決まりもあるので、
読み間違えることは、まず無いのだが。
自分はドライバ書いてるが、そういう文化があるから、Cの場合は省略することが多いね。
でもJavaでは絶対省略しない。ていうか許している仕様が理解できない。
あと、elif とかをなんで用意しなかったのか、謎でしょうがない。
三項演算子もJavaの場合は使わないな。
98:デフォルトの名無しさん
07/03/10 01:30:23
既にある規約を、そのやり方ではミスが増えるとか主張して、
自分流のやり方を押し通そうとする奴がいるが、
いままでそんな問題はなかったからとみんなになだめられても、
絶対に考えを曲げずに最後にはふてくされる。
はっきりいってこういう奴は使えない。
99:デフォルトの名無しさん
07/03/10 01:39:40
>>98
>いままでそんな問題はなかったからと
ヘボいところは、自分らがいかにヘボいか理解できないからなぁ。
まあ、そういう所でやり方を変えようなんて怖くていえないけどな。
当たり前のことができずにトラブって「なんでやり方かえた→言い出したヤツはだれだ」
って展開になりがち。
100:デフォルトの名無しさん
07/03/10 01:39:50
現場の状況に合わせて柔軟に対処できない奴はあらゆるトラブルの原因になる。
101:デフォルトの名無しさん
07/03/10 01:42:43
Perlの
～if ...;
って何気に最強だな。
102:デフォルトの名無しさん
07/03/10 01:45:51
>>99
規約を変えたければ管理する側に回ってからにしないと統率がとれなくなるだろ。
主張が通らない時点で、その権限が無いことが理解出来ないのが問題なんだよ。
自分の言っていることが正しいと思いこんで、自分勝手な行動をしているという認識がない。
103:デフォルトの名無しさん
07/03/10 01:53:47
>>102
いや、そこんとこは誰も問題にしてないから。
104:デフォルトの名無しさん
07/03/10 02:49:26
クラスの使い方覚えてホイホイ作りまくってたら
「解かりにくいわ！」って殴られた｡･ﾟ･(PД`q｡)･ﾟ･
105:デフォルトの名無しさん
07/03/10 03:34:25
>101
Rubyにもあるな。俺は and 派だが。
106:デフォルトの名無しさん
07/03/10 03:44:40
アホなルールもあるこたあるからね。
1ファイルにつき1関数とか、
関数に分けてはいけない(mainだけにしろ)とか、
関数名・変数名は紙ベースの台帳管理で関数はfxxxx変数はvxxxx(xxxxは数字)とか、
こういう規則はどうなんだろう。理にかなっているのかなあ。
こういうのはやめてもらいたいと思わない?
こういう底辺な現場からおさらばして10年以上になるけど、
まだこういう現場は残っているのだろうか。
まあif以下の文で複文でない場合も{}で囲むことなんてルールは、
あってもなくてもさほど害がないルールではあると思うけどもね。
境界はどの辺にあるんだろうね。
107:デフォルトの名無しさん
07/03/10 03:52:37
＞関数名・変数名は紙ベースの台帳管理で関数はfxxxx変数はvxxxx(xxxxは数字)とか、
これは実際に見るまでなかなか信じがたかったが、ホントにやってるとこあるのな。
漏れが見たのはJavaでの開発だった。
108:デフォルトの名無しさん
07/03/10 03:59:39
>>77
QB登場以前のBASICかよ。
109:デフォルトの名無しさん
07/03/10 04:05:35
C++/Java/C#使いのみんなに聞きたい。
自動変数のスコープを限定するためだけの{}使うよな。な。
仕事で使ったら、「この意味不明な{}は何なのか説明しる」って同僚に詰め寄られたんだが……。
110:デフォルトの名無しさん
07/03/10 04:38:07
>109
俺も使うことはある。特にC言語や、１つのメソッドが大きくなる時は。
ただ、Javaであまり必要に感じたことは無い。
privateメソッド複数作って、処理分けちゃうことが多いかな。
111:デフォルトの名無しさん
07/03/10 04:39:32
>>109
漏れはけっこう使う。
int n;
{
// 一時的な変数なんかも使って n を初期化するコード
}
// n を使うコード
とか。
書いてみて思ったより長かったらそのまま別の関数にするけど。
112:デフォルトの名無しさん
07/03/10 04:56:00
>>107
そういう職場ってそのうち慣れますか？
それともとっとと逃げ出すのが正解ですか？
113:デフォルトの名無しさん
07/03/10 05:00:10
>>112
そこに骨を埋めるつもりならがんばって慣れないと。
いずれ他所へ行くつもりなら慣れちゃったら後が大変そう。
114:デフォルトの名無しさん
07/03/10 05:08:38
……後者を選ぶことにします
115:デフォルトの名無しさん
07/03/10 05:55:22
>>110
そうしたくなったときというのは、
そこで関数を分けるべき時だと思っているので、
ほとんどの場合は括りだして別の関数に仕立て上げちゃう。
もちろんほんのちょっとスコープを限定したいというときは、
その限りでないけど。
116:デフォルトの名無しさん
07/03/10 05:58:01
>>107
それをやっているところはコボラーが仕切っていると考えてほぼ間違いないです。
あいつらオブジェクトがどうのとかいう以前に関数をわける利点とか、
もっと以前にわかりやすい名前をつけるとかスコープとかいうことを知らん。
117:デフォルトの名無しさん
07/03/10 06:34:15
このスレおもすれえ
118:デフォルトの名無しさん
07/03/10 06:36:52
>116
しょうがないじゃん、COBOLの仕様にはグローバル変数と
引数の無いサブルーチンしか無いんだから…
119:デフォルトの名無しさん
07/03/10 07:01:39
うざい上司にはインデントで訴えかけるに限る
hoge.each do |foo, bar|
fuga
piyo
hogera
end
piyo
hoge.to_a.each do |foo,bar|
foo
poi; bar; poi
qwe; end
120:デフォルトの名無しさん
07/03/10 08:11:08
>>94 >>108 30年以上前かららしいから、そんなところでしょう。
COBOLで IF CC EQUAL DD PERFORM YY ELSE PERFORM ZZ. の名残だと思う。
テスト、デバックがこの方がやりやすいからというのが積極的な理由。
ただしbreakする時が大変。
121:デフォルトの名無しさん
07/03/10 10:11:27
URLﾘﾝｸ(www.mono-project.com)
2つ目のgoodがbadだぜ
122:デフォルトの名無しさん
07/03/10 12:04:17
Coding Guideline であって Coding Convention じゃないんだな。
それくらい大きなオープンソースプロジェクトともなると、規約にしたところで従わない奴が続出するんだろうな。
123:デフォルトの名無しさん
07/03/10 12:09:05
厳密にやろうとするなら、コミット前にチェックして(subversionなら
pre-commitフック、CVSだとcommitinfoか?)、従ってなければコミット
させないなんてトコもありそう。
124:デフォルトの名無しさん
07/03/10 12:18:09
そこまでして関数名はf+数字を強制とかイヤすぎるなｗ
125:デフォルトの名無しさん
07/03/10 12:31:50
JavaやC++で省略する奴とは仕事しない
126:デフォルトの名無しさん
07/03/10 12:36:39
C++は省略しても普通だよね。
127:デフォルトの名無しさん
07/03/10 12:38:07
if(flag) break;
128:デフォルトの名無しさん
07/03/10 12:40:31
if(x)
/* 何らかの処理 */;
って書くとうっかりしやすいけど、
if(x) /* 何らかの処理 */;
って必ず一行に収める習慣にすれば大丈夫な気がする。
129:デフォルトの名無しさん
07/03/10 12:47:07
if(x) 何らかの処理1; 何らかの処理2;
と書く人がでてきちゃう。
130:デフォルトの名無しさん
07/03/10 12:48:34
そもそもブロックなしのifに一行追加して、ブロック付け忘れてハマったなんて経験がない。
131:デフォルトの名無しさん
07/03/10 12:51:29
御意
132:デフォルトの名無しさん
07/03/10 12:58:06
>>129
「;」で区切って一行にいくつも文を書く人にはお勧めできない。
133:デフォルトの名無しさん
07/03/10 13:28:01
if(cond) i = f(), j = g();
自分一人の開発ならこういうこともする。
読み間違えるとかありえない。
134:デフォルトの名無しさん
07/03/10 13:29:32
無能コーダーにぐだぐだコーディング規則を語られるのウザいから
ソースはIDEが自動整形してくれ。
135:デフォルトの名無しさん
07/03/10 13:45:22
括弧も自動で付けてくれるコードフォーマッタある？
136:デフォルトの名無しさん
07/03/10 13:45:33
>>130
if(cond) {
hoge();
fuga();
}
を
if(cond)
hoge();
にしようとした形跡のあるコードで
if(cond)
hoge();
fugafuga();
と、インデントそのままでブレースだけとられたコードではめられた事がある。
じっさいにはもうちょっと長いんだけど。
137:デフォルトの名無しさん
07/03/10 13:47:01
if(cond) {
hoge();
fuga();
}
と
if(cond)
hoge();
fugafuga();
にしようとしたコードで
if(cond)
hoge();
fugafuga();
とね（ちくせう空白つめんな）
138:デフォルトの名無しさん
07/03/10 13:49:17
>>135
ない
139:デフォルトの名無しさん
07/03/10 13:52:23
お前ら省略って言うけど、Cの場合本来ifの文法は
if( 条件 ) 文;
だよな？
でもこれだけじゃ機能不足で、複数の文を置きたいから{ }でブロックにするんだよな？
由来とかはどうでもいいし俺も{ }は必ずつける派だけどな？
140:デフォルトの名無しさん
07/03/10 14:22:20
>>139
確かに。
でもなんて表現したらいいんだろ？
141:デフォルトの名無しさん
07/03/10 14:29:26
実績ある有名なソフトでも、普通に省略してあるんで、品質には関係ない部分だとは思うけどな。
142:デフォルトの名無しさん
07/03/10 14:44:58
>>139
惜しい
if (式) 文
だ。最後にセミコロンはいらない。
143:デフォルトの名無しさん
07/03/10 14:58:45
>>141
そもそも品質はテストによって担保するものでコーディングスタイルに依存するものではない。
ただ、よいコーディングスタイルであればミスを未然に防ぎやすいというだけのこと。
144:デフォルトの名無しさん
07/03/10 15:03:38
そもそもスレタイの70%の根拠は何だ!
145:デフォルトの名無しさん
07/03/10 15:12:06
>>144
そんなんどうせ >>1 の経験からのなんとなくだろ。
そんなのいちいち気にしてたら負けだ。
146:デフォルトの名無しさん
07/03/10 15:18:05
だけど、
if(condition)
f1();
f2();
というコードに
if(condition)
f1();
f3();
f2();
なんて付け加えるプログラマっているか?
147:146
07/03/10 15:20:34
タブでなくスペースで送ってしまった。
>>146 は無かったことに。
148:デフォルトの名無しさん
07/03/10 15:20:36
>>146
なにがいいたいのかよくわからん。必要応じて を使ってくれんか？
149:デフォルトの名無しさん
07/03/10 15:27:40
>>143
だから、{}を省略してもミスとは関係ないって判断してるんだろ?
有名ソフトで{}を省略するスタイルの人たちは。
150:デフォルトの名無しさん
07/03/10 15:33:07
一人の天才で組んでるならともかく馬鹿と仕事するときは
馬鹿のレベルに合わせなきゃいけないんだよ
151:デフォルトの名無しさん
07/03/10 15:34:10
>>149
有名ソフトでそうしているからっていう判断はあんまり感心せんな。
152:デフォルトの名無しさん
07/03/10 15:36:50
>>150
短期的にはそれは認めるけど、今のこの業界は馬鹿を馬鹿のまま放置しすぎ。
153:デフォルトの名無しさん
07/03/10 16:05:16
向上心が無いからバカ
154:デフォルトの名無しさん
07/03/10 16:23:46
>>151
自分の経験も加えて。
2chのななしよりの意見より、実際に成果を出してるやつのスタイルのほうが参考になる。
155:デフォルトの名無しさん
07/03/10 16:27:33
有名ソフトや書籍でも、省略する派としない派がある。
ようは、たいして重要じゃないってことだろ。
156:デフォルトの名無しさん
07/03/10 17:48:19
う～ん、おそらくループ変数なんかのためでしょうし、
そのほうが安全そうですが、そういうソースは見たことないです。
157:デフォルトの名無しさん
07/03/10 19:51:17
>>1が70％の確率で{}省略でトラブルという告白スレ
158:デフォルトの名無しさん
07/03/10 23:43:29
>>155
逆だろ
派閥が分かれるってことは懸案事項だってこと
159:デフォルトの名無しさん
07/03/10 23:48:25
結論
コーディング規則を語るのは最下層の乞食コーダだけ。
160:デフォルトの名無しさん
07/03/11 00:08:58
奴隷につなぐ鎖の強度を語るのはいずれ管理へ回る前途ある者
それを理解できない159は、奴隷以下の乞食か動物
161:デフォルトの名無しさん
07/03/11 00:15:19
奴隷をつなぐ鎖なんて強度が十分であれば何を持ってきてもいい。
管理者はカタログから選んで持ってくればいいだけのこと。
鎖を再生産する管理者はバカ。
つながれてる鎖を自慢をする奴隷はマヌケ。
162:デフォルトの名無しさん
07/03/11 01:16:33
何の比喩なのか、わかったようでわからないレスだな。
163:デフォルトの名無しさん
07/03/11 01:18:14
わからないならレスしなくていいよ。
164:デフォルトの名無しさん
07/03/11 01:20:33
逆切れするくらいなら比喩なんか書くなよ
165:デフォルトの名無しさん
07/03/11 01:46:15
だそうだ。気をつけろよ>>160
166:デフォルトの名無しさん
07/03/11 02:01:40
>>165は>>160か。そんなにくやしかったのか？
167:160
07/03/11 02:06:05
悔しくなんてねーよ、バーカ
168:デフォルトの名無しさん
07/03/11 02:16:36
本物の160だけど、160以外のレスはつけてないけどね。
逆切れしたのはどいつだか知りたい。
あと、>>160の理由もね
169:デフォルトの名無しさん
07/03/11 02:17:55
＞あと、>>160の理由もね
まちがえた、
あと、>>165-166の理由もね
170:デフォルトの名無しさん
07/03/11 02:27:14
160必死だなｗｗｗｗ
171:デフォルトの名無しさん
07/03/11 03:58:07
だから｛｝でくくっておけばよかったんだ
172:デフォルトの名無しさん
07/03/11 05:47:17
int
hoge ( void ){
}
みたいなのもやめてほしいな。
173:デフォルトの名無しさん
07/03/11 05:52:03
括弧はともかく int と hoge の間の改行は正規表現で定義と使用が区別できるので vi 使いには便利。
174:デフォルトの名無しさん
07/03/11 08:34:51
正規表現なら別に改行でなくてもいいんでは。
175:デフォルトの名無しさん
07/03/11 08:48:19
>>174
vi使ってるときに、
/hoge で普通に検索
/^hoge で定義を検索
ていうことね。
176:デフォルトの名無しさん
07/03/11 11:34:46
IDE使えよ乞食
177:デフォルトの名無しさん
07/03/11 14:13:56
現実には戻りの型の方が関数名より長い事も多々あるからな。
intみたいな極端に短い物以外は改行で統一した方が見やすい。
178:デフォルトの名無しさん
07/03/11 14:21:09
いやそんなにないだろ
179:デフォルトの名無しさん
07/03/11 14:27:25
constもポインタも構造体もクラスもテンプレートも出てこないんですか。
APIやらライブラリ使ってりゃ長い名前の構造体なんていくらでもあるだろうに。
180:デフォルトの名無しさん
07/03/11 17:24:51
構造体なんか返すなよ
181:デフォルトの名無しさん
07/03/11 17:46:03
いくら長くても改行するほどじゃないな
というか、返す型情報まで含めてワンセットだから改行したくないなあ
182:デフォルトの名無しさん
07/03/11 17:49:24
BSD系のカーネルのソースなんかは改行する事になってるね。
style(9)あたりに書いてある。
183:デフォルトの名無しさん
07/03/11 18:19:02
>>180
３２ビット値２つとか３つの組は結構返すよ
184:デフォルトの名無しさん
07/03/11 18:50:28
>>158
どっちか片方に収束しないってことは、どっちでも大差ないんだよ。
どっちかが明らかによかったら、片方のスタイルは廃れてるだろ。
185:デフォルトの名無しさん
07/03/11 18:54:17
>>180はC使い
186:デフォルトの名無しさん
07/03/11 18:56:33
構造体自体を返さなくても、それを指すポインタ返せば記述は長くなりますやん。
187:デフォルトの名無しさん
07/03/11 18:59:02
>>185
C++でも同じだろ。
(スマートポインタで返すって手も使えるけど)
188:デフォルトの名無しさん
07/03/11 19:01:56
>>175
そんなん普通にコメントアウトでラベルつけときゃいいだけやん
189:デフォルトの名無しさん
07/03/11 19:03:41
>>188
意味わからん
190:デフォルトの名無しさん
07/03/11 19:30:28
>>189
int aho() /* teigi */
とかかな。
aho(); /* shiyou */
全部に書く気なんじゃない？
191:デフォルトの名無しさん
07/03/11 20:13:31
lint用のコメントみたいだなｗ
192:デフォルトの名無しさん
07/03/11 20:30:30
>>1
プログラマは信号は守るべきだが
小石を取り除くかどうかはプログラマしだいだ
尊敬するプログラマのソースを読め
193:デフォルトの名無しさん
07/03/11 20:35:44
>>192
尊敬するプログラマはみんな省略してませんでした
194:デフォルトの名無しさん
07/03/11 20:41:49
漏れその昔、ビル･アトキンソンをめちゃくちゃ尊敬してたが、
C系のコードは書いてたのかどうか知らん。
195:デフォルトの名無しさん
07/03/11 23:10:46
defineで閉じてるのは軽くいらっとさせるね
if () {
...
#if 1
} else
#endif
...
}
GNU関連は関数なんかもこれで閉じてくるよね
196:デフォルトの名無しさん
07/03/11 23:22:54
>>195
仕事でそんなコード書いてるヤツ見たら、思わずはり倒しちゃいそう。
197:デフォルトの名無しさん
07/03/12 00:32:13
return_type
func_name(
arg_type arg
)
{
}
はダメダメってことですね。
198:デフォルトの名無しさん
07/03/12 01:23:06
>>197
なんで？
199:デフォルトの名無しさん
07/03/12 01:47:52
つ >>172 >>177
200:デフォルトの名無しさん
07/03/12 02:07:20
>>197
俺はよくそのスタイルで書く衝動にかられるけど、
引数リストの行末がカンマで統一できないのが
嫌でいつも思いとどまる。
201:デフォルトの名無しさん
07/03/12 08:01:41
> 引数リストの行末がカンマで統一
そ、最後ね
arg_type1 arg1,
arg_type2 arg2,
arg_type3 arg3
最後のarg3だけカンマなしでないとエラー。よく引っかかる。
配列の初期化子は最後のカンマOKなのにね。
202:デフォルトの名無しさん
07/03/12 14:22:14
>>187
C++ 使ってると C の頃の感覚が麻痺して
抵抗なく string 返したりもできるようになる筈ｗ
203:デフォルトの名無しさん
07/03/12 15:09:03
オーバーヘッドなんて高が知れてるし、参照もポインタも使わずに
構造体やクラスを平気で返しちゃうぜ
204:デフォルトの名無しさん
07/03/12 20:35:18
C++クックブックって本は、コンテナクラスは 全部引数でやり取りしてた。
205:デフォルトの名無しさん
07/03/12 21:53:09
何でスレ伸びてるの？
206:デフォルトの名無しさん
07/03/12 23:23:25
>>76
それおまえさんが強要して出させたんじゃないか？
207:デフォルトの名無しさん
07/03/13 00:04:04
>>206
スレタイの数字の話じゃねえの？
208:デフォルトの名無しさん
07/03/13 01:41:45
ぶら下がりelseに起因するbug発生回数は一回
その他の中括弧の省略に起因するbug発生回数は零回
209:デフォルトの名無しさん
07/03/13 02:09:20
どんな書き方をしてもバグを生み出さないソースを書けばいいだけ
どんなにファクターがありそうでも最終的にそこに原因を求めるのは結局責任転嫁だ
210:デフォルトの名無しさん
07/03/13 02:10:42
読みやすい書き方はそれだけでバグの抑制になる
211:デフォルトの名無しさん
07/03/13 05:57:35
インクリメントとかシンプルな処理なら｛｝なんて使わなくても
使うのは数行に渡る見込みがあるか後々まで残す部分くらいだな
212:デフォルトの名無しさん
07/03/13 08:01:55
やはりbegin～endの勝利だな
213:デフォルトの名無しさん
07/03/13 09:26:05
Python最強ということで
214:デフォルトの名無しさん
07/03/13 09:35:13
schemeもええで
215:デフォルトの名無しさん
07/03/13 09:48:34
ソレより、 && || をif文中で使ってる場合の方が多いように思うけどな
特に俺が書いた時に無かったのに後から何気なく追加されたような場合、たいてい間違ってるゾ！
216:デフォルトの名無しさん
07/03/13 11:02:09
70%はそっちの方だね。
217:デフォルトの名無しさん
07/03/13 11:08:56
まだ && ||を２行に別けて書く人はミスが少ない気がする
if( ( hoge == hage )
&& ( hige ) ){
}
みたいに
218:デフォルトの名無しさん
07/03/13 11:12:50
こういうのは程度の問題で、複雑な式は分けて書いた方が理解しすいだろうが、
シンプルな式まで徹底して分ける事に決めちゃったりしたら、かえってコードの意図がわかりにくくなると思う。
{}の省略についても同様。
219:デフォルトの名無しさん
07/03/13 11:39:36
if修飾子が使える言語(PerlやRuby)だと、やることが1つなら修飾子にして
おいて、増えたら複文支配のifに書き換える、という使い分けが出来るな。
220:デフォルトの名無しさん
07/03/13 13:07:20
むしろ後置ifが使えるなら、
前置ifでの単文修飾は不可能にすべきじゃなかろうか。
221:デフォルトの名無しさん
07/03/13 13:16:18
perlはそうだね。
222:デフォルトの名無しさん
07/03/13 14:06:40
俺はPBP6.2の通りに後置ifはnext, last, redo, return, goto, die, croak, throwでのみ使うようにしてる。
メンテ不要な書き捨てプログラムはこの限りでないがw
223:デフォルトの名無しさん
07/03/13 22:45:43
if文より型の変換とか値入れてない変数とかの方がやばい気がする。
224:デフォルトの名無しさん
07/03/13 22:46:14
全ての分岐をgoto文で書いてやる
225:デフォルトの名無しさん
07/03/13 23:02:08
gotoが必要なのは多重ループを抜けるときだけだよな。
226:デフォルトの名無しさん
07/03/13 23:14:43
URLﾘﾝｸ(gedo-style.net)
227:デフォルトの名無しさん
07/03/14 00:27:29
多重ループは関数化で対処
228:デフォルトの名無しさん
07/03/14 04:07:30
gotoはエラー処理と字句解析のハードコード。
229:デフォルトの名無しさん
07/03/14 04:48:53
if()
{
;
}
↑これは異端か？
230:デフォルトの名無しさん
07/03/14 05:29:00
異端もクソも、なぜ if() の中を ! で否定しないよ
231:デフォルトの名無しさん
07/03/14 06:53:59
頭ごなしに否定するのはよくない
232:デフォルトの名無しさん
07/03/14 10:31:18
ケツで否定してやる。
{ ; } unless hoge;
233:デフォルトの名無しさん
07/03/14 10:41:26
{ } を付けたら女の子にもてるようになりました
234:デフォルトの名無しさん
07/03/14 17:09:17
スーパー括弧閉じ
235:デフォルトの名無しさん
07/03/14 17:26:03
括弧閉じはコッカって言わないか？
236:デフォルトの名無しさん
07/03/14 19:21:20
通じるけど恥ずかしいから自分では言わない。
237:デフォルトの名無しさん
07/03/15 16:12:21
>>235
それは局所的にしか通じないだろう。
238:デフォルトの名無しさん
07/03/15 16:57:00
sh 系だとそんなだよな。
esac ってなんだろと。
239:デフォルトの名無しさん
07/03/15 17:06:36
fi はまあ想像つくけどなｗ
240:デフォルトの名無しさん
07/03/16 22:54:36
言語規格の中で if() ; 形を if() { ; } の省略形であるとしている
言語はどんなものがありますか。
241:デフォルトの名無しさん
07/03/16 23:11:15
そんなのあるのか？
242:デフォルトの名無しさん
07/03/17 13:24:53
お前らエディタのソース整形機能とか使ったことなさそうだな
243:デフォルトの名無しさん
07/03/17 13:25:18
COBOLにそんな機能ねーよ
244:デフォルトの名無しさん
07/03/17 13:43:26
ソース整形が必要なほどのクソコードに出会ったら
とりあえず腹をくくることにしている。
245:デフォルトの名無しさん
07/03/17 13:51:37
おまえはソース整形について誤った観念を抱いているのではないか
246:デフォルトの名無しさん
07/03/17 13:52:38
ソーッスねぇ
247:デフォルトの名無しさん
07/03/17 14:27:11
ソース整形したらテスト全部やり直しなんだけどそれついてはどうなの？
248:デフォルトの名無しさん
07/03/17 14:29:25
>>247
なんで？
249:デフォルトの名無しさん
07/03/17 14:33:05
>>248
あ？遊びでやってんじゃねーんだぞ
250:デフォルトの名無しさん
07/03/17 14:34:46
>>247
kwsk
251:デフォルトの名無しさん
07/03/17 14:37:04
バイナリがかわんなきゃよくね？
or
テストケース再実行すりゃいいじゃん
好きなほうで
252:デフォルトの名無しさん
07/03/17 14:40:18
テストする前に整形すればいいだけじゃん
253:デフォルトの名無しさん
07/03/17 14:41:43
リポジトリにコミットするとき、自動的にソース整形すりゃよくね？も追加
254:デフォルトの名無しさん
07/03/17 14:45:04
>>247は自動化したテストですらとんでもなく時間を食う
ちょー大規模プロジェクトをやってるんだろう。
255:デフォルトの名無しさん
07/03/17 14:49:30
>>251
＞バイナリがかわんなきゃよくね？
これは納得できる
＞テストケース再実行すりゃいいじゃん
手動のテストケースもあるから無理
仮に全自動であったとしても時間無駄にしてんじゃねーよ
>>252
ソース整形しただけの個所までテストするのが時間の無駄
>>253
改行した瞬間に自動的にソース整形するVBが最適解か……orz
256:デフォルトの名無しさん
07/03/17 14:53:35
やはりpythonが・・・
257:デフォルトの名無しさん
07/03/17 14:54:49
>>255
時間かかるテストは、夜走らせとけよ
エディタorIDE
↓
リポジトリ(コミット時にソース整形)
↓
CI(夜間に自動ビルド＋テスト)
これ大抵の言語でいけるだろ。
258:デフォルトの名無しさん
07/03/17 16:57:26
バイナリが変わるようなコード変換はもはや整形じゃないと思う
259:デフォルトの名無しさん
07/03/18 01:12:11
>>175
そんなの^(unsigned)*[int|char|short|float|double] [a-Z]+[0-9|a-Z]*\(とかで検索すればいいんじゃね？
260:デフォルトの名無しさん
07/03/18 01:20:04
無理やりこうやればできるとかいう話じゃなくってさ。
viでは検索が日常的なカーソル移動手段のひとつなんだよ。
261:デフォルトの名無しさん
07/03/18 01:34:57
>>259
ぜんぜんだめ。おはなしにならない。
262:デフォルトの名無しさん
07/03/18 01:51:22
C言語は文脈自由文法だから正規表現で完璧にマッチさせるのは不可能
263:デフォルトの名無しさん
07/03/18 05:35:27
>>262 こういう話疎いので、初心者にも解るように解説してください。
264:デフォルトの名無しさん
07/03/18 07:02:14
>>263
コンパイラの本でも嫁
265:デフォルトの名無しさん
07/03/18 11:30:39
突然舞い上がったようなレスだな。>>262は
そもそもどのレスに依存するのだろう。
266:デフォルトの名無しさん
07/03/18 11:33:56
259のあたりだろ。
267:デフォルトの名無しさん
07/03/18 11:41:31
>>265が>>262を全く理解できなかったということだけはわかった。
268:デフォルトの名無しさん
07/03/18 11:50:27
まあ規約ガチガチなのはそのせいだしな
269:デフォルトの名無しさん
07/03/18 13:40:30
正規表現に疎い俺に>>173はどういう正規表現を書いているのか教えて欲しい。
270:デフォルトの名無しさん
07/03/18 13:49:32
そこらじゅうに未定義・未規定・処理系依存が
ぽっかり口をあけているC言語のどの辺がガチガチ？
271:デフォルトの名無しさん
07/03/18 14:23:15
コーディング規約でガチガチにするって意味だよ
272:263
07/03/18 18:26:20
そんな連関、聞いたこと無いけどな。
273:デフォルトの名無しさん
07/03/18 19:16:41
>>263
かっこが自由に無制限に入れ子に出来るパターンは
正規表現じゃ理論上無理らしいよ
274:デフォルトの名無しさん
07/03/18 20:28:25
正規文法と文脈自由文法でぐぐってみ
275:デフォルトの名無しさん
07/03/18 20:33:57
正規文法は a is b のルール．
線形構造しか表現できない．
A→B→C
A is B.
B is C.
文脈自由文法は a is b and c のルール．
木構造を表現できる．
A┬B
└C┬D
└E
A is B and C.
C is D and E.
そういうこっちゃ．
276:デフォルトの名無しさん
07/03/18 21:01:57
だかPerlとかの変態拡張性器表現ならきっと・・・
277:デフォルトの名無しさん
07/03/18 21:11:13
Perlのは正規表現の中でPerlのコードを評価できたりするからある意味万能
278:デフォルトの名無しさん
07/03/19 00:02:33
つまりゲストのお客さんが自由に参加すると収拾がつかなくなるので、
レギュラーのメンツだけでやってくれ、というわけですね。
279:デフォルトの名無しさん
07/03/19 05:52:30
結構前の話題だが
俺は例えば if なら
if(式) 文;
文が一行で、かつこの行が長くならない場合だけ { } を使わずに書くかなぁ。
if(式)
文;
と書くぐらいならブレースを使ってる。
280:デフォルトの名無しさん
07/03/19 07:18:05
条件文がすげー長かったら？
やっぱ１行でもブロックにする？
281:デフォルトの名無しさん
07/03/19 07:27:01
条件式を関数なりマクロなりに分けて良い感じの名前を付ければおけ。
そういう時ローカル関数使える言語だといいんだけどな。
282:デフォルトの名無しさん
07/03/19 08:29:05
ローカル関数は欲しいねえ・・
283:デフォルトの名無しさん
07/03/19 08:35:21
C++;なら関数内で定義したクラス/構造体のメソッドで代用出来るけどな
284:デフォルトの名無しさん
07/03/19 08:44:43
無理やりそんなことしても読みにくくなるだけだろ。
読みやすくすることが目的なのに。
285:279
07/03/19 20:21:25
>280
うん。条件が長い時もブレースにする。
もしくは条件式の閉じ括弧を実行文の行に持ってくる。
これなら俺は間違えない。集団ならやらんけど。
if(
条件式
) 実行文;
BASICで育ったんで一行IF／ブロックIFが基本、
長い時はブロック化するかこうしてたからなー。
IF ～ _
THEN 実行文
286:デフォルトの名無しさん
07/04/03 13:47:00
自分所のコーディングルールは、
if (式) 文1つ ;
if (式) {
複数の文
}
のいずれか片方のみ可。
287:デフォルトの名無しさん
07/04/03 14:34:40
ルール作るなら、常にブロック使えやコラにした方が良くね？
288:デフォルトの名無しさん
07/04/03 14:35:55
ガチガチだと読みにくくなるよ・・・
289:デフォルトの名無しさん
07/04/03 14:49:39
if (式)
{
・・・
}
これに統一すると美しい
290:デフォルトの名無しさん
07/04/03 14:58:54
主観
291:デフォルトの名無しさん
07/04/11 06:53:45
>>289
自分には美しく見えない。
変数のスコープのために、
{
何か
{
何か
}
何か
}
という書き方をする場合があるので、
if (式)
{
何か
}
という書き方を許してしまうと、{ が現われたとき、
if (式)
{
何か
}
という可能性を考えて、前方向をチェックしなくてはならない。
if (式) {
何か
}
というように同じ行に書くように強制すれば、見てすぐにわかる。
if (式) と { が生き別れになってしまうこともない。
292:デフォルトの名無しさん
07/04/11 11:19:49
そんなのは、常に整形ツール使えって事でいいじゃないか。
そのルールが気に入らない場合は、自分が読む時に整形しなおせばいい。
そして、読み終わったら元に戻すと。
293:デフォルトの名無しさん
07/04/11 11:36:07
よっぽどものすごい書き方してなきゃだいたい読めるし、
書くときはまわりに合わせりゃそれでいいじゃないの。
こんなのが原因でトラブるやつは他の原因でもっとトラブるよ。
294:デフォルトの名無しさん
07/04/11 12:55:21
>>291
つ[c++ or c99]
295:デフォルトの名無しさん
07/04/11 14:17:17
TCLではブレース次行じゃダメなんだよな
296:デフォルトの名無しさん
07/04/11 22:35:26
>>295
そうなのか。
あれは、それぞれがシェルコマンドみたいなもんだからな。
297:デフォルトの名無しさん
07/04/12 19:54:03
Tclは改行した時括弧の中じゃなかったら
そこでバッサリ文末になるからな
298:デフォルトの名無しさん
07/04/12 20:55:47
Rubyは、改行したところまでで文が成立する場合は次の行は別の文扱いだな。
二項演算式の途中とか対応するカッコを閉じる前のような、文が未完結である
ことがわかる場合は途中改行ができる。完結しているように見える場合は、
¥を付けて明示的に継続する必要がある。
299:デフォルトの名無しさん
07/04/12 23:55:43
セミコロンが文の終わり、にしときゃ良かったと思うんだけど
なんでそんなにも ; なくしたかったのかな？
300:デフォルトの名無しさん
07/04/13 00:57:43
毎回行末記号書くよりも、必要な時だけ継続記号使った方が手間がかからないという思想だろう。
301:デフォルトの名無しさん
07/04/13 01:16:58
>299
俺は逆に
何でわざわざ毎回行末を書かなきゃいけないんだ？
行末は普通文末だろ？
と思うぞ。
結局、普段使ってる言語の影響が強いんだと思う。
Lisperは文末どころか文の始まりまで毎回書くんだもんな…凄いと思う。
302:デフォルトの名無しさん
07/04/13 09:50:40
Ruby慣れると、C書くとき早速セミコロンを忘れる。
無いほうが自然なんだな、と実感する
303:デフォルトの名無しさん
07/04/13 10:13:04
文脈によらずに継続行書くときは常に\つける方が好み。
304:デフォルトの名無しさん
07/04/13 11:38:37
おまいらFORTRANやCOBOLの時代に逆戻りだな・・・
305:デフォルトの名無しさん
07/04/13 14:28:13
>304
むしろ、その時代はカラム制限があったから
セミコロン文末の方が利点が多かったろうに
ある程度のカラムが扱えるなら継続行のみ明示で良いと思うぞ
どうせそんな滅茶苦茶長い行書かないし
…ああ、C言語は使うAPIによっちゃ長い行が普通になるのか
306:デフォルトの名無しさん
07/04/13 19:18:25
>>301
Lisperにはカッコは見えていないし意識して入力もしてないｗ
307:デフォルトの名無しさん
07/04/13 19:56:09
>306
そういうモノなのかｗ
他言語の人（俺含）から見れば大量の括弧の方が目につくんだがな～
308:デフォルトの名無しさん
07/04/13 20:56:19
>>307
begin endが目につくpascalとか
:-が目につくprologとか
{}が目につくCとか
<>が目につくXMLとか
309:デフォルトの名無しさん
07/04/13 21:57:00
インデントしてたらそんなに目に付くもんでもないんじゃない？
310:デフォルトの名無しさん
07/04/14 01:53:45
セミコロンなしで行末で文末としてしまうと、
class hoge { どわーーー}
という具合に1行に書かないといけなくなりますぞ。
311:デフォルトの名無しさん
07/04/14 09:42:14
どわーーーでなぜか和んだ。
312:デフォルトの名無しさん
07/04/14 09:43:53
>310
そういう言語は
・閉じ括弧が少ない場合はブロックが継続する
・構文でブロックを示すからendが来るまでブロックが継続する
のどちらかを備えてるだろ普通。
Tclは前者。
BASICやCOBOLは後者。
Rubyは両方使ってるな。
Pythonはインデントでブロックを示すんだっけ？
313:デフォルトの名無しさん
07/04/14 12:12:36
Pythonはインデントでブロックを表してて、両方だな。
314:デフォルトの名無しさん
07/04/16 22:57:37
途中から良スレになってる気がした
315:デフォルトの名無しさん
07/04/17 04:31:02
気のせいだった
316:デフォルトの名無しさん
07/08/31 11:46:07
age
317:デフォルトの名無しさん
07/09/01 15:23:25
かの有名なカーニハン先生も省略するべきでないと仰っているよ。
318:デフォルトの名無しさん
07/09/01 15:33:26
蟹飯がナンボのもんじゃーい！
319:デフォルトの名無しさん
07/09/01 17:16:33
>>317
K&R、省略しまくりじゃん。
320:デフォルトの名無しさん
07/09/02 06:09:15
俺はC→JAVA→C++→C#と勉強してきたから
コードブロックよりもセミコロンがない言語が苦手だな
321:デフォルトの名無しさん
07/09/02 18:34:19
セミコロンは文の区切りです。
322:デフォルトの名無しさん
07/09/02 21:58:20
同じセミコロンでもデリミタとして使う言語とターミネータとして使う言語があるのよん。
323:デフォルトの名無しさん
07/09/02 23:07:25
Pascalは文の最後はピリオドだったな。
324:デフォルトの名無しさん
07/09/03 00:46:44
pascal は
○ if a then b else c;
× if a then b; else c; (コンパイルエラー)
Cはどっちも大丈夫
325:デフォルトの名無しさん
07/09/03 01:18:28
Cはどっちも怒られそうだぞ
326:デフォルトの名無しさん
07/09/03 13:06:03
カッコが付かないな
327:デフォルトの名無しさん
07/12/31 03:42:45
Pascalの場合、elseはif文の一部で
セミコロン付けると、そこでif文が終わるから
「文頭にelseはおかしい」って言われるんだよね。
328:デフォルトの名無しさん
08/03/05 17:00:17
c でも else は if 文の一部。
; が文同士のセパレータではなく文の終端記号でしかないから、
b; が 1 文となって問題にならない、ってこと。
329:デフォルトの名無しさん
08/03/15 16:13:12
>>323
プログラムの最後だろ？
330:デフォルトの名無しさん
08/05/04 13:30:52
>>1
COBOLのIF文の歴史を知らないんだな。
331:デフォルトの名無しさん
08/05/06 17:30:21
内容（意味）によらず形式だけで決める
>>1の考え方が危険なだけ
332:デフォルトの名無しさん
08/05/06 17:42:39
人いたんだ。
333:デフォルトの名無しさん
08/06/25 14:44:13
>>331
形式で決められるものは、決めればいい。
その分、考えないといけないことに頭のリソースを配分しようぜ。
334:デフォルトの名無しさん
08/06/29 01:35:51
ブラを付ける自由もあれば、付けない自由もある。
女性はブラジャーの着用を義務付けるという法律が
制定できないのと同じ。
ブラは時には非常に邪魔になる。
形式では決めることができないものは意外に多い。
335:デフォルトの名無しさん
08/06/29 02:50:06
そもそも、
Windowsのメモ帳にたくさん毛が生えたようなテキストエディタを使ってコードを書く
という時点で、おかしいだろ。
336:デフォルトの名無しさん
08/06/30 18:35:16
C#なら言語仕様で{}を強制してたとしても不思議ではないね
switch内のbreakは強制だっけ
337:デフォルトの名無しさん
08/06/30 22:41:09
{} を強制するなら elseif キーワードが必要
338:デフォルトの名無しさん
08/07/01 03:21:06
ブラを強制するのなら、elseの禁止も合わせてやったほうが良いかも？
よくね～よw。
なるべくブラ着用。elseの多用は可愛気がないぜ。といったところ。
339:デフォルトの名無しさん
08/07/01 04:43:44
コーディングするためのユーザインタフェースが、
事故を未然に防ぐべく何かするのが第一だろ
いつまでも
紙に鉛筆でプログラムを書くレベルに留まるな
340:デフォルトの名無しさん
08/07/27 00:00:15
>337
なぜに?
341:デフォルトの名無しさん
08/07/27 02:59:30
elseifがないと
if () {
} else {
if () {
} else {
if () {
} else {
if () {
} else {
}
}
}
}
みたいにどんどんネストが深くなる。
342:デフォルトの名無しさん
08/07/27 03:00:38
{} を省略できるなら
if () {
} else if () {
} else if () {
} else if () {
} else {
}
みたいに書けるんだけど
343:デフォルトの名無しさん
08/07/27 03:06:05
強制する←→省略不可だからそういうのも認めないって話じゃねーの。
344:デフォルトの名無しさん
08/07/27 03:27:46
というか、>>1の主張を強制するのならelse ifという慣用表現も禁止で
>>341みたいにきちんとif文をネストするような表現とすることを
強制するべき。
>>342式を禁止するというか非推奨にするのは、それなりに根拠がある。
多くの場合、>>342の形式の場合、ロジックが練れていなく、
バグが多い割に修正が難しいから。経験的に言って>>341式のほう
が、バグも少なくなり、バグが出ても修正しやすいような気がする。
結論的に言えば>>342式を禁止するのは一定の意味を持つが
>>1を強制するのはやり過ぎかも。
345:デフォルトの名無しさん
08/07/27 04:11:17
>>342禁止ですら、行き過ぎという感があるのに
>>1強制なんてあり得ない
346:デフォルトの名無しさん
08/07/27 13:36:09
なる。
それなら俺は {} 強制で else if 容認かな。
自分のバグ元としては {}なしのif より 比較に = 使っちゃう方が多いけど。
だから、エディタで[^><=]=[^=] を赤くなるようにしてる。
347:デフォルトの名無しさん
08/07/28 15:32:25
caseで
348:デフォルトの名無しさん
08/07/28 17:42:41
多くの場合、経験的に言って、根拠があると言っているわりに>>344は主観推論しか言っていない気がする。
349:デフォルトの名無しさん
08/07/28 21:13:28
case式が強力な言語ならいいんだけどCだと定数との比較しかできない
350:デフォルトの名無しさん
08/08/04 12:32:49
>>342のようなコードってさ、
if (A) { い
} else if (B) { ろ
} else if (C) { は
} else { に
}
ってさ、
if (A) { い }
if (!A && B) { ろ }
if (!A && !B && C) {は}
if (!A && !B && !C) {に}
ということなんだけど、その条件が分散して書かれているから、わかりにくいのよね。
ただのswitch-case的な使い方だと誤解して順序を変えてしまうと、意味が変ってしまう。
351:デフォルトの名無しさん
08/10/01 23:41:42
if(id == typeA && ){}
else if (id == typeB &&){}
って書く奴いるけどなんでswitch文使わないの
バカなのねぇバカなの？
352:デフォルトの名無しさん
08/10/02 09:16:07
>>351
妙な && が気になるが、if で書けば
・コードの行数が少なくて済むので見やすい
・スコープがしっかり認識できて良い
・シンタックスハイラトや自動インデントなど IDE によっては switch の対応が微妙
・if の方がコンパイラが最適化しやすい条件になっている
とかとか。分かってて書いている人なら、別に良いと思うけど？
353:デフォルトの名無しさん
08/10/02 22:17:54
if(id == typeA)
if(id == typeB)
と
if(id == typeA)
else if(id == typeB)
同じ意味だよね？
354:デフォルトの名無しさん
08/10/03 01:40:46
>>353
if (id == typeA) {
...
id = typeHoge;
}
の場合は？
355:デフォルトの名無しさん
08/10/06 12:06:12
>>353
idがconstなら同じ。そうでないなら、>354の可能性がある。
例えば、この関数では全く同じ。
void func(const int id)
{
if (id == typeA) {
funcA();
}
if (id == typeB) {
funcB();
}
}
356:デフォルトの名無しさん
08/10/06 12:18:01
つか、同じじゃないように見えるんだけど？
if(id == typeA)
if(id == typeB)
って、インデント付けると
if(id == typeA)
if(id == typeB)
だよな？ 更に括弧も付けると
if(id == typeA) {
if(id == typeB) {
}
}
だよな？
357:デフォルトの名無しさん
08/10/06 13:00:09
>>356
>353が>351を踏まえて書いたかどうかだな。
>353が>351を踏まえずに>356の意味で書いたのだとしたら、
if (id == typeA) if (id == typeB)
は(typeAとtypeBが等しいと言う無謀な前提を仮定しない限り)
if (0)と同じになってしまう。
358:デフォルトの名無しさん
08/10/07 18:07:30
べつに無謀な前提ではないんじゃないか
typeA != typeBでもid == typeAかつid == typeBだったりすると怖いけど
359:デフォルトの名無しさん
08/10/09 12:42:52
>>358
この流れでその前提は、余りに阿呆過ぎる。
最早>351も>353もいないから真意は不明だが。