[表示 : 全て 最新50 1-99 101- 201- 301- 2chのread.cgiへ]
Update time : 09/18 12:25 / Filesize : 67 KB / Number-of Response : 360
[このスレッドの書き込みを削除する]
[+板 最近立ったスレ&熱いスレ一覧 : +板 最近立ったスレ/記者別一覧] [類似スレッド一覧]


↑キャッシュ検索、類似スレ動作を修正しました、ご迷惑をお掛けしました

コーディングトラブルの約70%はif文などでの{}省略



1 名前:デフォルトの名無しさん mailto:sage [2007/03/09(金) 14:02:01 ]
自分は1行しか書かないつもりでも
あとでコードを足さなければならない事態なんていくらでもやってくる。
他人がきちんと中括弧補ってくれるかどうかはわからない。

1行文だろうがなんだろうが
最初から中括弧をつけるクセをつけろ

187 名前:デフォルトの名無しさん mailto:sage [2007/03/11(日) 18:59:02 ]
>>185
C++でも同じだろ。
(スマートポインタで返すって手も使えるけど)

188 名前:デフォルトの名無しさん mailto:sage [2007/03/11(日) 19:01:56 ]
>>175
そんなん普通にコメントアウトでラベルつけときゃいいだけやん

189 名前:デフォルトの名無しさん mailto:sage [2007/03/11(日) 19:03:41 ]
>>188
意味わからん

190 名前:デフォルトの名無しさん mailto:sage [2007/03/11(日) 19:30:28 ]
>>189
int aho() /* teigi */
とかかな。
aho(); /* shiyou */

全部に書く気なんじゃない?

191 名前:デフォルトの名無しさん mailto:sage [2007/03/11(日) 20:13:31 ]
lint用のコメントみたいだなw

192 名前:デフォルトの名無しさん mailto:sage [2007/03/11(日) 20:30:30 ]
>>1
プログラマは信号は守るべきだが
小石を取り除くかどうかはプログラマしだいだ
尊敬するプログラマのソースを読め

193 名前:デフォルトの名無しさん mailto:sage [2007/03/11(日) 20:35:44 ]
>>192
尊敬するプログラマはみんな省略してませんでした

194 名前:デフォルトの名無しさん mailto:sage [2007/03/11(日) 20:41:49 ]
漏れその昔、ビル・アトキンソンをめちゃくちゃ尊敬してたが、
C系のコードは書いてたのかどうか知らん。

195 名前:デフォルトの名無しさん mailto:sage [2007/03/11(日) 23:10:46 ]
defineで閉じてるのは軽くいらっとさせるね
if () {
...
#if 1
} else
#endif
...

}
GNU関連は関数なんかもこれで閉じてくるよね






196 名前:デフォルトの名無しさん mailto:sage [2007/03/11(日) 23:22:54 ]
>>195
仕事でそんなコード書いてるヤツ見たら、思わずはり倒しちゃいそう。

197 名前:デフォルトの名無しさん mailto:sage [2007/03/12(月) 00:32:13 ]
return_type
func_name(
 arg_type arg
)
{
}
はダメダメってことですね。

198 名前:デフォルトの名無しさん mailto:sage [2007/03/12(月) 01:23:06 ]
>>197
なんで?

199 名前:デフォルトの名無しさん mailto:sage [2007/03/12(月) 01:47:52 ]
>>172 >>177

200 名前:デフォルトの名無しさん mailto:sage [2007/03/12(月) 02:07:20 ]
>>197
俺はよくそのスタイルで書く衝動にかられるけど、
引数リストの行末がカンマで統一できないのが
嫌でいつも思いとどまる。

201 名前:デフォルトの名無しさん mailto:sage [2007/03/12(月) 08:01:41 ]
> 引数リストの行末がカンマで統一
そ、最後ね

arg_type1 arg1,
arg_type2 arg2,
arg_type3 arg3

最後のarg3だけカンマなしでないとエラー。よく引っかかる。
配列の初期化子は最後のカンマOKなのにね。

202 名前:デフォルトの名無しさん mailto:sage [2007/03/12(月) 14:22:14 ]
>>187
C++ 使ってると C の頃の感覚が麻痺して
抵抗なく string 返したりもできるようになる筈w

203 名前:デフォルトの名無しさん mailto:sage [2007/03/12(月) 15:09:03 ]
オーバーヘッドなんて高が知れてるし、参照もポインタも使わずに
構造体やクラスを平気で返しちゃうぜ

204 名前:デフォルトの名無しさん mailto:sage [2007/03/12(月) 20:35:18 ]
C++クックブックって本は、コンテナクラスは 全部引数でやり取りしてた。

205 名前:デフォルトの名無しさん mailto:sage [2007/03/12(月) 21:53:09 ]
何でスレ伸びてるの?



206 名前:デフォルトの名無しさん [2007/03/12(月) 23:23:25 ]
>>76
それおまえさんが強要して出させたんじゃないか?

207 名前:デフォルトの名無しさん mailto:sage [2007/03/13(火) 00:04:04 ]
>>206
スレタイの数字の話じゃねえの?

208 名前:デフォルトの名無しさん mailto:sage [2007/03/13(火) 01:41:45 ]
ぶら下がりelseに起因するbug発生回数は一回
その他の中括弧の省略に起因するbug発生回数は零回

209 名前:デフォルトの名無しさん mailto:sage [2007/03/13(火) 02:09:20 ]
どんな書き方をしてもバグを生み出さないソースを書けばいいだけ
どんなにファクターがありそうでも最終的にそこに原因を求めるのは結局責任転嫁だ

210 名前:デフォルトの名無しさん mailto:sage [2007/03/13(火) 02:10:42 ]
読みやすい書き方はそれだけでバグの抑制になる

211 名前:デフォルトの名無しさん mailto:sage [2007/03/13(火) 05:57:35 ]
インクリメントとかシンプルな処理なら{}なんて使わなくても
使うのは数行に渡る見込みがあるか後々まで残す部分くらいだな

212 名前:デフォルトの名無しさん [2007/03/13(火) 08:01:55 ]
やはりbegin〜endの勝利だな

213 名前:デフォルトの名無しさん mailto:sage [2007/03/13(火) 09:26:05 ]
Python最強ということで

214 名前:デフォルトの名無しさん mailto:sage [2007/03/13(火) 09:35:13 ]
schemeもええで

215 名前:デフォルトの名無しさん mailto:sage [2007/03/13(火) 09:48:34 ]
ソレより、 && || をif文中で使ってる場合の方が多いように思うけどな

特に俺が書いた時に無かったのに後から何気なく追加されたような場合、たいてい間違ってるゾ!



216 名前:デフォルトの名無しさん mailto:sage [2007/03/13(火) 11:02:09 ]
70%はそっちの方だね。

217 名前:デフォルトの名無しさん mailto:sage [2007/03/13(火) 11:08:56 ]
まだ && ||を2行に別けて書く人はミスが少ない気がする

if( ( hoge == hage )
&& ( hige ) ){
}
みたいに

218 名前:デフォルトの名無しさん mailto:sage [2007/03/13(火) 11:12:50 ]
こういうのは程度の問題で、複雑な式は分けて書いた方が理解しすいだろうが、
シンプルな式まで徹底して分ける事に決めちゃったりしたら、かえってコードの意図がわかりにくくなると思う。
{}の省略についても同様。

219 名前:デフォルトの名無しさん mailto:sage [2007/03/13(火) 11:39:36 ]
if修飾子が使える言語(PerlやRuby)だと、やることが1つなら修飾子にして
おいて、増えたら複文支配のifに書き換える、という使い分けが出来るな。


220 名前:デフォルトの名無しさん mailto:sage [2007/03/13(火) 13:07:20 ]
むしろ後置ifが使えるなら、
前置ifでの単文修飾は不可能にすべきじゃなかろうか。

221 名前:デフォルトの名無しさん mailto:sage [2007/03/13(火) 13:16:18 ]
perlはそうだね。

222 名前:デフォルトの名無しさん mailto:sage [2007/03/13(火) 14:06:40 ]
俺はPBP6.2の通りに後置ifはnext, last, redo, return, goto, die, croak, throwでのみ使うようにしてる。
メンテ不要な書き捨てプログラムはこの限りでないがw

223 名前:デフォルトの名無しさん mailto:sage [2007/03/13(火) 22:45:43 ]
if文より型の変換とか値入れてない変数とかの方がやばい気がする。

224 名前:デフォルトの名無しさん mailto:sage [2007/03/13(火) 22:46:14 ]
全ての分岐をgoto文で書いてやる

225 名前:デフォルトの名無しさん mailto:sage [2007/03/13(火) 23:02:08 ]
gotoが必要なのは多重ループを抜けるときだけだよな。



226 名前:デフォルトの名無しさん mailto:sage [2007/03/13(火) 23:14:43 ]
ttp://gedo-style.net/g/?v=361721&d=d.jpg

227 名前:デフォルトの名無しさん mailto:sage [2007/03/14(水) 00:27:29 ]
多重ループは関数化で対処

228 名前:デフォルトの名無しさん mailto:sage [2007/03/14(水) 04:07:30 ]
gotoはエラー処理と字句解析のハードコード。

229 名前:デフォルトの名無しさん mailto:sage [2007/03/14(水) 04:48:53 ]
if()
{
;
}

↑これは異端か?

230 名前:デフォルトの名無しさん mailto:sage [2007/03/14(水) 05:29:00 ]
異端もクソも、なぜ if() の中を ! で否定しないよ

231 名前:デフォルトの名無しさん mailto:sage [2007/03/14(水) 06:53:59 ]
頭ごなしに否定するのはよくない

232 名前:デフォルトの名無しさん mailto:sage [2007/03/14(水) 10:31:18 ]
ケツで否定してやる。

{ ; } unless hoge;

233 名前:デフォルトの名無しさん mailto:sage [2007/03/14(水) 10:41:26 ]
{ } を付けたら女の子にもてるようになりました

234 名前:デフォルトの名無しさん mailto:sage [2007/03/14(水) 17:09:17 ]
スーパー括弧閉じ


235 名前:デフォルトの名無しさん mailto:sage [2007/03/14(水) 17:26:03 ]
括弧閉じはコッカって言わないか?



236 名前:デフォルトの名無しさん mailto:sage [2007/03/14(水) 19:21:20 ]
通じるけど恥ずかしいから自分では言わない。

237 名前:デフォルトの名無しさん mailto:sage [2007/03/15(木) 16:12:21 ]
>>235
それは局所的にしか通じないだろう。

238 名前:デフォルトの名無しさん mailto:sage [2007/03/15(木) 16:57:00 ]
sh 系だとそんなだよな。

esac ってなんだろと。

239 名前:デフォルトの名無しさん mailto:sage [2007/03/15(木) 17:06:36 ]
fi はまあ想像つくけどなw

240 名前:デフォルトの名無しさん mailto:sage [2007/03/16(金) 22:54:36 ]
言語規格の中で if() ; 形を if() { ; } の省略形であるとしている
言語はどんなものがありますか。

241 名前:デフォルトの名無しさん mailto:sage [2007/03/16(金) 23:11:15 ]
そんなのあるのか?

242 名前:デフォルトの名無しさん mailto:sage [2007/03/17(土) 13:24:53 ]
お前らエディタのソース整形機能とか使ったことなさそうだな

243 名前:デフォルトの名無しさん mailto:sage [2007/03/17(土) 13:25:18 ]
COBOLにそんな機能ねーよ

244 名前:デフォルトの名無しさん mailto:sage [2007/03/17(土) 13:43:26 ]
ソース整形が必要なほどのクソコードに出会ったら
とりあえず腹をくくることにしている。

245 名前:デフォルトの名無しさん mailto:sage [2007/03/17(土) 13:51:37 ]
おまえはソース整形について誤った観念を抱いているのではないか



246 名前:デフォルトの名無しさん mailto:sage [2007/03/17(土) 13:52:38 ]
ソーッスねぇ

247 名前:デフォルトの名無しさん mailto:sage [2007/03/17(土) 14:27:11 ]
ソース整形したらテスト全部やり直しなんだけどそれついてはどうなの?

248 名前:デフォルトの名無しさん mailto:sage [2007/03/17(土) 14:29:25 ]
>>247
なんで?

249 名前:デフォルトの名無しさん mailto:sage [2007/03/17(土) 14:33:05 ]
>>248
あ?遊びでやってんじゃねーんだぞ

250 名前:デフォルトの名無しさん mailto:sage [2007/03/17(土) 14:34:46 ]
>>247
kwsk

251 名前:デフォルトの名無しさん mailto:sage [2007/03/17(土) 14:37:04 ]
バイナリがかわんなきゃよくね?
or
テストケース再実行すりゃいいじゃん

好きなほうで

252 名前:デフォルトの名無しさん mailto:sage [2007/03/17(土) 14:40:18 ]
テストする前に整形すればいいだけじゃん

253 名前:デフォルトの名無しさん mailto:sage [2007/03/17(土) 14:41:43 ]
リポジトリにコミットするとき、自動的にソース整形すりゃよくね?も追加

254 名前:デフォルトの名無しさん mailto:sage [2007/03/17(土) 14:45:04 ]
>>247は自動化したテストですらとんでもなく時間を食う
ちょー大規模プロジェクトをやってるんだろう。


255 名前:デフォルトの名無しさん mailto:sage [2007/03/17(土) 14:49:30 ]
>>251
>バイナリがかわんなきゃよくね?
これは納得できる

>テストケース再実行すりゃいいじゃん
手動のテストケースもあるから無理
仮に全自動であったとしても時間無駄にしてんじゃねーよ

>>252
ソース整形しただけの個所までテストするのが時間の無駄

>>253
改行した瞬間に自動的にソース整形するVBが最適解か……orz



256 名前:デフォルトの名無しさん mailto:sage [2007/03/17(土) 14:53:35 ]
やはりpythonが・・・

257 名前:デフォルトの名無しさん mailto:sage [2007/03/17(土) 14:54:49 ]
>>255
時間かかるテストは、夜走らせとけよ

エディタorIDE

リポジトリ(コミット時にソース整形)

CI(夜間に自動ビルド+テスト)

これ大抵の言語でいけるだろ。

258 名前:デフォルトの名無しさん mailto:sage [2007/03/17(土) 16:57:26 ]
バイナリが変わるようなコード変換はもはや整形じゃないと思う

259 名前:デフォルトの名無しさん mailto:sage [2007/03/18(日) 01:12:11 ]
>>175
そんなの^(unsigned)*[int|char|short|float|double] [a-Z]+[0-9|a-Z]*\(とかで検索すればいいんじゃね?


260 名前:デフォルトの名無しさん mailto:sage [2007/03/18(日) 01:20:04 ]
無理やりこうやればできるとかいう話じゃなくってさ。
viでは検索が日常的なカーソル移動手段のひとつなんだよ。

261 名前:デフォルトの名無しさん mailto:sage [2007/03/18(日) 01:34:57 ]
>>259
ぜんぜんだめ。おはなしにならない。

262 名前:デフォルトの名無しさん mailto:sage [2007/03/18(日) 01:51:22 ]
C言語は文脈自由文法だから正規表現で完璧にマッチさせるのは不可能

263 名前:デフォルトの名無しさん mailto:sage [2007/03/18(日) 05:35:27 ]
>>262 こういう話疎いので、初心者にも解るように解説してください。

264 名前:デフォルトの名無しさん mailto:sage [2007/03/18(日) 07:02:14 ]
>>263
コンパイラの本でも嫁

265 名前:デフォルトの名無しさん mailto:sage [2007/03/18(日) 11:30:39 ]
突然舞い上がったようなレスだな。>>262
そもそもどのレスに依存するのだろう。



266 名前:デフォルトの名無しさん mailto:sage [2007/03/18(日) 11:33:56 ]
259のあたりだろ。

267 名前:デフォルトの名無しさん mailto:sage [2007/03/18(日) 11:41:31 ]
>>265>>262を全く理解できなかったということだけはわかった。

268 名前:デフォルトの名無しさん mailto:sage [2007/03/18(日) 11:50:27 ]
まあ規約ガチガチなのはそのせいだしな

269 名前:デフォルトの名無しさん mailto:sage [2007/03/18(日) 13:40:30 ]
正規表現に疎い俺に>>173はどういう正規表現を書いているのか教えて欲しい。

270 名前:デフォルトの名無しさん mailto:sage [2007/03/18(日) 13:49:32 ]
そこらじゅうに未定義・未規定・処理系依存が
ぽっかり口をあけているC言語のどの辺がガチガチ?

271 名前:デフォルトの名無しさん mailto:sage [2007/03/18(日) 14:23:15 ]
コーディング規約でガチガチにするって意味だよ

272 名前:263 mailto:sage [2007/03/18(日) 18:26:20 ]
そんな連関、聞いたこと無いけどな。

273 名前:デフォルトの名無しさん mailto:sage [2007/03/18(日) 19:16:41 ]
>>263
かっこが自由に無制限に入れ子に出来るパターンは
正規表現じゃ理論上無理らしいよ

274 名前:デフォルトの名無しさん mailto:sage [2007/03/18(日) 20:28:25 ]
正規文法と文脈自由文法でぐぐってみ

275 名前:デフォルトの名無しさん mailto:sage [2007/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 名前:デフォルトの名無しさん mailto:sage [2007/03/18(日) 21:01:57 ]
だかPerlとかの変態拡張性器表現ならきっと・・・

277 名前:デフォルトの名無しさん mailto:sage [2007/03/18(日) 21:11:13 ]
Perlのは正規表現の中でPerlのコードを評価できたりするからある意味万能

278 名前:デフォルトの名無しさん mailto:sage [2007/03/19(月) 00:02:33 ]
つまりゲストのお客さんが自由に参加すると収拾がつかなくなるので、
レギュラーのメンツだけでやってくれ、というわけですね。

279 名前:デフォルトの名無しさん mailto:sage [2007/03/19(月) 05:52:30 ]
結構前の話題だが

俺は例えば if なら
if(式) 文;
文が一行で、かつこの行が長くならない場合だけ { } を使わずに書くかなぁ。
if(式)
  文;
と書くぐらいならブレースを使ってる。

280 名前:デフォルトの名無しさん mailto:sage [2007/03/19(月) 07:18:05 ]
条件文がすげー長かったら?
やっぱ1行でもブロックにする?

281 名前:デフォルトの名無しさん mailto:sage [2007/03/19(月) 07:27:01 ]
条件式を関数なりマクロなりに分けて良い感じの名前を付ければおけ。
そういう時ローカル関数使える言語だといいんだけどな。

282 名前:デフォルトの名無しさん mailto:sage [2007/03/19(月) 08:29:05 ]
ローカル関数は欲しいねえ・・

283 名前:デフォルトの名無しさん mailto:sage [2007/03/19(月) 08:35:21 ]
C++;なら関数内で定義したクラス/構造体のメソッドで代用出来るけどな

284 名前:デフォルトの名無しさん mailto:sage [2007/03/19(月) 08:44:43 ]
無理やりそんなことしても読みにくくなるだけだろ。
読みやすくすることが目的なのに。

285 名前:279 mailto:sage [2007/03/19(月) 20:21:25 ]
>280
うん。条件が長い時もブレースにする。
もしくは条件式の閉じ括弧を実行文の行に持ってくる。
これなら俺は間違えない。集団ならやらんけど。

if(
  条件式
) 実行文;

BASICで育ったんで一行IF/ブロックIFが基本、
長い時はブロック化するかこうしてたからなー。
IF 〜 _
THEN 実行文



286 名前:デフォルトの名無しさん mailto:sage [2007/04/03(火) 13:47:00 ]
自分所のコーディングルールは、

if (式) 文1つ ;

if (式) {
複数の文
}

のいずれか片方のみ可。


287 名前:デフォルトの名無しさん mailto:sage [2007/04/03(火) 14:34:40 ]
ルール作るなら、常にブロック使えやコラにした方が良くね?

288 名前:デフォルトの名無しさん mailto:sage [2007/04/03(火) 14:35:55 ]
ガチガチだと読みにくくなるよ・・・

289 名前:デフォルトの名無しさん mailto:sage [2007/04/03(火) 14:49:39 ]
if (式)
{
 ・・・
}

これに統一すると美しい

290 名前:デフォルトの名無しさん mailto:sage [2007/04/03(火) 14:58:54 ]
主観

291 名前:デフォルトの名無しさん mailto:sage [2007/04/11(水) 06:53:45 ]
>>289
自分には美しく見えない。

変数のスコープのために、
{
何か
{
何か
}
何か
}
という書き方をする場合があるので、
if (式)
{
何か
}
という書き方を許してしまうと、{ が現われたとき、
if (式)


{
何か
}
という可能性を考えて、前方向をチェックしなくてはならない。
if (式) {
何か
}
というように同じ行に書くように強制すれば、見てすぐにわかる。
if (式) と { が生き別れになってしまうこともない。

292 名前:デフォルトの名無しさん mailto:sage [2007/04/11(水) 11:19:49 ]
そんなのは、常に整形ツール使えって事でいいじゃないか。

そのルールが気に入らない場合は、自分が読む時に整形しなおせばいい。
そして、読み終わったら元に戻すと。

293 名前:デフォルトの名無しさん mailto:sage [2007/04/11(水) 11:36:07 ]
よっぽどものすごい書き方してなきゃだいたい読めるし、
書くときはまわりに合わせりゃそれでいいじゃないの。
こんなのが原因でトラブるやつは他の原因でもっとトラブるよ。

294 名前:デフォルトの名無しさん mailto:sage [2007/04/11(水) 12:55:21 ]
>>291
つ[c++ or c99]

295 名前:デフォルトの名無しさん mailto:sage [2007/04/11(水) 14:17:17 ]
TCLではブレース次行じゃダメなんだよな



296 名前:デフォルトの名無しさん mailto:sage [2007/04/11(水) 22:35:26 ]
>>295
そうなのか。
あれは、それぞれがシェルコマンドみたいなもんだからな。


297 名前:デフォルトの名無しさん mailto:sage [2007/04/12(木) 19:54:03 ]
Tclは改行した時括弧の中じゃなかったら
そこでバッサリ文末になるからな

298 名前:デフォルトの名無しさん mailto:sage [2007/04/12(木) 20:55:47 ]
Rubyは、改行したところまでで文が成立する場合は次の行は別の文扱いだな。

二項演算式の途中とか対応するカッコを閉じる前のような、文が未完結である
ことがわかる場合は途中改行ができる。完結しているように見える場合は、
¥を付けて明示的に継続する必要がある。


299 名前:デフォルトの名無しさん mailto:sage [2007/04/12(木) 23:55:43 ]
セミコロンが文の終わり、にしときゃ良かったと思うんだけど
なんでそんなにも ; なくしたかったのかな?

300 名前:デフォルトの名無しさん mailto:sage [2007/04/13(金) 00:57:43 ]
毎回行末記号書くよりも、必要な時だけ継続記号使った方が手間がかからないという思想だろう。

301 名前:デフォルトの名無しさん mailto:sage [2007/04/13(金) 01:16:58 ]
>299
俺は逆に

何でわざわざ毎回行末を書かなきゃいけないんだ?
行末は普通文末だろ?

と思うぞ。
結局、普段使ってる言語の影響が強いんだと思う。

Lisperは文末どころか文の始まりまで毎回書くんだもんな…凄いと思う。

302 名前:デフォルトの名無しさん mailto:sage [2007/04/13(金) 09:50:40 ]
Ruby慣れると、C書くとき早速セミコロンを忘れる。
無いほうが自然なんだな、と実感する

303 名前:デフォルトの名無しさん mailto:sage [2007/04/13(金) 10:13:04 ]
文脈によらずに継続行書くときは常に\つける方が好み。

304 名前:デフォルトの名無しさん mailto:sage [2007/04/13(金) 11:38:37 ]
おまいらFORTRANやCOBOLの時代に逆戻りだな・・・

305 名前:デフォルトの名無しさん mailto:sage [2007/04/13(金) 14:28:13 ]
>304
むしろ、その時代はカラム制限があったから
セミコロン文末の方が利点が多かったろうに
ある程度のカラムが扱えるなら継続行のみ明示で良いと思うぞ
どうせそんな滅茶苦茶長い行書かないし

…ああ、C言語は使うAPIによっちゃ長い行が普通になるのか



306 名前:デフォルトの名無しさん mailto:sage [2007/04/13(金) 19:18:25 ]
>>301
Lisperにはカッコは見えていないし意識して入力もしてないw

307 名前:デフォルトの名無しさん mailto:sage [2007/04/13(金) 19:56:09 ]
>306
そういうモノなのかw
他言語の人(俺含)から見れば大量の括弧の方が目につくんだがな〜

308 名前:デフォルトの名無しさん mailto:sage [2007/04/13(金) 20:56:19 ]
>>307
begin endが目につくpascalとか
:-が目につくprologとか
{}が目につくCとか
<>が目につくXMLとか

309 名前:デフォルトの名無しさん mailto:sage [2007/04/13(金) 21:57:00 ]
インデントしてたらそんなに目に付くもんでもないんじゃない?

310 名前:デフォルトの名無しさん mailto:sage [2007/04/14(土) 01:53:45 ]
セミコロンなしで行末で文末としてしまうと、

class hoge { どわーーー}
という具合に1行に書かないといけなくなりますぞ。

311 名前:デフォルトの名無しさん mailto:sage [2007/04/14(土) 09:42:14 ]
どわーーーでなぜか和んだ。


312 名前:デフォルトの名無しさん mailto:sage [2007/04/14(土) 09:43:53 ]
>310
そういう言語は
・閉じ括弧が少ない場合はブロックが継続する
・構文でブロックを示すからendが来るまでブロックが継続する
のどちらかを備えてるだろ普通。

Tclは前者。
BASICやCOBOLは後者。
Rubyは両方使ってるな。
Pythonはインデントでブロックを示すんだっけ?

313 名前:デフォルトの名無しさん mailto:sage [2007/04/14(土) 12:12:36 ]
Pythonはインデントでブロックを表してて、両方だな。

314 名前:デフォルトの名無しさん mailto:sage [2007/04/16(月) 22:57:37 ]
途中から良スレになってる気がした

315 名前:デフォルトの名無しさん mailto:sage [2007/04/17(火) 04:31:02 ]
気のせいだった



316 名前:デフォルトの名無しさん mailto:age [2007/08/31(金) 11:46:07 ]
age

317 名前:デフォルトの名無しさん [2007/09/01(土) 15:23:25 ]
かの有名なカーニハン先生も省略するべきでないと仰っているよ。

318 名前:デフォルトの名無しさん mailto:sage [2007/09/01(土) 15:33:26 ]
蟹飯がナンボのもんじゃーい!

319 名前:デフォルトの名無しさん mailto:sage [2007/09/01(土) 17:16:33 ]
>>317
K&R、省略しまくりじゃん。

320 名前:デフォルトの名無しさん mailto:sage [2007/09/02(日) 06:09:15 ]
俺はC→JAVA→C++→C#と勉強してきたから
コードブロックよりもセミコロンがない言語が苦手だな

321 名前:デフォルトの名無しさん mailto:sage [2007/09/02(日) 18:34:19 ]
セミコロンは文の区切りです。

322 名前:デフォルトの名無しさん mailto:sage [2007/09/02(日) 21:58:20 ]
同じセミコロンでもデリミタとして使う言語とターミネータとして使う言語があるのよん。

323 名前:デフォルトの名無しさん mailto:sage [2007/09/02(日) 23:07:25 ]
Pascalは文の最後はピリオドだったな。


324 名前:デフォルトの名無しさん mailto:sage [2007/09/03(月) 00:46:44 ]
pascal は
○ if a then b else c;
× if a then b; else c; (コンパイルエラー)
Cはどっちも大丈夫

325 名前:デフォルトの名無しさん mailto:sage [2007/09/03(月) 01:18:28 ]
Cはどっちも怒られそうだぞ



326 名前:デフォルトの名無しさん mailto:sage [2007/09/03(月) 13:06:03 ]
カッコが付かないな

327 名前:デフォルトの名無しさん mailto:sage [2007/12/31(月) 03:42:45 ]
Pascalの場合、elseはif文の一部で
セミコロン付けると、そこでif文が終わるから
「文頭にelseはおかしい」って言われるんだよね。

328 名前:デフォルトの名無しさん mailto:sage [2008/03/05(水) 17:00:17 ]
c でも else は if 文の一部。

; が文同士のセパレータではなく文の終端記号でしかないから、
b; が 1 文となって問題にならない、ってこと。

329 名前:デフォルトの名無しさん mailto:sage [2008/03/15(土) 16:13:12 ]
>>323
プログラムの最後だろ?

330 名前:デフォルトの名無しさん mailto:sage [2008/05/04(日) 13:30:52 ]
>>1
COBOLのIF文の歴史を知らないんだな。

331 名前:デフォルトの名無しさん mailto:sage [2008/05/06(火) 17:30:21 ]
内容(意味)によらず形式だけで決める
>>1の考え方が危険なだけ



332 名前:デフォルトの名無しさん [2008/05/06(火) 17:42:39 ]
人いたんだ。

333 名前:デフォルトの名無しさん mailto:sage [2008/06/25(水) 14:44:13 ]
>>331
形式で決められるものは、決めればいい。
その分、考えないといけないことに頭のリソースを配分しようぜ。

334 名前:デフォルトの名無しさん mailto:sage [2008/06/29(日) 01:35:51 ]
ブラを付ける自由もあれば、付けない自由もある。
女性はブラジャーの着用を義務付けるという法律が
制定できないのと同じ。
ブラは時には非常に邪魔になる。
形式では決めることができないものは意外に多い。

335 名前:デフォルトの名無しさん mailto:sage [2008/06/29(日) 02:50:06 ]
そもそも、
Windowsのメモ帳にたくさん毛が生えたようなテキストエディタを使ってコードを書く
という時点で、おかしいだろ。




336 名前:デフォルトの名無しさん mailto:sage [2008/06/30(月) 18:35:16 ]
C#なら言語仕様で{}を強制してたとしても不思議ではないね
switch内のbreakは強制だっけ

337 名前:デフォルトの名無しさん mailto:sage [2008/06/30(月) 22:41:09 ]
{} を強制するなら elseif キーワードが必要

338 名前:デフォルトの名無しさん mailto:sage [2008/07/01(火) 03:21:06 ]
ブラを強制するのなら、elseの禁止も合わせてやったほうが良いかも?

よくね〜よw。
なるべくブラ着用。elseの多用は可愛気がないぜ。といったところ。

339 名前:デフォルトの名無しさん mailto:sage [2008/07/01(火) 04:43:44 ]
コーディングするためのユーザインタフェースが、
事故を未然に防ぐべく何かするのが第一だろ

いつまでも
紙に鉛筆でプログラムを書くレベルに留まるな

340 名前:デフォルトの名無しさん mailto:sage [2008/07/27(日) 00:00:15 ]
>337
なぜに?

341 名前:デフォルトの名無しさん mailto:sage [2008/07/27(日) 02:59:30 ]
elseifがないと
if () {
} else {
 if () {
 } else {
  if () {
  } else {
   if () {
   } else {
   }
  }
 }
}
みたいにどんどんネストが深くなる。

342 名前:デフォルトの名無しさん mailto:sage [2008/07/27(日) 03:00:38 ]
{} を省略できるなら
if () {
} else if () {
} else if () {
} else if () {
} else {
}
みたいに書けるんだけど

343 名前:デフォルトの名無しさん mailto:sage [2008/07/27(日) 03:06:05 ]
強制する←→省略不可だからそういうのも認めないって話じゃねーの。

344 名前:デフォルトの名無しさん mailto:sage [2008/07/27(日) 03:27:46 ]
というか、>>1の主張を強制するのならelse ifという慣用表現も禁止で
>>341みたいにきちんとif文をネストするような表現とすることを
強制するべき。
>>342式を禁止するというか非推奨にするのは、それなりに根拠がある。
多くの場合、>>342の形式の場合、ロジックが練れていなく、
バグが多い割に修正が難しいから。経験的に言って>>341式のほう
が、バグも少なくなり、バグが出ても修正しやすいような気がする。
結論的に言えば>>342式を禁止するのは一定の意味を持つが
>>1を強制するのはやり過ぎかも。

345 名前:デフォルトの名無しさん mailto:sage [2008/07/27(日) 04:11:17 ]
>>342禁止ですら、行き過ぎという感があるのに
>>1強制なんてあり得ない



346 名前:デフォルトの名無しさん mailto:sage [2008/07/27(日) 13:36:09 ]
なる。
それなら俺は {} 強制で else if 容認かな。

自分のバグ元としては {}なしのif より 比較に = 使っちゃう方が多いけど。
だから、エディタで[^><=]=[^=] を赤くなるようにしてる。

347 名前:デフォルトの名無しさん mailto:sage [2008/07/28(月) 15:32:25 ]
caseで

348 名前:デフォルトの名無しさん mailto:sage [2008/07/28(月) 17:42:41 ]
多くの場合、経験的に言って、根拠があると言っているわりに>>344は主観推論しか言っていない気がする。

349 名前:デフォルトの名無しさん mailto:sage [2008/07/28(月) 21:13:28 ]
case式が強力な言語ならいいんだけどCだと定数との比較しかできない

350 名前:デフォルトの名無しさん mailto:sage [2008/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 名前:デフォルトの名無しさん mailto:sage [2008/10/01(水) 23:41:42 ]
if(id == typeA && ){}
else if (id == typeB &&){}

って書く奴いるけどなんでswitch文使わないの
バカなのねぇバカなの?

352 名前:デフォルトの名無しさん mailto:sage [2008/10/02(木) 09:16:07 ]
>>351
妙な && が気になるが、if で書けば
・コードの行数が少なくて済むので見やすい
・スコープがしっかり認識できて良い
・シンタックスハイラトや自動インデントなど IDE によっては switch の対応が微妙
・if の方がコンパイラが最適化しやすい条件になっている
とかとか。分かってて書いている人なら、別に良いと思うけど?

353 名前:デフォルトの名無しさん mailto:sage [2008/10/02(木) 22:17:54 ]
if(id == typeA)
if(id == typeB)

if(id == typeA)
else if(id == typeB)
同じ意味だよね?


354 名前:デフォルトの名無しさん mailto:sage [2008/10/03(金) 01:40:46 ]
>>353
if (id == typeA) {
...
id = typeHoge;
}
の場合は?



355 名前:デフォルトの名無しさん mailto:sage [2008/10/06(月) 12:06:12 ]
>>353
idがconstなら同じ。そうでないなら、>354の可能性がある。
例えば、この関数では全く同じ。
void func(const int id)
{
if (id == typeA) {
funcA();
}
if (id == typeB) {
funcB();
}
}



356 名前:デフォルトの名無しさん mailto:sage [2008/10/06(月) 12:18:01 ]
つか、同じじゃないように見えるんだけど?

if(id == typeA)
if(id == typeB)
って、インデント付けると
if(id == typeA)
 if(id == typeB)
だよな? 更に括弧も付けると
if(id == typeA) {
 if(id == typeB) {
 }
}
だよな?

357 名前:デフォルトの名無しさん mailto:sage [2008/10/06(月) 13:00:09 ]
>>356
>353が>351を踏まえて書いたかどうかだな。
>353が>351を踏まえずに>356の意味で書いたのだとしたら、
if (id == typeA) if (id == typeB)
は(typeAとtypeBが等しいと言う無謀な前提を仮定しない限り)
if (0)と同じになってしまう。

358 名前:デフォルトの名無しさん mailto:sage [2008/10/07(火) 18:07:30 ]
べつに無謀な前提ではないんじゃないか
typeA != typeBでもid == typeAかつid == typeBだったりすると怖いけど

359 名前:デフォルトの名無しさん mailto:sage [2008/10/09(木) 12:42:52 ]
>>358
この流れでその前提は、余りに阿呆過ぎる。
最早>351も>353もいないから真意は不明だが。






[ 新着レスの取得/表示 (agate) ] / [ 携帯版 ]

前100 次100 最新50 [ このスレをブックマーク! 携帯に送る ] 2chのread.cgiへ
[+板 最近立ったスレ&熱いスレ一覧 : +板 最近立ったスレ/記者別一覧](*・∀・)<67KB

read.cgi ver5.27 [feat.BBS2 +1.6] / e.0.2 (02/09/03) / eucaly.net products.
担当:undef