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もいないから真意は不明だが。