トップページ⇒tech
408コメント99KB

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

■ このスレッドは過去ログ倉庫に格納されています
0001デフォルトの名無しさん2007/03/09(金) 14:02:01
自分は1行しか書かないつもりでも
あとでコードを足さなければならない事態なんていくらでもやってくる。
他人がきちんと中括弧補ってくれるかどうかはわからない。

1行文だろうがなんだろうが
最初から中括弧をつけるクセをつけろ
0002デフォルトの名無しさん2007/03/09(金) 14:09:42
>>1
禿同!!
0003デフォルトの名無しさん2007/03/09(金) 14:15:37
>>2
自演乙!!
0004デフォルトの名無しさん2007/03/09(金) 14:25:56
アンケートとったんですか？
アンケートに答える暇がある人にのみ聞いたんですか？
0005デフォルトの名無しさん2007/03/09(金) 14:35:17
>>4はVB使い
0006デフォルトの名無しさん2007/03/09(金) 14:47:19
自分ひとりで書くときはつけないが、人と組むときはつけることにしてるな。
0007デフォルトの名無しさん2007/03/09(金) 14:53:32
同じく。
でも自分が信用できないので最近は１行でも書くようにしてる。
今のところ（自分一人で使う範囲でも）
このおかげでバグが出たことはないけど。
0008デフォルトの名無しさん2007/03/09(金) 15:14:17
>>6
スクリプトでポイポイ使い捨てのつもりで書いた物とかならともかく。
自分一人の時でもコーディング規約を適用するとそれほど縛りを感じないけどな。
むしろコーディング規約ナシで書いて半年後に眺めた日には泣ける。

規約があると、その規約を適用していた時のコードを振り返るときも楽だし。
0009デフォルトの名無しさん2007/03/09(金) 15:35:12
そんなん明らかに実行結果違うでしょ。
コーディング後テスト出来ずに、すぐにリリースしなくてはならない環境だったり
中括弧の後の追加文が検証しにくい環境であることの方が問題。
0010デフォルトの名無しさん2007/03/09(金) 16:26:38
　＿＿　　　　 ＿＿　　＿＿＿＿＿　　＿＿＿＿_　　　 　___　___　　 　___
　|　　 |　　　 /　　/　　/　　　　　　　|　/＿＿　　__/ [][] ＿|　|_|　|＿_　_|　|_
　| 　　|.　　 /　　/ 　 /　　 /￣￣|.　l　　　　/　/　　　　 |　　　 ＿　　| |_　　ﾚ'~￣|
　|　　 |　　/　　/　　 /　　 /.　　／　/　　　　|　 |___ 　 　　￣| 　|　/　/　/ 　 ／|　|
　|　　 |　 /　　/　 　/　　　￣￣　／　　　　　＼＿_|　　　　　| 　|　￣　/_　 /　　|　|_
　| 　　|. /　　/　　 /　　 /￣￣|　＼　　　 　　　　　　　　　 　|＿|　　　　 |__|　　　＼/
　|　　 |/　　/　 　/　　 /　　　 ｜　 |
　|.　　　　 /　 　 /　　 /　　　／　　/　　　　　　　　　　 　　　Powered By Visual Basic 6.0
　|　　　　/. 　　./　　 　￣￣　　／　http://pc8.2ch.net/test/read.cgi/prog/1155017860/
　￣￣￣　　　 ￣￣￣￣￣￣
0011デフォルトの名無しさん2007/03/09(金) 16:37:41
そもそも、そんなに入力めんどくさいモンじゃないじゃん
省略しないほうがメリット大なのに省略するやつって
インデントもグチャグチャなことが多い。

条件式も代入も全部インデントなしの位置で記述してたり
0012デフォルトの名無しさん2007/03/09(金) 16:53:06
いつも省略しないで書くから、｛｝省略しているコードが非常に読みづらい
省略している奴らはなんか美意識とかあんのかなぁ
0013デフォルトの名無しさん2007/03/09(金) 16:58:19
省略するだろ普通。
それだけ縦方向に圧縮できて情報量がふえる

インデントで対応するPythonやendをつけるRubyなんかはたしかにこの手の問題を意識してるのかな
0014デフォルトの名無しさん2007/03/09(金) 17:19:38
if文1つにつき1行そこらで情報量が増えるとか言われてもねえ
0015デフォルトの名無しさん2007/03/09(金) 17:48:07
>>1
俺も省略するが、それでトラブるのは莫迦だからじゃね？

>>13-14
そんな大層なもんじゃねえだろ。
0016デフォルトの名無しさん2007/03/09(金) 18:10:40
馬鹿な奴ほど、なんでも省略したがる傾向にあるんだよな。
頭のいい奴は省略なんてしねーよ。重要なのは省略じゃなく最適化だろうが。
中括弧の省略は可読性を低下させるだけの悪習だろ。
そんなにソースの情報量にこだわるのなら、空白文字類をすべて省けよ。
ま、中括弧をつけないことに美を感じるとか趣味だとかそういう理由なら何も言わんが。
好きにすればって感じ。
つうか、中括弧ごときで騒ぐ奴のほうがおかしいんじゃねーのとか思っちゃうけどね。
0017デフォルトの名無しさん2007/03/09(金) 19:21:37
開発ソフトでソース書けば全解決ではないのですか？
よくシリマセンガ！
0018デフォルトの名無しさん2007/03/09(金) 19:21:54
省略できてしまう文法が悪い。
宗教戦争起こるのは当然。
0019デフォルトの名無しさん2007/03/09(金) 19:22:38
ぜひともトラブルの７０％とかいうソースを出してもらいたい。
調査したの？
0020デフォルトの名無しさん2007/03/09(金) 19:36:53
これは大いに賛成
省略して何がうれしいのかと思う

自分はミスしない、と言うやつは一人で
コーディングして、一切ソースを人に見せない人なんだろう
0021デフォルトの名無しさん2007/03/09(金) 19:41:56
人間って、１０段階評価って出来ないですよね
0022デフォルトの名無しさん2007/03/09(金) 19:44:05
評価されたら１か２ばかりつけられちゃうじゃまいか
いやん
0023デフォルトの名無しさん2007/03/09(金) 19:44:11
まぁ、情報量増やしたい奴らは、改行しないでエディタの右端で折り返しとかすれば一度にみれる情報量一気にふえるじゃん

情報量というか、可読性とかをあげた方が最終的にはバグとか減って生産性も上がると思うんだがな。
0024デフォルトの名無しさん2007/03/09(金) 19:46:57
数値で評価といっても、結果的に、あるものとの比較による評価だよね。
0025デフォルトの名無しさん2007/03/09(金) 19:53:34
{}省略してる奴が
コメントアウトで//ああお腹すいた
とか書いてたりすると殺意を覚える
0026デフォルトの名無しさん2007/03/09(金) 20:03:41
このスレには少々驚いたな。一行の方が基本かと思ってた。
省略してると解釈するものか・・・。
0027デフォルトの名無しさん2007/03/09(金) 20:05:24
java言語すら存在しない時代のCの教育書には
>>1と同じことが書いてある
0028デフォルトの名無しさん2007/03/09(金) 20:11:28
これが原因でトラブルを起こすような奴がコードを書いてることが問題
0029デフォルトの名無しさん2007/03/09(金) 20:13:45
>>28
人間のミスのほとんどは、ケアレスミスだよ。
言い方を換えれば、ケアレスミスをしないですむ状況をつくればミスは減る。
0030デフォルトの名無しさん2007/03/09(金) 20:13:50
マ板でやれ。
0031デフォルトの名無しさん2007/03/09(金) 20:23:55
ケアレスミスを減らすために決まりを沢山作るよりも、
問題がすぐに発見/修正されるような仕組みを作ることが重要。
0032デフォルトの名無しさん2007/03/09(金) 21:33:23
取り敢えず一切省略しない。
エディタがifを入れたところでブレースを含めて展開してくれるから、面倒もない。
0033デフォルトの名無しさん2007/03/09(金) 21:34:48
俺は基本的に1行でも{}はつけるけどたまにつけない事もある。
つけない事が原因でバグが入った事は無い。
0034デフォルトの名無しさん2007/03/09(金) 21:38:20
{}無くてもインデント付けてりゃまず見逃さないだろ
0035デフォルトの名無しさん2007/03/09(金) 21:42:25
>>31
少なくとも省略して可読性を悪くする人間は失格ｄな
0036デフォルトの名無しさん2007/03/09(金) 21:45:05
省略を許してしまうような言語が悪い

俺は悪くない
0037デフォルトの名無しさん2007/03/09(金) 21:47:36
>>35
あんたにとって可読性が良いコードが万人にとって可読性が良いわけじゃないでしょ。
0038デフォルトの名無しさん2007/03/09(金) 21:54:09
>>37
{}を使った方が可読性が良いって流れなんだけどな
0039デフォルトの名無しさん2007/03/09(金) 21:55:34
だからそれは万人にとってじゃないでしょ。
間延びして読みにくいと感じる人もいるわけで。
0040デフォルトの名無しさん2007/03/09(金) 22:03:16
{}付ける派だが、俺は

if()
{
    // ...
}

って開きを綴じと同じレベルに置きたいから無駄になるのが1行じゃなくて2行なんだよな。
0041デフォルトの名無しさん2007/03/09(金) 22:06:59
{{{{{{if(1)printf("Hello, world");}}}}}}
0042デフォルトの名無しさん2007/03/09(金) 22:07:51
俺は状況によって色々

if (...) {
　　aaaaaa;
　　bbbbbb;
}

if (...)
{
　　int n = 0;

　　aaaaaa;
　　bbbbbb;
}
0043デフォルトの名無しさん2007/03/09(金) 22:13:27
>>42
そういう決まりが無いのがトラブルを起こしやすいんじゃない？
0044デフォルトの名無しさん2007/03/09(金) 22:13:33
そもそも省略不可な場合（複数行）が多くて、つけるのが癖になってる。
仮にものすごく低い確率でつけ忘れたってトラブルになる程でもない。
ちょっと実行してみて、あれおかしいな、ああここか修正修正って感じ。
この程度じゃトラブルになりようがない。
ワープロの文書コピー作業じゃないんだから。
0045デフォルトの名無しさん2007/03/09(金) 22:16:34
>>43
決まりはあるけど？
0046デフォルトの名無しさん2007/03/09(金) 22:21:06
関数の最初の方で早抜けするときはこうも書くな

if (...) return;
0047デフォルトの名無しさん2007/03/09(金) 22:40:44
if (...)
  if (...)
    aho();
else
  baka();
0048デフォルトの名無しさん2007/03/09(金) 22:42:30
つまり Python を使えばコーディングトラブルの約70%を省略できると(w
0049デフォルトの名無しさん2007/03/09(金) 22:50:01
if(...)
　　nurupo();
else
0050デフォルトの名無しさん2007/03/09(金) 23:03:09
if(...)
　　b = a>>49;
else
　　gaxtu();
0051デフォルトの名無しさん2007/03/09(金) 23:32:32
完全記述

if(...) {
} else {
 if(...) {
 }
}
0052デフォルトの名無しさん2007/03/09(金) 23:34:33
こうだろ？ｗ

if (...)
{
}
else
{
　　if (...)
　　{
　　}
}
0053デフォルトの名無しさん2007/03/09(金) 23:41:53
以前は>>51のスタイルだったけど
VisualC#を使い始めてから>>52になった。
0054デフォルトの名無しさん2007/03/09(金) 23:42:50
甘い。正解はこれ。

if (...)
{
}
else
{
　　if (...)
　　{
　　}
　　else
{
//do nothing
}
}
0055デフォルトの名無しさん2007/03/09(金) 23:43:10
JavaでもC++でも>>52みたいに書いてる学生だけど
今のうちに修正した方がいいんだろーかと悩むお年頃
0056デフォルトの名無しさん2007/03/09(金) 23:45:04
インデントがプログラムの意味とずれてさえいなければ、どれでも問題なっしんぐ。
あと、人のコードをいじるときは周囲に合わせる控えめな心が大事ｗ
0057デフォルトの名無しさん2007/03/09(金) 23:47:16
心に刻んでおきます
0058デフォルトの名無しさん2007/03/09(金) 23:47:18
プログラミング歴20余年の俺は紆余曲折を経て最終的に>>52のスタイルに至ったんだが。
0059デフォルトの名無しさん2007/03/09(金) 23:48:42
else if
だけはぶら下げちまえ。
ぶら下げ使ってくれ。
頼むから。

あと、俺は
if(..) {
}
派なんだけど、
if(...)
{
}
派が理解できない。
一行無駄だろ。
0060デフォルトの名無しさん2007/03/09(金) 23:51:23
eclipse(ﾃﾞﾌｫ)は>51なんだが、君たちの開発ソフトはどんな記述だ？
0061デフォルトの名無しさん2007/03/09(金) 23:54:17
>>59
ブロックの中でローカルな変数使うときだけは

if (...)
{
　　変数宣言

　　あれこれあれこれ
　　ずびずばぱやぱや
}

ってやりたくなる。　
0062デフォルトの名無しさん2007/03/09(金) 23:54:37
>>60
if (..) {
} else if (...) {
} else {
}

俺もeclipseだけど。
0063デフォルトの名無しさん2007/03/09(金) 23:57:10
>>60 >>62
else の後の if を {} に入れてるかどうかで当然後の整形結果も違ってくるんだろ
0064582007/03/10(土) 00:01:39
else if は俺の場合こうだ。

if (...)
{
  ...
}
else
if (...)
{
  ...
}
else
if (...)
{
  ...
}
0065デフォルトの名無しさん2007/03/10(土) 00:03:09
昔こうやってた時期がある。
あほか、とｗ

/**/ if (...) {
}
else if (...) {
}
else {
}
0066デフォルトの名無しさん2007/03/10(土) 00:07:12
{}をつけないのは副作用のあるループで本体が空の場合だけかな

while (i--)
　;

こんなの。
0067デフォルトの名無しさん2007/03/10(土) 00:09:18
>>66
それはこうやるな

while (i--) {}
0068デフォルトの名無しさん2007/03/10(土) 00:21:32
【ネガティブ派遣根性チェック】

3つ以上、思い当たる点があればアナタの性格はひん曲がっており、ネガティブ負け組人生を歩んでいます。

□派遣先の人事権のある社員の意見はたとえ間違っていてもマンセーする
□派遣先から「いつまでもここで仕事してくださいね(安い金でｗ)」と言われて嬉しい
□自社で仕事なんてできるわけがない
□派遣労働の問題点の話題が出ると感情剥き出しにして反論する
□派遣労働の問題を指摘する人は嫌いだ
□派遣先には仕事だけでなく自分のプライベートについても指示して欲しい
□奢ってくれる派遣先正社員は尊敬する
□自分の月額金額を知らないのは当然だ
□派遣先正社員より自分の生涯収入が低いのは当然だ
□派遣先に尻尾を振り、いつまでも派遣を続けることが大切だ
0069582007/03/10(土) 00:21:55
>>66
それでも、俺の場合はこうだ。

while(i--)
{
}

俺も青かったころは

while(i--);

とかやってたけどね。
0070デフォルトの名無しさん2007/03/10(土) 00:25:32
典型的なレベルの低いスレだな。

こんなのは、「俺の場合」とかじゃなくて、決められたコーディング規則で書け。
0071デフォルトの名無しさん2007/03/10(土) 00:27:37
これは恥ずかしいレスだな
0072デフォルトの名無しさん2007/03/10(土) 00:27:40
>>70
趣味でやってる場合はコーディング規則なんてないし、
仕事でやってる場合でもそのコーディング規則とやらはたいてい誰かの「俺の場合」なんだが。
0073デフォルトの名無しさん2007/03/10(土) 00:28:07
プログラミングは研究で使うだけで規則は決められてない
0074デフォルトの名無しさん2007/03/10(土) 00:28:24
>>70
規約がある場面ならそれに従うのが前提だろ。
0075デフォルトの名無しさん2007/03/10(土) 00:29:20
俺は縦方向にあまり引き伸ばしちゃうと、意味が俯瞰しにくい気がするんだな。
0076デフォルトの名無しさん2007/03/10(土) 00:32:19
自信のない論拠を補強するために妄想で実体のない数字を提示する奴って、
すぐ言い訳や嘘をつくから一緒に仕事をしたくない。
0077デフォルトの名無しさん2007/03/10(土) 00:34:12
うちは皆さんとは逆にif文にブロック禁止。
if(条件) 関数1(); else 関数2();
で書く。
0078デフォルトの名無しさん2007/03/10(土) 00:35:09
コーディングレベルの低い奴に限ってコーディングルールの話をやたらとするんだよなｗ
そんな暇があったらコード書けよｗｗｗ
0079デフォルトの名無しさん2007/03/10(土) 00:36:11
>>77
(条件) ? 関数1() : 関数2();
0080デフォルトの名無しさん2007/03/10(土) 00:37:32
>>77
俺の場合、どうしても１行に納めたい場合は if 文使わずに
(条件 && (関数1(), true)) || (関数2(), true);
とかってする。
0081デフォルトの名無しさん2007/03/10(土) 00:40:16
コードフォーマッタで括弧も自動で付けてくれる奴ってある？
0082デフォルトの名無しさん2007/03/10(土) 00:40:37
チーム平均レベルが低い問題の100%は>>1が原因
0083デフォルトの名無しさん2007/03/10(土) 00:44:26
>>80
詰め込みすぎだw
0084デフォルトの名無しさん2007/03/10(土) 00:45:10
ていうか手段と目的が入れ替わってる
0085デフォルトの名無しさん2007/03/10(土) 00:46:09
>>78 みたいなヤツが、小汚くてメンテナンス性ゼロなコードをまき散らしてんだろうな。
0086デフォルトの名無しさん2007/03/10(土) 00:47:05
そんなに１行にしたいなら改行しなきゃいいだけじゃん。
0087デフォルトの名無しさん2007/03/10(土) 00:48:04
みんな好きだねこういうスレ。
レスの伸びること伸びること。
0088デフォルトの名無しさん2007/03/10(土) 00:49:25
>>85
お前はコードレビューの時につまんない俺流コーディング規則を得意げに解説したりするんだろｗ
聞いてる人うんざりだろうなｗｗｗ
0089デフォルトの名無しさん2007/03/10(土) 00:50:02
>>87
知識が無くても話せるからねｗ
0090デフォルトの名無しさん2007/03/10(土) 00:50:24
コーディング云々よりも、嘘つきの方が遙かに厄介。
0091デフォルトの名無しさん2007/03/10(土) 00:52:52
>>88
お前にいいものやるよ。

　つ　[鏡]

お前の書き込み見てる人うんざりだから。
0092デフォルトの名無しさん2007/03/10(土) 00:58:18
>>1のように自分のミスを他人のコードのせいにして、非を認めずに言い訳し続けたり、
何の根拠もない数字を持ってきて嘘をついたりする人間がプロジェクトに混ざっていると、
非常に迷惑極まりない状態になる。
0093デフォルトの名無しさん2007/03/10(土) 01:03:59
有名ソフトや書籍でも、一行の場合は{}は省略してるのは多いな。
まあ、コーディングルールでも、どうでもいい部分だろな。
これは。
0094デフォルトの名無しさん2007/03/10(土) 01:10:14
>>77
えええええええ

そんなあほらしい規約があるのか。。
驚愕
0095デフォルトの名無しさん2007/03/10(土) 01:14:03
>>94
多少、あほな規約でもちゃんと一貫して守られてさえいればおk。
まぁ、厳しく管理してない限り、たいていなし崩しになっちゃうんだけどな。
0096デフォルトの名無しさん2007/03/10(土) 01:17:27
>>95
> あほな規約でもちゃんと一貫して守られてさえいればおk。

そんなことねーよ。
0097デフォルトの名無しさん2007/03/10(土) 01:19:23
linuxカーネルは、1行の場合は省略だね。
そうじゃないと、コミッタに罵倒されてパッチを受け付けてくれなかったり。
まぁlinuxの場合、インデントは8でタブで無いといけないという決まりもあるので、
読み間違えることは、まず無いのだが。
自分はドライバ書いてるが、そういう文化があるから、Cの場合は省略することが多いね。

でもJavaでは絶対省略しない。ていうか許している仕様が理解できない。
あと、elif とかをなんで用意しなかったのか、謎でしょうがない。
三項演算子もJavaの場合は使わないな。
0098デフォルトの名無しさん2007/03/10(土) 01:30:23
既にある規約を、そのやり方ではミスが増えるとか主張して、
自分流のやり方を押し通そうとする奴がいるが、
いままでそんな問題はなかったからとみんなになだめられても、
絶対に考えを曲げずに最後にはふてくされる。
はっきりいってこういう奴は使えない。
0099デフォルトの名無しさん2007/03/10(土) 01:39:40
>>98
>いままでそんな問題はなかったからと

ヘボいところは、自分らがいかにヘボいか理解できないからなぁ。

まあ、そういう所でやり方を変えようなんて怖くていえないけどな。
当たり前のことができずにトラブって「なんでやり方かえた→言い出したヤツはだれだ」
って展開になりがち。
0100デフォルトの名無しさん2007/03/10(土) 01:39:50
現場の状況に合わせて柔軟に対処できない奴はあらゆるトラブルの原因になる。
0101デフォルトの名無しさん2007/03/10(土) 01:42:43
Perlの
〜if ...;
って何気に最強だな。
0102デフォルトの名無しさん2007/03/10(土) 01:45:51
>>99
規約を変えたければ管理する側に回ってからにしないと統率がとれなくなるだろ。
主張が通らない時点で、その権限が無いことが理解出来ないのが問題なんだよ。
自分の言っていることが正しいと思いこんで、自分勝手な行動をしているという認識がない。
0103デフォルトの名無しさん2007/03/10(土) 01:53:47
>>102
いや、そこんとこは誰も問題にしてないから。
0104デフォルトの名無しさん2007/03/10(土) 02:49:26
クラスの使い方覚えてホイホイ作りまくってたら
「解かりにくいわ！」って殴られた｡･ﾟ･(PД`q｡)･ﾟ･
0105デフォルトの名無しさん2007/03/10(土) 03:34:25
>101
Rubyにもあるな。俺は and 派だが。
0106デフォルトの名無しさん2007/03/10(土) 03:44:40
アホなルールもあるこたあるからね。
1ファイルにつき1関数とか、
関数に分けてはいけない(mainだけにしろ)とか、
関数名・変数名は紙ベースの台帳管理で関数はfxxxx変数はvxxxx(xxxxは数字)とか、
こういう規則はどうなんだろう。理にかなっているのかなあ。

こういうのはやめてもらいたいと思わない?

こういう底辺な現場からおさらばして10年以上になるけど、
まだこういう現場は残っているのだろうか。

まあif以下の文で複文でない場合も{}で囲むことなんてルールは、
あってもなくてもさほど害がないルールではあると思うけどもね。
境界はどの辺にあるんだろうね。
0107デフォルトの名無しさん2007/03/10(土) 03:52:37
＞関数名・変数名は紙ベースの台帳管理で関数はfxxxx変数はvxxxx(xxxxは数字)とか、

これは実際に見るまでなかなか信じがたかったが、ホントにやってるとこあるのな。
漏れが見たのはJavaでの開発だった。
0108デフォルトの名無しさん2007/03/10(土) 03:59:39
>>77
QB登場以前のBASICかよ。
0109デフォルトの名無しさん2007/03/10(土) 04:05:35
C++/Java/C#使いのみんなに聞きたい。
自動変数のスコープを限定するためだけの{}使うよな。な。
仕事で使ったら、「この意味不明な{}は何なのか説明しる」って同僚に詰め寄られたんだが……。
0110デフォルトの名無しさん2007/03/10(土) 04:38:07
>109
俺も使うことはある。特にC言語や、１つのメソッドが大きくなる時は。
ただ、Javaであまり必要に感じたことは無い。
privateメソッド複数作って、処理分けちゃうことが多いかな。
0111デフォルトの名無しさん2007/03/10(土) 04:39:32
>>109
漏れはけっこう使う。

int n;
{
　// 一時的な変数なんかも使って n を初期化するコード
}

// n を使うコード

とか。
書いてみて思ったより長かったらそのまま別の関数にするけど。
0112デフォルトの名無しさん2007/03/10(土) 04:56:00
>>107
そういう職場ってそのうち慣れますか？
それともとっとと逃げ出すのが正解ですか？
0113デフォルトの名無しさん2007/03/10(土) 05:00:10
>>112
そこに骨を埋めるつもりならがんばって慣れないと。
いずれ他所へ行くつもりなら慣れちゃったら後が大変そう。
0114デフォルトの名無しさん2007/03/10(土) 05:08:38
……後者を選ぶことにします
0115デフォルトの名無しさん2007/03/10(土) 05:55:22
>>110
そうしたくなったときというのは、
そこで関数を分けるべき時だと思っているので、
ほとんどの場合は括りだして別の関数に仕立て上げちゃう。

もちろんほんのちょっとスコープを限定したいというときは、
その限りでないけど。
0116デフォルトの名無しさん2007/03/10(土) 05:58:01
>>107
それをやっているところはコボラーが仕切っていると考えてほぼ間違いないです。

あいつらオブジェクトがどうのとかいう以前に関数をわける利点とか、
もっと以前にわかりやすい名前をつけるとかスコープとかいうことを知らん。
0117デフォルトの名無しさん2007/03/10(土) 06:34:15
このスレおもすれえ
0118デフォルトの名無しさん2007/03/10(土) 06:36:52
>116
しょうがないじゃん、COBOLの仕様にはグローバル変数と
引数の無いサブルーチンしか無いんだから…
0119デフォルトの名無しさん2007/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
0120デフォルトの名無しさん2007/03/10(土) 08:11:08
>>94 >>108 30年以上前かららしいから、そんなところでしょう。
COBOLで IF CC EQUAL DD PERFORM YY ELSE PERFORM ZZ. の名残だと思う。
テスト、デバックがこの方がやりやすいからというのが積極的な理由。
ただしbreakする時が大変。
0121デフォルトの名無しさん2007/03/10(土) 10:11:27
http://www.mono-project.com/Coding_Guidelines#Where_to_put_braces

2つ目のgoodがbadだぜ
0122デフォルトの名無しさん2007/03/10(土) 12:04:17
Coding Guideline であって Coding Convention じゃないんだな。
それくらい大きなオープンソースプロジェクトともなると、規約にしたところで従わない奴が続出するんだろうな。
0123デフォルトの名無しさん2007/03/10(土) 12:09:05
厳密にやろうとするなら、コミット前にチェックして(subversionなら
pre-commitフック、CVSだとcommitinfoか?)、従ってなければコミット
させないなんてトコもありそう。

0124デフォルトの名無しさん2007/03/10(土) 12:18:09
そこまでして関数名はf+数字を強制とかイヤすぎるなｗ
0125デフォルトの名無しさん2007/03/10(土) 12:31:50
JavaやC++で省略する奴とは仕事しない
0126デフォルトの名無しさん2007/03/10(土) 12:36:39
C++は省略しても普通だよね。
0127デフォルトの名無しさん2007/03/10(土) 12:38:07
if(flag) break;
0128デフォルトの名無しさん2007/03/10(土) 12:40:31
if(x)
　　　　/* 何らかの処理 */;

って書くとうっかりしやすいけど、

if(x) /* 何らかの処理 */;

って必ず一行に収める習慣にすれば大丈夫な気がする。
0129デフォルトの名無しさん2007/03/10(土) 12:47:07
if(x) 何らかの処理1; 何らかの処理2;
と書く人がでてきちゃう。
0130デフォルトの名無しさん2007/03/10(土) 12:48:34
そもそもブロックなしのifに一行追加して、ブロック付け忘れてハマったなんて経験がない。
0131デフォルトの名無しさん2007/03/10(土) 12:51:29
御意
0132デフォルトの名無しさん2007/03/10(土) 12:58:06
>>129
「;」で区切って一行にいくつも文を書く人にはお勧めできない。
0133デフォルトの名無しさん2007/03/10(土) 13:28:01
if(cond) i = f(), j = g();

自分一人の開発ならこういうこともする。
読み間違えるとかありえない。
0134デフォルトの名無しさん2007/03/10(土) 13:29:32
無能コーダーにぐだぐだコーディング規則を語られるのウザいから
ソースはIDEが自動整形してくれ。
0135デフォルトの名無しさん2007/03/10(土) 13:45:22
括弧も自動で付けてくれるコードフォーマッタある？
0136デフォルトの名無しさん2007/03/10(土) 13:45:33
>>130

if(cond) {
hoge();
fuga();
}
を
if(cond)
hoge();
にしようとした形跡のあるコードで
if(cond)
hoge();
fugafuga();
と、インデントそのままでブレースだけとられたコードではめられた事がある。
じっさいにはもうちょっと長いんだけど。
0137デフォルトの名無しさん2007/03/10(土) 13:47:01
if(cond) {
　　hoge();
　　fuga();
}
と
if(cond)
　　hoge();
fugafuga();
にしようとしたコードで
if(cond)
　　hoge();
　　fugafuga();
とね（ちくせう空白つめんな）
0138デフォルトの名無しさん2007/03/10(土) 13:49:17
>>135
ない
0139デフォルトの名無しさん2007/03/10(土) 13:52:23
お前ら省略って言うけど、Cの場合本来ifの文法は
if( 条件 ) 文;
だよな？
でもこれだけじゃ機能不足で、複数の文を置きたいから{ }でブロックにするんだよな？

由来とかはどうでもいいし俺も{ }は必ずつける派だけどな？
0140デフォルトの名無しさん2007/03/10(土) 14:22:20
>>139
確かに。
でもなんて表現したらいいんだろ？
0141デフォルトの名無しさん2007/03/10(土) 14:29:26
実績ある有名なソフトでも、普通に省略してあるんで、品質には関係ない部分だとは思うけどな。
0142デフォルトの名無しさん2007/03/10(土) 14:44:58
>>139
惜しい

if (式) 文

だ。最後にセミコロンはいらない。

0143デフォルトの名無しさん2007/03/10(土) 14:58:45
>>141
そもそも品質はテストによって担保するものでコーディングスタイルに依存するものではない。
ただ、よいコーディングスタイルであればミスを未然に防ぎやすいというだけのこと。
0144デフォルトの名無しさん2007/03/10(土) 15:03:38
そもそもスレタイの70%の根拠は何だ!
0145デフォルトの名無しさん2007/03/10(土) 15:12:06
>>144
そんなんどうせ >>1 の経験からのなんとなくだろ。
そんなのいちいち気にしてたら負けだ。
0146デフォルトの名無しさん2007/03/10(土) 15:18:05
だけど、
if(condition)
f1();
f2();
というコードに
if(condition)
f1();
f3();
f2();
なんて付け加えるプログラマっているか?
01471462007/03/10(土) 15:20:34
タブでなくスペースで送ってしまった。
>>146 は無かったことに。
0148デフォルトの名無しさん2007/03/10(土) 15:20:36
>>146
なにがいいたいのかよくわからん。必要応じて   を使ってくれんか？
0149デフォルトの名無しさん2007/03/10(土) 15:27:40
>>143
だから、{}を省略してもミスとは関係ないって判断してるんだろ?
有名ソフトで{}を省略するスタイルの人たちは。
0150デフォルトの名無しさん2007/03/10(土) 15:33:07
一人の天才で組んでるならともかく馬鹿と仕事するときは
馬鹿のレベルに合わせなきゃいけないんだよ
0151デフォルトの名無しさん2007/03/10(土) 15:34:10
>>149
有名ソフトでそうしているからっていう判断はあんまり感心せんな。
0152デフォルトの名無しさん2007/03/10(土) 15:36:50
>>150
短期的にはそれは認めるけど、今のこの業界は馬鹿を馬鹿のまま放置しすぎ。
0153デフォルトの名無しさん2007/03/10(土) 16:05:16
向上心が無いからバカ
0154デフォルトの名無しさん2007/03/10(土) 16:23:46
>>151
自分の経験も加えて。
2chのななしよりの意見より、実際に成果を出してるやつのスタイルのほうが参考になる。
0155デフォルトの名無しさん2007/03/10(土) 16:27:33
有名ソフトや書籍でも、省略する派としない派がある。
ようは、たいして重要じゃないってことだろ。
0156デフォルトの名無しさん2007/03/10(土) 17:48:19
う〜ん、おそらくループ変数なんかのためでしょうし、
そのほうが安全そうですが、そういうソースは見たことないです。
0157デフォルトの名無しさん2007/03/10(土) 19:51:17
>>1が70％の確率で{}省略でトラブルという告白スレ
0158デフォルトの名無しさん2007/03/10(土) 23:43:29
>>155
逆だろ
派閥が分かれるってことは懸案事項だってこと
0159デフォルトの名無しさん2007/03/10(土) 23:48:25
結論

コーディング規則を語るのは最下層の乞食コーダだけ。
0160デフォルトの名無しさん2007/03/11(日) 00:08:58
奴隷につなぐ鎖の強度を語るのはいずれ管理へ回る前途ある者
それを理解できない159は、奴隷以下の乞食か動物
0161デフォルトの名無しさん2007/03/11(日) 00:15:19
奴隷をつなぐ鎖なんて強度が十分であれば何を持ってきてもいい。
管理者はカタログから選んで持ってくればいいだけのこと。

鎖を再生産する管理者はバカ。
つながれてる鎖を自慢をする奴隷はマヌケ。
0162デフォルトの名無しさん2007/03/11(日) 01:16:33
何の比喩なのか、わかったようでわからないレスだな。
0163デフォルトの名無しさん2007/03/11(日) 01:18:14
わからないならレスしなくていいよ。
0164デフォルトの名無しさん2007/03/11(日) 01:20:33
逆切れするくらいなら比喩なんか書くなよ
0165デフォルトの名無しさん2007/03/11(日) 01:46:15
だそうだ。気をつけろよ>>160
0166デフォルトの名無しさん2007/03/11(日) 02:01:40
>>165は>>160か。そんなにくやしかったのか？
01671602007/03/11(日) 02:06:05
悔しくなんてねーよ、バーカ
0168デフォルトの名無しさん2007/03/11(日) 02:16:36
本物の160だけど、160以外のレスはつけてないけどね。
逆切れしたのはどいつだか知りたい。
あと、>>160の理由もね
0169デフォルトの名無しさん2007/03/11(日) 02:17:55
＞あと、>>160の理由もね
まちがえた、
あと、>>165-166の理由もね
0170デフォルトの名無しさん2007/03/11(日) 02:27:14
160必死だなｗｗｗｗ
0171デフォルトの名無しさん2007/03/11(日) 03:58:07
だから｛｝でくくっておけばよかったんだ
0172デフォルトの名無しさん2007/03/11(日) 05:47:17
int
hoge ( void ){
}

みたいなのもやめてほしいな。
0173デフォルトの名無しさん2007/03/11(日) 05:52:03
括弧はともかく int と hoge の間の改行は正規表現で定義と使用が区別できるので vi 使いには便利。
0174デフォルトの名無しさん2007/03/11(日) 08:34:51
正規表現なら別に改行でなくてもいいんでは。
0175デフォルトの名無しさん2007/03/11(日) 08:48:19
>>174
vi使ってるときに、

/hoge で普通に検索
/^hoge で定義を検索

ていうことね。
0176デフォルトの名無しさん2007/03/11(日) 11:34:46
IDE使えよ乞食
0177デフォルトの名無しさん2007/03/11(日) 14:13:56
現実には戻りの型の方が関数名より長い事も多々あるからな。
intみたいな極端に短い物以外は改行で統一した方が見やすい。
0178デフォルトの名無しさん2007/03/11(日) 14:21:09
いやそんなにないだろ
0179デフォルトの名無しさん2007/03/11(日) 14:27:25
constもポインタも構造体もクラスもテンプレートも出てこないんですか。
APIやらライブラリ使ってりゃ長い名前の構造体なんていくらでもあるだろうに。
0180デフォルトの名無しさん2007/03/11(日) 17:24:51
構造体なんか返すなよ
0181デフォルトの名無しさん2007/03/11(日) 17:46:03
いくら長くても改行するほどじゃないな
というか、返す型情報まで含めてワンセットだから改行したくないなあ
0182デフォルトの名無しさん2007/03/11(日) 17:49:24
BSD系のカーネルのソースなんかは改行する事になってるね。
style(9)あたりに書いてある。
0183デフォルトの名無しさん2007/03/11(日) 18:19:02
>>180
３２ビット値２つとか３つの組は結構返すよ
0184デフォルトの名無しさん2007/03/11(日) 18:50:28
>>158
どっちか片方に収束しないってことは、どっちでも大差ないんだよ。
どっちかが明らかによかったら、片方のスタイルは廃れてるだろ。
0185デフォルトの名無しさん2007/03/11(日) 18:54:17
>>180はC使い
0186デフォルトの名無しさん2007/03/11(日) 18:56:33
構造体自体を返さなくても、それを指すポインタ返せば記述は長くなりますやん。
0187デフォルトの名無しさん2007/03/11(日) 18:59:02
>>185
C++でも同じだろ。
(スマートポインタで返すって手も使えるけど)
0188デフォルトの名無しさん2007/03/11(日) 19:01:56
>>175
そんなん普通にコメントアウトでラベルつけときゃいいだけやん
0189デフォルトの名無しさん2007/03/11(日) 19:03:41
>>188
意味わからん
0190デフォルトの名無しさん2007/03/11(日) 19:30:28
>>189
int aho() /* teigi */
とかかな。
aho(); /* shiyou */

全部に書く気なんじゃない？
0191デフォルトの名無しさん2007/03/11(日) 20:13:31
lint用のコメントみたいだなｗ
0192デフォルトの名無しさん2007/03/11(日) 20:30:30
>>1
プログラマは信号は守るべきだが
小石を取り除くかどうかはプログラマしだいだ
尊敬するプログラマのソースを読め
0193デフォルトの名無しさん2007/03/11(日) 20:35:44
>>192
尊敬するプログラマはみんな省略してませんでした
0194デフォルトの名無しさん2007/03/11(日) 20:41:49
漏れその昔、ビル･アトキンソンをめちゃくちゃ尊敬してたが、
C系のコードは書いてたのかどうか知らん。
0195デフォルトの名無しさん2007/03/11(日) 23:10:46
defineで閉じてるのは軽くいらっとさせるね
if () {
...
#if 1
} else
#endif
...

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


0196デフォルトの名無しさん2007/03/11(日) 23:22:54
>>195
仕事でそんなコード書いてるヤツ見たら、思わずはり倒しちゃいそう。
0197デフォルトの名無しさん2007/03/12(月) 00:32:13
return_type
func_name(
　arg_type arg
)
{
}
はダメダメってことですね。
0198デフォルトの名無しさん2007/03/12(月) 01:23:06
>>197
なんで？
0199デフォルトの名無しさん2007/03/12(月) 01:47:52
つ >>172 >>177
0200デフォルトの名無しさん2007/03/12(月) 02:07:20
>>197
俺はよくそのスタイルで書く衝動にかられるけど、
引数リストの行末がカンマで統一できないのが
嫌でいつも思いとどまる。
0201デフォルトの名無しさん2007/03/12(月) 08:01:41
> 引数リストの行末がカンマで統一
そ、最後ね

arg_type1 arg1,
arg_type2 arg2,
arg_type3 arg3

最後のarg3だけカンマなしでないとエラー。よく引っかかる。
配列の初期化子は最後のカンマOKなのにね。
0202デフォルトの名無しさん2007/03/12(月) 14:22:14
>>187
C++ 使ってると C の頃の感覚が麻痺して
抵抗なく string 返したりもできるようになる筈ｗ
0203デフォルトの名無しさん2007/03/12(月) 15:09:03
オーバーヘッドなんて高が知れてるし、参照もポインタも使わずに
構造体やクラスを平気で返しちゃうぜ
0204デフォルトの名無しさん2007/03/12(月) 20:35:18
C++クックブックって本は、コンテナクラスは 全部引数でやり取りしてた。
0205デフォルトの名無しさん2007/03/12(月) 21:53:09
何でスレ伸びてるの？
0206デフォルトの名無しさん2007/03/12(月) 23:23:25
>>76
それおまえさんが強要して出させたんじゃないか？
0207デフォルトの名無しさん2007/03/13(火) 00:04:04
>>206
スレタイの数字の話じゃねえの？
0208デフォルトの名無しさん2007/03/13(火) 01:41:45
ぶら下がりelseに起因するbug発生回数は一回
その他の中括弧の省略に起因するbug発生回数は零回
0209デフォルトの名無しさん2007/03/13(火) 02:09:20
どんな書き方をしてもバグを生み出さないソースを書けばいいだけ
どんなにファクターがありそうでも最終的にそこに原因を求めるのは結局責任転嫁だ
0210デフォルトの名無しさん2007/03/13(火) 02:10:42
読みやすい書き方はそれだけでバグの抑制になる
0211デフォルトの名無しさん2007/03/13(火) 05:57:35
インクリメントとかシンプルな処理なら｛｝なんて使わなくても
使うのは数行に渡る見込みがあるか後々まで残す部分くらいだな
0212デフォルトの名無しさん2007/03/13(火) 08:01:55
やはりbegin〜endの勝利だな
0213デフォルトの名無しさん2007/03/13(火) 09:26:05
Python最強ということで
0214デフォルトの名無しさん2007/03/13(火) 09:35:13
schemeもええで
0215デフォルトの名無しさん2007/03/13(火) 09:48:34
ソレより、 && || をif文中で使ってる場合の方が多いように思うけどな

特に俺が書いた時に無かったのに後から何気なく追加されたような場合、たいてい間違ってるゾ！
0216デフォルトの名無しさん2007/03/13(火) 11:02:09
70%はそっちの方だね。
0217デフォルトの名無しさん2007/03/13(火) 11:08:56
まだ && ||を２行に別けて書く人はミスが少ない気がする

if( ( hoge == hage )
&& ( hige ) ){
}
みたいに
0218デフォルトの名無しさん2007/03/13(火) 11:12:50
こういうのは程度の問題で、複雑な式は分けて書いた方が理解しすいだろうが、
シンプルな式まで徹底して分ける事に決めちゃったりしたら、かえってコードの意図がわかりにくくなると思う。
{}の省略についても同様。
0219デフォルトの名無しさん2007/03/13(火) 11:39:36
if修飾子が使える言語(PerlやRuby)だと、やることが1つなら修飾子にして
おいて、増えたら複文支配のifに書き換える、という使い分けが出来るな。
0220デフォルトの名無しさん2007/03/13(火) 13:07:20
むしろ後置ifが使えるなら、
前置ifでの単文修飾は不可能にすべきじゃなかろうか。
0221デフォルトの名無しさん2007/03/13(火) 13:16:18
perlはそうだね。
0222デフォルトの名無しさん2007/03/13(火) 14:06:40
俺はPBP6.2の通りに後置ifはnext, last, redo, return, goto, die, croak, throwでのみ使うようにしてる。
メンテ不要な書き捨てプログラムはこの限りでないがw
0223デフォルトの名無しさん2007/03/13(火) 22:45:43
if文より型の変換とか値入れてない変数とかの方がやばい気がする。
0224デフォルトの名無しさん2007/03/13(火) 22:46:14
全ての分岐をgoto文で書いてやる
0225デフォルトの名無しさん2007/03/13(火) 23:02:08
gotoが必要なのは多重ループを抜けるときだけだよな。
0226デフォルトの名無しさん2007/03/13(火) 23:14:43
ttp://gedo-style.net/g/?v=361721&d=d.jpg
0227デフォルトの名無しさん2007/03/14(水) 00:27:29
多重ループは関数化で対処
0228デフォルトの名無しさん2007/03/14(水) 04:07:30
gotoはエラー処理と字句解析のハードコード。
0229デフォルトの名無しさん2007/03/14(水) 04:48:53
if()
{
;
}

↑これは異端か？
0230デフォルトの名無しさん2007/03/14(水) 05:29:00
異端もクソも、なぜ if() の中を ! で否定しないよ
0231デフォルトの名無しさん2007/03/14(水) 06:53:59
頭ごなしに否定するのはよくない
0232デフォルトの名無しさん2007/03/14(水) 10:31:18
ケツで否定してやる。

{ ; } unless hoge;
0233デフォルトの名無しさん2007/03/14(水) 10:41:26
{ } を付けたら女の子にもてるようになりました
0234デフォルトの名無しさん2007/03/14(水) 17:09:17
スーパー括弧閉じ
0235デフォルトの名無しさん2007/03/14(水) 17:26:03
括弧閉じはコッカって言わないか？
0236デフォルトの名無しさん2007/03/14(水) 19:21:20
通じるけど恥ずかしいから自分では言わない。
0237デフォルトの名無しさん2007/03/15(木) 16:12:21
>>235
それは局所的にしか通じないだろう。
0238デフォルトの名無しさん2007/03/15(木) 16:57:00
sh 系だとそんなだよな。

esac ってなんだろと。
0239デフォルトの名無しさん2007/03/15(木) 17:06:36
fi はまあ想像つくけどなｗ
0240デフォルトの名無しさん2007/03/16(金) 22:54:36
言語規格の中で if() ; 形を if() { ; } の省略形であるとしている
言語はどんなものがありますか。
0241デフォルトの名無しさん2007/03/16(金) 23:11:15
そんなのあるのか？
0242デフォルトの名無しさん2007/03/17(土) 13:24:53
お前らエディタのソース整形機能とか使ったことなさそうだな
0243デフォルトの名無しさん2007/03/17(土) 13:25:18
COBOLにそんな機能ねーよ
0244デフォルトの名無しさん2007/03/17(土) 13:43:26
ソース整形が必要なほどのクソコードに出会ったら
とりあえず腹をくくることにしている。
0245デフォルトの名無しさん2007/03/17(土) 13:51:37
おまえはソース整形について誤った観念を抱いているのではないか
0246デフォルトの名無しさん2007/03/17(土) 13:52:38
ソーッスねぇ
0247デフォルトの名無しさん2007/03/17(土) 14:27:11
ソース整形したらテスト全部やり直しなんだけどそれついてはどうなの？
0248デフォルトの名無しさん2007/03/17(土) 14:29:25
>>247
なんで？
0249デフォルトの名無しさん2007/03/17(土) 14:33:05
>>248
あ？遊びでやってんじゃねーんだぞ
0250デフォルトの名無しさん2007/03/17(土) 14:34:46
>>247
kwsk
0251デフォルトの名無しさん2007/03/17(土) 14:37:04
バイナリがかわんなきゃよくね？
or
テストケース再実行すりゃいいじゃん

好きなほうで
0252デフォルトの名無しさん2007/03/17(土) 14:40:18
テストする前に整形すればいいだけじゃん
0253デフォルトの名無しさん2007/03/17(土) 14:41:43
リポジトリにコミットするとき、自動的にソース整形すりゃよくね？も追加
0254デフォルトの名無しさん2007/03/17(土) 14:45:04
>>247は自動化したテストですらとんでもなく時間を食う
ちょー大規模プロジェクトをやってるんだろう。
0255デフォルトの名無しさん2007/03/17(土) 14:49:30
>>251
＞バイナリがかわんなきゃよくね？
これは納得できる

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

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

>>253
改行した瞬間に自動的にソース整形するVBが最適解か……orz
0256デフォルトの名無しさん2007/03/17(土) 14:53:35
やはりpythonが・・・
0257デフォルトの名無しさん2007/03/17(土) 14:54:49
>>255
時間かかるテストは、夜走らせとけよ

エディタorIDE
↓
リポジトリ(コミット時にソース整形)
↓
CI(夜間に自動ビルド＋テスト)

これ大抵の言語でいけるだろ。
0258デフォルトの名無しさん2007/03/17(土) 16:57:26
バイナリが変わるようなコード変換はもはや整形じゃないと思う
0259デフォルトの名無しさん2007/03/18(日) 01:12:11
>>175
そんなの^(unsigned)*[int|char|short|float|double] [a-Z]+[0-9|a-Z]*\(とかで検索すればいいんじゃね？
0260デフォルトの名無しさん2007/03/18(日) 01:20:04
無理やりこうやればできるとかいう話じゃなくってさ。
viでは検索が日常的なカーソル移動手段のひとつなんだよ。
0261デフォルトの名無しさん2007/03/18(日) 01:34:57
>>259
ぜんぜんだめ。おはなしにならない。
0262デフォルトの名無しさん2007/03/18(日) 01:51:22
C言語は文脈自由文法だから正規表現で完璧にマッチさせるのは不可能
0263デフォルトの名無しさん2007/03/18(日) 05:35:27
>>262 こういう話疎いので、初心者にも解るように解説してください。
0264デフォルトの名無しさん2007/03/18(日) 07:02:14
>>263
コンパイラの本でも嫁
0265デフォルトの名無しさん2007/03/18(日) 11:30:39
突然舞い上がったようなレスだな。>>262は
そもそもどのレスに依存するのだろう。
0266デフォルトの名無しさん2007/03/18(日) 11:33:56
259のあたりだろ。
0267デフォルトの名無しさん2007/03/18(日) 11:41:31
>>265が>>262を全く理解できなかったということだけはわかった。
0268デフォルトの名無しさん2007/03/18(日) 11:50:27
まあ規約ガチガチなのはそのせいだしな
0269デフォルトの名無しさん2007/03/18(日) 13:40:30
正規表現に疎い俺に>>173はどういう正規表現を書いているのか教えて欲しい。
0270デフォルトの名無しさん2007/03/18(日) 13:49:32
そこらじゅうに未定義・未規定・処理系依存が
ぽっかり口をあけているC言語のどの辺がガチガチ？
0271デフォルトの名無しさん2007/03/18(日) 14:23:15
コーディング規約でガチガチにするって意味だよ
02722632007/03/18(日) 18:26:20
そんな連関、聞いたこと無いけどな。
0273デフォルトの名無しさん2007/03/18(日) 19:16:41
>>263
かっこが自由に無制限に入れ子に出来るパターンは
正規表現じゃ理論上無理らしいよ
0274デフォルトの名無しさん2007/03/18(日) 20:28:25
正規文法と文脈自由文法でぐぐってみ
0275デフォルトの名無しさん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.

そういうこっちゃ．
0276デフォルトの名無しさん2007/03/18(日) 21:01:57
だかPerlとかの変態拡張性器表現ならきっと・・・
0277デフォルトの名無しさん2007/03/18(日) 21:11:13
Perlのは正規表現の中でPerlのコードを評価できたりするからある意味万能
0278デフォルトの名無しさん2007/03/19(月) 00:02:33
つまりゲストのお客さんが自由に参加すると収拾がつかなくなるので、
レギュラーのメンツだけでやってくれ、というわけですね。
0279デフォルトの名無しさん2007/03/19(月) 05:52:30
結構前の話題だが

俺は例えば if なら
if(式) 文;
文が一行で、かつこの行が長くならない場合だけ { } を使わずに書くかなぁ。
if(式)
　　文;
と書くぐらいならブレースを使ってる。
0280デフォルトの名無しさん2007/03/19(月) 07:18:05
条件文がすげー長かったら？
やっぱ１行でもブロックにする？
0281デフォルトの名無しさん2007/03/19(月) 07:27:01
条件式を関数なりマクロなりに分けて良い感じの名前を付ければおけ。
そういう時ローカル関数使える言語だといいんだけどな。
0282デフォルトの名無しさん2007/03/19(月) 08:29:05
ローカル関数は欲しいねえ・・
0283デフォルトの名無しさん2007/03/19(月) 08:35:21
C++;なら関数内で定義したクラス/構造体のメソッドで代用出来るけどな
0284デフォルトの名無しさん2007/03/19(月) 08:44:43
無理やりそんなことしても読みにくくなるだけだろ。
読みやすくすることが目的なのに。
02852792007/03/19(月) 20:21:25
>280
うん。条件が長い時もブレースにする。
もしくは条件式の閉じ括弧を実行文の行に持ってくる。
これなら俺は間違えない。集団ならやらんけど。

if(
　　条件式
) 実行文;

BASICで育ったんで一行IF／ブロックIFが基本、
長い時はブロック化するかこうしてたからなー。
IF 〜 _
THEN 実行文
0286デフォルトの名無しさん2007/04/03(火) 13:47:00
自分所のコーディングルールは、

if (式) 文1つ ;

if (式) {
複数の文
}

のいずれか片方のみ可。
0287デフォルトの名無しさん2007/04/03(火) 14:34:40
ルール作るなら、常にブロック使えやコラにした方が良くね？
0288デフォルトの名無しさん2007/04/03(火) 14:35:55
ガチガチだと読みにくくなるよ・・・
0289デフォルトの名無しさん2007/04/03(火) 14:49:39
if (式)
{
　・・・
}

これに統一すると美しい
0290デフォルトの名無しさん2007/04/03(火) 14:58:54
主観
0291デフォルトの名無しさん2007/04/11(水) 06:53:45
>>289
自分には美しく見えない。

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


{
何か
}
という可能性を考えて、前方向をチェックしなくてはならない。
if (式) {
何か
}
というように同じ行に書くように強制すれば、見てすぐにわかる。
if (式) と { が生き別れになってしまうこともない。
0292デフォルトの名無しさん2007/04/11(水) 11:19:49
そんなのは、常に整形ツール使えって事でいいじゃないか。

そのルールが気に入らない場合は、自分が読む時に整形しなおせばいい。
そして、読み終わったら元に戻すと。
0293デフォルトの名無しさん2007/04/11(水) 11:36:07
よっぽどものすごい書き方してなきゃだいたい読めるし、
書くときはまわりに合わせりゃそれでいいじゃないの。
こんなのが原因でトラブるやつは他の原因でもっとトラブるよ。
0294デフォルトの名無しさん2007/04/11(水) 12:55:21
>>291
つ[c++ or c99]
0295デフォルトの名無しさん2007/04/11(水) 14:17:17
TCLではブレース次行じゃダメなんだよな
0296デフォルトの名無しさん2007/04/11(水) 22:35:26
>>295
そうなのか。
あれは、それぞれがシェルコマンドみたいなもんだからな。
0297デフォルトの名無しさん2007/04/12(木) 19:54:03
Tclは改行した時括弧の中じゃなかったら
そこでバッサリ文末になるからな
0298デフォルトの名無しさん2007/04/12(木) 20:55:47
Rubyは、改行したところまでで文が成立する場合は次の行は別の文扱いだな。

二項演算式の途中とか対応するカッコを閉じる前のような、文が未完結である
ことがわかる場合は途中改行ができる。完結しているように見える場合は、
¥を付けて明示的に継続する必要がある。
0299デフォルトの名無しさん2007/04/12(木) 23:55:43
セミコロンが文の終わり、にしときゃ良かったと思うんだけど
なんでそんなにも ; なくしたかったのかな？
0300デフォルトの名無しさん2007/04/13(金) 00:57:43
毎回行末記号書くよりも、必要な時だけ継続記号使った方が手間がかからないという思想だろう。
0301デフォルトの名無しさん2007/04/13(金) 01:16:58
>299
俺は逆に

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

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

Lisperは文末どころか文の始まりまで毎回書くんだもんな…凄いと思う。
0302デフォルトの名無しさん2007/04/13(金) 09:50:40
Ruby慣れると、C書くとき早速セミコロンを忘れる。
無いほうが自然なんだな、と実感する
0303デフォルトの名無しさん2007/04/13(金) 10:13:04
文脈によらずに継続行書くときは常に\つける方が好み。
0304デフォルトの名無しさん2007/04/13(金) 11:38:37
おまいらFORTRANやCOBOLの時代に逆戻りだな・・・
0305デフォルトの名無しさん2007/04/13(金) 14:28:13
>304
むしろ、その時代はカラム制限があったから
セミコロン文末の方が利点が多かったろうに
ある程度のカラムが扱えるなら継続行のみ明示で良いと思うぞ
どうせそんな滅茶苦茶長い行書かないし

…ああ、C言語は使うAPIによっちゃ長い行が普通になるのか
0306デフォルトの名無しさん2007/04/13(金) 19:18:25
>>301
Lisperにはカッコは見えていないし意識して入力もしてないｗ
0307デフォルトの名無しさん2007/04/13(金) 19:56:09
>306
そういうモノなのかｗ
他言語の人（俺含）から見れば大量の括弧の方が目につくんだがな〜
0308デフォルトの名無しさん2007/04/13(金) 20:56:19
>>307
begin endが目につくpascalとか
:-が目につくprologとか
{}が目につくCとか
<>が目につくXMLとか
0309デフォルトの名無しさん2007/04/13(金) 21:57:00
インデントしてたらそんなに目に付くもんでもないんじゃない？
0310デフォルトの名無しさん2007/04/14(土) 01:53:45
セミコロンなしで行末で文末としてしまうと、

class hoge { どわーーー}
という具合に1行に書かないといけなくなりますぞ。
0311デフォルトの名無しさん2007/04/14(土) 09:42:14
どわーーーでなぜか和んだ。
0312デフォルトの名無しさん2007/04/14(土) 09:43:53
>310
そういう言語は
・閉じ括弧が少ない場合はブロックが継続する
・構文でブロックを示すからendが来るまでブロックが継続する
のどちらかを備えてるだろ普通。

Tclは前者。
BASICやCOBOLは後者。
Rubyは両方使ってるな。
Pythonはインデントでブロックを示すんだっけ？
0313デフォルトの名無しさん2007/04/14(土) 12:12:36
Pythonはインデントでブロックを表してて、両方だな。
0314デフォルトの名無しさん2007/04/16(月) 22:57:37
途中から良スレになってる気がした
0315デフォルトの名無しさん2007/04/17(火) 04:31:02
気のせいだった
0316デフォルトの名無しさん2007/08/31(金) 11:46:07
age
0317デフォルトの名無しさん2007/09/01(土) 15:23:25
かの有名なカーニハン先生も省略するべきでないと仰っているよ。
0318デフォルトの名無しさん2007/09/01(土) 15:33:26
蟹飯がナンボのもんじゃーい！
0319デフォルトの名無しさん2007/09/01(土) 17:16:33
>>317
K&R、省略しまくりじゃん。
0320デフォルトの名無しさん 2007/09/02(日) 06:09:15
俺はC→JAVA→C++→C#と勉強してきたから
コードブロックよりもセミコロンがない言語が苦手だな
0321デフォルトの名無しさん2007/09/02(日) 18:34:19
セミコロンは文の区切りです。
0322デフォルトの名無しさん2007/09/02(日) 21:58:20
同じセミコロンでもデリミタとして使う言語とターミネータとして使う言語があるのよん。
0323デフォルトの名無しさん2007/09/02(日) 23:07:25
Pascalは文の最後はピリオドだったな。
0324デフォルトの名無しさん2007/09/03(月) 00:46:44
pascal は
○ if a then b else c;
× if a then b; else c; (コンパイルエラー)
Cはどっちも大丈夫
0325デフォルトの名無しさん2007/09/03(月) 01:18:28
Cはどっちも怒られそうだぞ
0326デフォルトの名無しさん2007/09/03(月) 13:06:03
カッコが付かないな
0327デフォルトの名無しさん2007/12/31(月) 03:42:45
Pascalの場合、elseはif文の一部で
セミコロン付けると、そこでif文が終わるから
「文頭にelseはおかしい」って言われるんだよね。
0328デフォルトの名無しさん2008/03/05(水) 17:00:17
c でも else は if 文の一部。

; が文同士のセパレータではなく文の終端記号でしかないから、
b; が 1 文となって問題にならない、ってこと。
0329デフォルトの名無しさん2008/03/15(土) 16:13:12
>>323
プログラムの最後だろ？
0330デフォルトの名無しさん2008/05/04(日) 13:30:52
>>1
COBOLのIF文の歴史を知らないんだな。
0331デフォルトの名無しさん2008/05/06(火) 17:30:21
内容（意味）によらず形式だけで決める
>>1の考え方が危険なだけ

0332デフォルトの名無しさん2008/05/06(火) 17:42:39
人いたんだ。
0333デフォルトの名無しさん2008/06/25(水) 14:44:13
>>331
形式で決められるものは、決めればいい。
その分、考えないといけないことに頭のリソースを配分しようぜ。
0334デフォルトの名無しさん2008/06/29(日) 01:35:51
ブラを付ける自由もあれば、付けない自由もある。
女性はブラジャーの着用を義務付けるという法律が
制定できないのと同じ。
ブラは時には非常に邪魔になる。
形式では決めることができないものは意外に多い。
0335デフォルトの名無しさん2008/06/29(日) 02:50:06
そもそも、
Windowsのメモ帳にたくさん毛が生えたようなテキストエディタを使ってコードを書く
という時点で、おかしいだろ。
0336デフォルトの名無しさん2008/06/30(月) 18:35:16
C#なら言語仕様で{}を強制してたとしても不思議ではないね
switch内のbreakは強制だっけ
0337デフォルトの名無しさん2008/06/30(月) 22:41:09
{} を強制するなら elseif キーワードが必要
0338デフォルトの名無しさん2008/07/01(火) 03:21:06
ブラを強制するのなら、elseの禁止も合わせてやったほうが良いかも？

よくね〜よw。
なるべくブラ着用。elseの多用は可愛気がないぜ。といったところ。
0339デフォルトの名無しさん2008/07/01(火) 04:43:44
コーディングするためのユーザインタフェースが、
事故を未然に防ぐべく何かするのが第一だろ

いつまでも
紙に鉛筆でプログラムを書くレベルに留まるな
0340デフォルトの名無しさん2008/07/27(日) 00:00:15
>337
なぜに?
0341デフォルトの名無しさん2008/07/27(日) 02:59:30
elseifがないと
if () {
} else {
　if () {
　} else {
　　if () {
　　} else {
　　　if () {
　　　} else {
　　　}
　　}
　}
}
みたいにどんどんネストが深くなる。
0342デフォルトの名無しさん2008/07/27(日) 03:00:38
{} を省略できるなら
if () {
} else if () {
} else if () {
} else if () {
} else {
}
みたいに書けるんだけど
0343デフォルトの名無しさん2008/07/27(日) 03:06:05
強制する←→省略不可だからそういうのも認めないって話じゃねーの。
0344デフォルトの名無しさん2008/07/27(日) 03:27:46
というか、>>1の主張を強制するのならelse ifという慣用表現も禁止で
>>341みたいにきちんとif文をネストするような表現とすることを
強制するべき。
>>342式を禁止するというか非推奨にするのは、それなりに根拠がある。
多くの場合、>>342の形式の場合、ロジックが練れていなく、
バグが多い割に修正が難しいから。経験的に言って>>341式のほう
が、バグも少なくなり、バグが出ても修正しやすいような気がする。
結論的に言えば>>342式を禁止するのは一定の意味を持つが
>>1を強制するのはやり過ぎかも。
0345デフォルトの名無しさん2008/07/27(日) 04:11:17
>>342禁止ですら、行き過ぎという感があるのに
>>1強制なんてあり得ない
0346デフォルトの名無しさん2008/07/27(日) 13:36:09
なる。
それなら俺は {} 強制で else if 容認かな。

自分のバグ元としては {}なしのif より 比較に = 使っちゃう方が多いけど。
だから、エディタで[^><=]=[^=] を赤くなるようにしてる。
0347デフォルトの名無しさん2008/07/28(月) 15:32:25
caseで
0348デフォルトの名無しさん2008/07/28(月) 17:42:41
多くの場合、経験的に言って、根拠があると言っているわりに>>344は主観推論しか言っていない気がする。
0349デフォルトの名無しさん2008/07/28(月) 21:13:28
case式が強力な言語ならいいんだけどCだと定数との比較しかできない
0350デフォルトの名無しさん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的な使い方だと誤解して順序を変えてしまうと、意味が変ってしまう。
0351デフォルトの名無しさん2008/10/01(水) 23:41:42
if(id == typeA && ){}
else if (id == typeB &&){}

って書く奴いるけどなんでswitch文使わないの
バカなのねぇバカなの？
0352デフォルトの名無しさん2008/10/02(木) 09:16:07
>>351
妙な && が気になるが、if で書けば
・コードの行数が少なくて済むので見やすい
・スコープがしっかり認識できて良い
・シンタックスハイラトや自動インデントなど IDE によっては switch の対応が微妙
・if の方がコンパイラが最適化しやすい条件になっている
とかとか。分かってて書いている人なら、別に良いと思うけど？
0353デフォルトの名無しさん2008/10/02(木) 22:17:54
if(id == typeA)
if(id == typeB)
と
if(id == typeA)
else if(id == typeB)
同じ意味だよね？
0354デフォルトの名無しさん2008/10/03(金) 01:40:46
>>353
if (id == typeA) {
...
id = typeHoge;
}
の場合は？

0355デフォルトの名無しさん2008/10/06(月) 12:06:12
>>353
idがconstなら同じ。そうでないなら、>354の可能性がある。
例えば、この関数では全く同じ。
void func(const int id)
{
if (id == typeA) {
funcA();
}
if (id == typeB) {
funcB();
}
}
0356デフォルトの名無しさん2008/10/06(月) 12:18:01
つか、同じじゃないように見えるんだけど？

if(id == typeA)
if(id == typeB)
って、インデント付けると
if(id == typeA)
　if(id == typeB)
だよな？　更に括弧も付けると
if(id == typeA) {
　if(id == typeB) {
　}
}
だよな？
0357デフォルトの名無しさん2008/10/06(月) 13:00:09
>>356
>353が>351を踏まえて書いたかどうかだな。
>353が>351を踏まえずに>356の意味で書いたのだとしたら、
if (id == typeA) if (id == typeB)
は(typeAとtypeBが等しいと言う無謀な前提を仮定しない限り)
if (0)と同じになってしまう。
0358デフォルトの名無しさん2008/10/07(火) 18:07:30
べつに無謀な前提ではないんじゃないか
typeA != typeBでもid == typeAかつid == typeBだったりすると怖いけど
0359デフォルトの名無しさん2008/10/09(木) 12:42:52
>>358
この流れでその前提は、余りに阿呆過ぎる。
最早>351も>353もいないから真意は不明だが。
0360デフォルトの名無しさん2009/04/08(水) 19:34:44
ダメ
0361デフォルトの名無しさん2009/08/26(水) 18:28:00
{}をつけないせいで失敗するほど不注意なら{}をつけたせいで失敗する事もありそう
0362デフォルトの名無しさん2009/08/31(月) 11:56:11
こういうバカなやつもプログラム書いてるのが問題なんだよね
0363デフォルトの名無しさん2009/09/01(火) 02:47:11
？
0364デフォルトの名無しさん2009/09/01(火) 07:59:27
凡人と初心者は{}付けとけば問題なし。
0365デフォルトの名無しさん2009/09/01(火) 12:07:22
初心者ほど{}を省略するからな。
そして成長しないまま{}を省略し続けると。
0366デフォルトの名無しさん2009/09/02(水) 02:31:00
{}を付ける癖がつくと、すべてのロジックをそのルーチンの中に
詰め込み、使い回せる関数だけを外側に出そうとする癖がつく？
本当に使い回せるかどうかの判断は実は相当のベテランでも
ない限り難しいにも関わらず。

{}を付けない癖がつくと、すべて下請けに回そうというコード
になりがち。最初は調子が良いが硬直なコードになりがちなので
仕様変更時に泣きを見る結果になりやすい？
0367デフォルトの名無しさん2009/09/02(水) 19:45:17
初心者は何度も書き換えて、コードが増えたり減ったりを繰り返す。
構造もあやふやだろうし、{}無しで使ってコケる。それも勉強だろうけど、
{}を付けて処理範囲を明確にすれば、最低限コケることは無くなる。
{構造化を意識させることもできる(その地点からはだいぶ先の話だけど)。
0368デフォルトの名無しさん2009/09/03(木) 23:09:26
>>365
上級者はふつーに省略して、省略するなって主張してるのって、2chの名無しとか
素人くさいプログラム系のブログってイメージ。
0369デフォルトの名無しさん2009/09/04(金) 02:03:58
オフサイドルール大勝利
0370デフォルトの名無しさん2009/09/04(金) 20:36:44
っていうか{}省略で起こる問題って具体的にどんなことがあるんだ？
if(){
func1();
}
else
func2();

ふつうにインデントしてれば何も間違えよう無いし{}省略で
間違えたことなんて一度もねーぞ。
0371デフォルトの名無しさん2009/09/04(金) 20:51:54
>>1本人のコーディングトラブルの 70% だそうなので
皆さんは気にしなくていいですよ
0372デフォルトの名無しさん2009/09/04(金) 23:38:11
俺は省略しないんだが、省略したら今の三倍もバクが増えるとは
とても思えないんだが。
0373デフォルトの名無しさん2009/09/05(土) 08:52:10
さすがに70%はありえないな。
{}省略で間違えることはあまり無い。
ただ、else節以降でインデントを間違えてるソースを見た事は2回ぐらいある。
あれは悩ましいからやめてくれ。

初心者のうちは間違いようの無いシンプルなルールで書いて、
他の部分に頭を使った方がいい。
もちろん天才とベテランは別。
0374デフォルトの名無しさん2009/09/08(火) 09:41:31
>>372
バグをバクとtypoするようなレベルの奴が言っても
0375デフォルトの名無しさん2009/09/08(火) 12:26:48
ﾜﾛﾀ
0376デフォルトの名無しさん2009/09/08(火) 14:08:44
　　,ｨ─--、　　　,ｨ─--、　　　,ｨ─--、
　 (_/　(ヽ'ヽ。　(_/　(ヽ'ヽ。　(_/　(ヽ'ヽ。
　 ヽ　゛д ノ　　ヽ　゛д ノ　　ヽ　゛д ノ　　＜三倍に増えるぞな！
　　ﾉ　∪　|　　　ﾉ　∪　|　　　ﾉ　∪　|
　 ,ゝ、　 .ノ　　 ,ゝ、　 .ノ　　 ,ゝ、　 .ノ
　　　|＿(　　　　　|＿(　　　　　　|＿(
0377デフォルトの名無しさん2009/09/08(火) 22:26:47
2chの書き込みのタイポごときで揚げ足取ったつもりで得意顔？
みっともね。
0378デフォルトの名無しさん2009/09/09(水) 09:35:16
>>377
手がすべったtypo、意図的なものとして定着したtypoならそうかもしれんが、明らかに違うよな。本人乙。
0379デフォルトの名無しさん2009/09/09(水) 11:13:43
>>378
JISカナ配列使いかも知らん。
0380デフォルトの名無しさん2009/09/09(水) 11:59:17
そもそもコーディング時のミスの話してる時に書き間違いの書き込みしてるんだから
間違いは起こりうると証明してるようなもん。
0381デフォルトの名無しさん2009/09/09(水) 12:02:32
>>380
>そもそもコーディング時のミスの話してる時
「{}を省略することによる」という前提外すなよ。
0382デフォルトの名無しさん2009/09/09(水) 14:42:40
世の中qwertyでローマ字入力ばかりだと思ってんのかよ。
0383デフォルトの名無しさん2009/09/10(木) 09:22:19
カナ入力するプログラマなんて死ねばいいけどね
0384デフォルトの名無しさん2009/09/10(木) 11:42:18
>>383
自分の前に使ってた人がカナロックしっぱなしで
うっかり「ﾄﾝﾄｶｲﾓ」とか入れちゃったとか、そういう被害にでも遭ったのか？
0385デフォルトの名無しさん2009/09/10(木) 22:26:26
懐かしいな、ﾄﾝﾄｶｲﾓ。
0386デフォルトの名無しさん2009/09/12(土) 16:20:26
有限会社ﾊﾆﾘｲﾄってのがあってちょっとクスッときた
0387デフォルトの名無しさん2009/09/14(月) 04:05:51
カナ無刻印キーボード使ってるんで面白さがわからん。
解説してくれ。
0388最後の二つはNECとNTT2009/09/14(月) 09:17:47
>>387

トントカイモ→system
ハニリイト→files

パソ通の時代は、みんな覚えていたもんさw
ミイソの98でミミカ経由で繋いでたからね。
0389デフォルトの名無しさん2009/09/14(月) 14:20:41
ミカカでしょ
リニトカとかスナミとかもやったなあ
03903882009/09/14(月) 15:18:38
おー、typoだ。失敬。
0391デフォルトの名無しさん2009/09/17(木) 11:51:39
俺も一行なら省略してたけど、別にそれでトラブルったことはないな。
それより、結局処理追加する必要があると分かった時に挿入したり、
逆に一行でいいと分かった時に整合性のために削除してることが多いのに気付いて
めんどいから最近は {} 非省略派になった。
0392デフォルトの名無しさん2009/09/17(木) 13:44:44
俺の場合は{}を使ってifやループでやる処理をぱっと見て分かるように囲ってる。
if(hogehoge){
　　...;
　　...;
}
とか
if(hogehoge){ ...; }
とか。
ブレース使っても短い処理なら1行で記述できるし省略の必要性は全く感じてない。
0393デフォルトの名無しさん2009/09/17(木) 13:52:53
ifと括弧の間に空白のないコードの70%は糞。
ときには、条件に一致した場合の処理を同一行に書く、上級糞コードも。
0394デフォルトの名無しさん2009/09/17(木) 14:04:44
フォーマッター使えばどうにでもなるような事をグジグジ言ってる暇があるなら
もっとマシなコード書けよ。
くっだらねえ。
0395デフォルトの名無しさん2009/09/17(木) 14:54:09
確かに、スペースポリシーって些細なようでその人の性格が出るな。
統一感がなかったり、合理性がない書き方をする奴は確かにコード自体も質が悪い傾向にある。
ところでたまに

if (続行条件) {
　続行処理...
} else {
　終了処理...
}

みたいなのと

if (終了条件) {
　終了処理...
}

続行処理...

どっちがいいのか迷うんだけど、（無駄にブロック作りたくないから後者にしてるけど）
こういう制御構文の使い分けのケーススタディみたいなのが
詳しく載ってるサイトとか書籍ってないのかな。
0396デフォルトの名無しさん2009/09/17(木) 15:18:38
>>1
ジョークかと思ったら、本気みたい。
0397デフォルトの名無しさん2009/09/18(金) 09:51:54
>>395
それだけじゃよく判らんが、無駄にブロックを作りたくないなら
if (! 続行条件) {
　終了処理...
}
続行処理...
とするか
if (続行条件) {
} else {
　終了処理...
}
続行処理...
としてもいいよね。
0398デフォルトの名無しさん2009/09/19(土) 12:11:51
"else if"をひとつながりで一つのキーワードにしてみるのはどうだろう。
マイクロソフトならやりかねない
0399デフォルトの名無しさん2009/09/23(水) 11:58:27
ほかの言語にはelifつーものがあってだな
0400デフォルトの名無しさん2009/09/24(木) 00:02:47
if 〜 else if は if 〜 else と違って if に対して処理が対象ではないから、
勘違いする人のためには elif が有ってもいいかもね。ダサイけど。
0401デフォルトの名無しさん2009/09/25(金) 11:04:48
>398はどれへのレスなんだ?
少なくとも>395はelse ifの話なんて全然してないわけだが。
0402デフォルトの名無しさん2009/09/25(金) 14:46:22
>>394
書かれたコードを問題にしているのではない。
書いた阿呆の無能さを問題にしているのだ。
0403デフォルトの名無しさん2009/09/27(日) 18:19:52
eclipseで自分仕様のスタイルが設定できなくて困る
一度間違ってソースが全部整形されてしまって、ヒストリで元に戻そうにも
そのミスをやってしまったのがかなり前だと判明したため泣きながら手作業で修正した
0404デフォルトの名無しさん2009/09/27(日) 18:31:08
そこで bc ですよ。
0405デフォルトの名無しさん2009/09/28(月) 11:20:30
暫くindentを改造して使っていたが、思い通りにいかないことが増えてきて捨てた。
今は必要なときに必要なところだけエディタで整形している。
0406デフォルトの名無しさん2009/09/28(月) 21:29:02
ideやら整形ツールで対応できないような一般的でないスタイルは捨てるというのはどうだろうか。
0407デフォルトの名無しさん2009/09/30(水) 15:01:54
エディタを俺仕様にカスタマイズするのは大分前にやめた。
自分をエディタに合わせる方が楽。
0408デフォルトの名無しさん2009/11/23(月) 20:43:16
ガード節による入れ子条件記述の置き換え
1. メソッドに正常ルートが不明確な条件付振る舞いがある
2. 特殊ケースすべてに対してガード節( メソッド内で、処理がメインロジックに到達するの
を防ぐためのコード) を使う
double getPayAmount() {
　double result;
　if (_isDead) result = deadAmount();
　else {
　　if (_isSeparated) result = separatedAmount();
　　else {
　　　if (_isRetired) result = retiredAmount();
　　　else result = normalPayAmount();
　　}
　}
　return result;
}
　↓
double getPayAmount() {
　if (_isDead) return deadAmount();
　if (_isSeparated) return separatedAmount();
　if (_isRetired) return retiredAmount();
　return normalPayAmount();
}
出口が1 つだけというルールは本当は有益ではありません。
1つにすることでメソッドが明瞭になるならば出口は1 つでいいが、そうでなければ使うべきではない
■ このスレッドは過去ログ倉庫に格納されています