コーディングスタイルにこだわるスレ

■ このスレッドは過去ログ倉庫に格納されています
1デフォルトの名無しさん
垢版 |
2007/10/28(日) 15:59:01
コーディングスタイルについて熱く語れ
2009/10/20(火) 11:51:05
>>327
行が長くなるときどう折り返すか
ttp://java-house.jp/ml/archive/j-h-b/009166.html#body
2009/10/20(火) 12:09:53
C++ 使っててカンマとか演算子の「前」で折り返して、演算子の類が行頭にくるように
してたんだけど、 Python 使い出したらそうもいかなくなって、今は微妙な気持ちです。
2009/10/20(火) 12:20:08
>>331
英語では普通、カンマやセミコロンなどは単語の後ろに空白なしにつける。当然、改行はその後。
演算子もそれに準じる。
2009/10/20(火) 13:57:32
>>331
（ ・∀・）人（・∀・ ）ﾅｶｰﾏ

.append(foo)
.append(bar)
.toString();

+ fooooooooooooooooooooooo
- (baaaaaaaaaar % baaaaaaaaz);

= {
11111111111
, 2222222222
, 3333333333
}

if (
(cooooooooooooooond)
|| (baaaaaaaar && bazzzzzzzz)
)

文末を見るより、文頭を見るほうが目の動きが少ない。
2009/10/20(火) 14:05:42
. を先頭にもってくるのは許せるが、 , を先頭にもってくるのが許せないのはなぜだろう。
2009/10/24(土) 22:25:29
if 〜 else if 〜 else の各節にコメントをつけたいとき、俺はこのように書いているんです。
// こういう場合はこう
if (...)
{
}
// こういう場合はこう
else
{
}

ところが、節を分断するのはよくないと言う人がいるんですね。それはそれで一理あります。
その人はこう書いている。
if (...) // こういう場合はこう
{
}
else // こういう場合はこう
{
}

このやり方だと、条件式が長くなったり複数行にわたると、ちっと面倒なことになる。
みなさん、if文のコメントはどのように書いていますか？
2009/10/24(土) 22:35:25
>>335
if にコメント付いてれば else へのコメントは冗長だろ？考えるだけ無駄。
2009/10/24(土) 23:21:52
冗長なんて言ったらコメントなんて書けなくなる。
それに複数のelse ifがある場合はコメントがあった方がいい。
2009/10/25(日) 00:16:58
>>337
お前はなんのためにコメントが書きたいの？
コメントを書くことが目的なの？
2009/10/25(日) 01:41:21
// コメント
if(...) {
}
else {
// コメント
}
2009/10/25(日) 02:39:09
>>339
俺もそれだ。
2009/10/25(日) 02:43:33
俺はこうだわ。space efficiant!!

if(...) { // コメント
  foo();
} else if(...) { // コメント
  bar();
} else {
  foobar();
}
2009/10/25(日) 07:39:57
漏れは内容に応じて使い分けた方が良いと思うけど。

// 分岐全体について。
if( ... ){　　　// 式について。
　// ブロック内の処理&実行条件の概要
}
else {
　// ブロック内の処理&実行条件の概要
}


（例）
// 〜と〜を切り分ける
if( … 　　// 〜をチェック
&& … ) { // 〜をチェック
　// 〜の場合、〜する
}
else {
　// 〜の場合、〜する
}
2009/10/25(日) 14:06:52
こうしてる
if(...) {
　// ...なら〜
} else {
　// 〜(条件についての記述は無し)
}
2009/11/22(日) 14:45:58
お前ら、そんな面倒なコメントつけるくらいなら
is_こういう場合() っていう関数作ってif に入れとけよ。

どうしてもコメント書きたかったら
is_こういう場合() のところに書けばすっきりしていいだろ。
2009/11/23(月) 06:06:37
>344
それだと is〜() が何をチェックしてるのか知りたくなったら、一々中身を見なきゃ分からないし、
is〜() の条件を変えたくなったら、使ってる場所を全部チェックした上で変更するか、
「使われない関数」が生じるのを覚悟で別な関数を追加しなきゃならん。
（まぁ静的リンクのみなら、コンパイルすれば何処で使ってるかは分かるけど）

is〜()の名称自体は「何を」チェックするかに留めて、「何故」チェックするかとか
条件式全体が何を意味するかとかは、コメントに書く方がよっぽど面倒が無い。
2009/11/23(月) 10:58:02
>>345
> それだと is〜() が何をチェックしてるのか知りたくなったら、一々中身を見なきゃ分からないし、
ちゃんと名前付けて、関数宣言部分にコメント書けば、そんなことにはならないよ。
中身見るのはバグを疑うときぐらい。

> is〜()の名称自体は「何を」チェックするかに留めて、「何故」チェックするかとか
> 条件式全体が何を意味するかとかは、コメントに書く方がよっぽど面倒が無い。
コメントに書いて良いのは「何故」だけだな。
2009/11/23(月) 11:01:17
仕方なくわかりづらいコード書くときしか関数の中にコメントは書かないな
外側に書いたドキュメントだけでいい
2009/11/23(月) 11:01:32
>>345の思考様式だと関数を細かく分けることは悪になりそうだなｗ
適切な名前の関数を作ってどんどん分けるのは常識レベルだと思ってたが
349345
垢版 |
2009/11/23(月) 18:28:36
漏れは>344の言葉をそのまま鵜呑みにすると

　// Hogeの場合
　if ( isFoo() && isBar() )

のようなコードも、コメント付けるより

　if( isHoge() ）

とした方が良いって事になるのを否定しただけです。
ちょっと言葉足らずで意図不明瞭だったのは申し訳ない。
↓以外は>346-348全てに同意。


>346
>コメントに書いて良いのは「何故」だけだな。

この言葉を鵜呑みにすると、「何時呼び出す」とか書けない。
これは「5W1Hが単純に読み取れない場合だけ」のがより適切だと思う。


>348
>適切な名前の関数を作ってどんどん分けるのは常識レベルだと思ってたが

これは「どんどん」「分ける」の間に「適切な粒度になるよう」が抜けてる。
2009/11/23(月) 20:50:16
適切に分けてりゃ、関数名は「何を」チェックするかだけ示せば十分>>344のように
運用できるだろ
2009/11/23(月) 23:17:29
>>349
>>コメントに書いて良いのは「何故」だけだな。
>
> この言葉を鵜呑みにすると、「何時呼び出す」とか書けない。

コードに呼び出しタイミングは書いてあるのに、なんでそんなことを
コメントに書きたいの？

それとも、関数を作った側がどんなときに呼び出すべきか想定してる
ってこと？
それなら関数の側にコメント書くから、やっぱり if にコメント書くことには
ならないよ。
2009/11/23(月) 23:53:41
ってゆーか、さ、
if ((flag & F_OPT1) && (flag & F_ERROR_ABORT)) // デバッグが有効で abort する場合
{ ... }
else
{ ... }

みたいに謎の条件判断とコメント両方つけるぐらいなら

if (is_abort_on_debug(flag))
{ ... }
else
{ ... }
って書くだろ？
353354
垢版 |
2009/11/24(火) 00:15:33
ついでに言っとくと、>>342 みたいに
細切れでコメントつけるのはあんまり好きじゃない。

if (is_debug() && // デバッグモードをチェック
　　is_error_abort() ) { // エラーで abortするかチェック
　　// デバッグ時エラーならアボートする
　　... // 必要な処理をする
} else {
　　// デバッグモードでないか、エラーでも abort しない場合
　　nr_error++; // エラーカウンタを更新
　　... // 必要な処理をする
}

みたいに、C言語の日本語直訳を書くだけになりやすい。


それなら
/*****************************
* この関数は○○の時は△△します。
* 詳細は http://＜社内サイトの仕様書置き場＞
* の □□ のフローを参照してください。
* データフォーマットは grep -r Hoge_data ./sub1/include で探してしてください。
*****************************/
とでも書いてあったほうがわかるよ。
2009/11/24(火) 00:17:52
オレだよ、オレオレ
355354
垢版 |
2009/11/24(火) 02:45:53
>350
「AかつB ⇒ Cである」の「Cである」が、一言で言えるなら>344で十分だけど、
常にそうであるとは限らんでしょ。
「Aである」「Bである」とか、一言で言える「Cである」は
>344の方針で良いと思うけど。


>351
すまん、if文へのコメント限定ではなく、コメント全般で考えてた。
if文へのコメント限定だったら、「何時真になる」とか。


>352
その例、漏れなら下のいずれかにする。
1,2の場合はコメント無し。3は政治的理由等で1,2が採択できない場合の最後の手段。

(1) if ( (flag & F_OPT_DEBUG) && (flag & F_ERROR_ABORT) )
(2) if ( isDebug(flag) && isAbort(flag) )
(3)　if ( (flag & F_OPT1)　　　　　　　　　//デバッグON
　　　　&&(flag & F_ERROR_ABORT) )


>353
352も漏れだけど、そーいう実況的コメントを書けという意図ではない。
コメントを書くなら、対象が明示的になる位置に書くべきでないの?
という趣旨で書いてる。
2009/11/24(火) 02:47:03
>355=>345≠>354
orz
2009/11/24(火) 02:54:18
>>352のコードは二つのことを一つの関数で表してるから微妙だな。
>>353や>>355のコードの方が良い。

だが、>>345で言ってることはどうにも奇妙に感じられる。
要は、コードで語り合った方がいいタイプってことだな。
2009/11/27(金) 18:45:01
中身が1行のif文やfor文について

// 1
if (...)
　　...;
{}省略してバグ混入したら嫌。

// 2
if (...) { ...; }
デバッグの時にブレークポイントが置きにくい。1行が長くなりそうなのも×。

// 3
if (...)
{
　　...;
}
行数取りすぎて画面内に表示されるコードが減ってしまう。if (...) {にすれば1行減るけど普段使ってないから一貫して使いたくない。

// 4
if (...)
{ ...; }
インデントがないのが見にくそう。かと言って{がインデントされているのも気持ち悪い。

それぞれデメリットがあって悩ましいです。
皆さんはどう書いていますか？
2009/11/27(金) 19:00:25
「{}省略してバグ混入」とはちょくちょく聞く意見だが、
生まれてこの方十数万行書いてきたが、
一回もソレになったことがない。

中括弧書き忘れたからといってバグるやつも、
バグるから書いておけばいいと考えるやつも、
死んでしまえと思う。

その程度の注意力と読解力、記述力しかないのなら、
人間やめてしまえと思う。
2009/11/27(金) 19:25:27
>359
確かに中括弧省略によるバグ混入のリスクがどの程度あるのか疑問ですね。
しかし、その反論も中括弧を省略するメリットがなければ意味がなくないですか？
中括弧を書く僅かな手間で、少しでも注意力のいらないコードが書けるのなら理にかなっていると思いますが。
2009/11/27(金) 19:56:23
>>360
ifに一行くっついてて、それにもう一行加えるんだろ？　すぐ下とかに。
それを書くときに中括弧が必要か否かに注意を払えないやつ、
書き忘れ、などと捕らえてしまうやつは死んだほうがいい。
変更を加えるとき、いつだってその挿入行の前後への注意は必要だ。

その注意力すら欠いておいてプログラミングをしようとするのは怖い。

> 中括弧を書く僅かな手間で、少しでも注意力のいらないコードが書けるのなら理にかなっていると思いますが。

それは否定していない。ただ、効果は有るが、全体にとって微少だと思ってる。
ただ、そんなヤワなサポートに頼ってしまう時点で、既に色々ダメだ。

個人的にはこうしてる。

if (cond) return; // continue, breakなども

if (cond) {
 abababa;
} else {
 abababa;
}

これは、注意力軽減への配慮でもなんでもなく、
見た目を統一したいがためにそうしてる。
ネストを避けるための式は右側に書いちゃう。
それ以外で中括弧はいつもつける。elseがなくてもつける。

> 中括弧を省略するメリット

メリットなんざ特に思いつかない。あえて言うなら見た目。
2009/11/27(金) 19:57:15
中括弧省略によるバグは実際会社で２例ほど見た
自分だけがいじるコードならいいだろうけど
後々他の馬の骨がいじる可能性も考えると
{ } 省略はやめた方がいい

ちなみに、俺は開始 { は if と同じ行に書く派
そして { } 内が短くても { の次は改行を入れ、} は単独行にする
昔は { を if の次の行に書いてたけど間延びするのでやめた
でも、行が長いと間が詰まりすぎると感じる事もあるので微妙な所
2009/11/27(金) 20:01:17
最初は一行でも後で書き足すことも多いので大抵は常に括弧付ける。
括弧あった方が見やすいし。
2009/11/27(金) 20:46:51
>>361
> それは否定していない。ただ、効果は有るが、全体にとって微少だと思ってる。
コーディングスタイルで重要なのは統一する事ですよね。
どっちでもいいような事でも、できるだけ合理的な方を選びたいです。

> ネストを避けるための式は右側に書いちゃう。
> それ以外で中括弧はいつもつける。elseがなくてもつける。
参考になります。
確かにreturnなどは1行が長くなる事が少ないですし、if文の右側でもいいですね。

>>362,363
やはり中括弧は省略しない方がいいんですね。
2009/11/27(金) 22:05:58
お前らLinux KernelとGNUのコーディング規約調べてみｗ
2009/11/27(金) 22:11:31
Linuxカーネルは、単文を中括弧で囲むのを基本的に禁止してるね。
if文の分岐の片方が単文な時だけ、特例として中括弧で囲うルールだったはず。
2009/11/27(金) 22:54:07
後から追加して複文になったときの問題だけじゃなくて、
if-else のネストで意図したものと異なる方に
else がくっつくことがあるって問題もあるんだぜ
2009/11/28(土) 03:28:03
それでもLinuxは無駄な中括弧を排除してるし、それであの巨大プロジェクトが一応は
問題なくやれてる訳だよな
ぶっちゃけ、こだわるほどのことではないんだろ
2009/11/28(土) 13:16:28
Linuxいじるような人は概ねレベルが高いだろうから問題ないんだろうな
というイメージだが、実際の所どうなんだろう
2009/11/28(土) 13:29:00
しっかり統一できてればいいんじゃね
2009/11/28(土) 13:49:06
VC使っててもミスる人いるのに
vimやemacsで大丈夫なの？
2009/11/28(土) 21:56:34
ミスとか以前に、他の複数行のif文と見た感じが統一されなくて気持ち悪いのは俺だけ？
2009/11/28(土) 22:21:16
統一性は別に気にならないな
単一文 if は単一文 if で統一されていれば
2009/11/29(日) 02:03:11
ぶっちゃけ、if-breakやif-returnまで中括弧入れてると冗長感はかなりあったから、
俺はLinux方式の方が好みかな
Perlなんかは逆に中括弧の強制が言語的に決まってたりするし、それはそれでいい
と思うけど（つーかPerlはreturn ifとかand returnとか好き放題に書けるしな）
2009/11/29(日) 09:11:32
rubyみたいなif修飾子があれば最高なんだよな。
next if condとかってスカッとする。
2009/11/29(日) 18:16:18
Perlのstatement modifierをそのままパクった奴だな
さらにそのパクリ元はBASIC/PLUSらしいが、どういう言語かシラネ
2009/11/29(日) 21:10:43
else if () は中括弧なしの単文だよな。


>>368
Linux はコードのチェックインの前に基本的に
Kernel ML へのパッチ提出でレビューを経るから
抜けはそこで指摘できる。

一人でコーディングするなら後任のことも
考えて {} つけといたほうがいい。
2009/11/30(月) 02:01:45
そんなのミスる奴は、悪いけど擁護しきれないレベルだと思うんだが
まともかつ慣れた奴でそんなミスをやる奴っているの？
2009/11/30(月) 16:36:53
都市伝説だと思うよｗ
2009/12/02(水) 01:12:47
>>378
新人をいきなり投入ってあるよ。
ま、一人に投げっぱなしじゃないけど、
char *foo(void)
{
　　char buff[128];
　　。。。
　　return buff;
}
みたいなコード書くヤツでも平気で
投入されてくるから要注意だｗ


そういえば、
for (...);
{
/* 何かの処理 */
}
で、ループの中が一度しか実行されない病
にはまった事はあるｗ
381デフォルトの名無しさん
垢版 |
2009/12/05(土) 00:53:50
人いないのかよ。

ぬるぽ！
2009/12/05(土) 02:18:36
>>381 ガッ
2009/12/05(土) 09:47:04
対応する中括弧のインデントの階層を同じにしろといつも思ってる
なんでみんな階層変えて書くの？死ぬの？
2009/12/05(土) 11:38:34
>>383 が言いたいのは

if (...) {
}

スタイルは嫌いだ、ってこと？
2009/12/05(土) 18:53:46
一つのクラス内やファイル内に記述する関数やメソッドの順番ってどうしてる？
たとえばCで f1()からf2()とf3()が呼ばれて、f3()からf4()が呼ばれる場合、自分は
void f2() { ... }
void f4() { ... }
void f3() { f4(); ... }
void f1() { f2(); ... f3(); ... }
のように、呼び出される関数を上の方に書いてるんだけど、
呼び出される関数を下の方に書くスタイルもあるよね。
こういう理由でこういうスタイルにしているというのがあれば教えて。
2009/12/05(土) 19:12:42
トップダウンで実装してる時はトップダウンで。
ボトムアップで実装してる時はボトムアップで。

# コーディング規則があるときや、既存のプロジェクトでは他に合わせて。
2009/12/05(土) 20:35:30
>>385
eclipseにメンバをソートする機能があるから、それでアルファベット順にソート。
2009/12/06(日) 00:23:38
>>385
プロトタイプ宣言はつけてるのでどんな順番でもいいのだが、
追加・変更した関数を上に持ってくる。 だいたい
いじる関数は決まってるからな。

自然と、下に行くほど枯れた関数ということになる。
機能単位でまとめられるようであれば別ファイルに
くくり出すときに雑魚は下の方でソートしてる。


起動時間などの最適化をかけるために順序を
変えることもある。 起動時に使うものをなるべく
一箇所に集めて上に持ってくるとか。
2009/12/06(日) 00:49:16
宣言を繰り返すのが面倒だから、呼ばれる側が上。
自然とファイルローカルな関数が上に来て、外部関数は下に来る。
ヘッダで宣言してる外部関数は、ヘッダでの宣言順にあわせる。
2009/12/06(日) 11:46:02
他人のソースをいくつか読んでみて、
見やすいのと見難いので比較してみれば？

わしは前フリ長いの嫌いなんで、上位の関数を
上に書いて欲しい。 わからないところだけ下を見る。


つか、クラスで最初に private もって来る奴とかいないだろ？
それと同じことじゃね？
2009/12/06(日) 12:08:47
>>390
ふつーにいるだろ? privateを最初に書くの。
2009/12/06(日) 12:09:15
if(hoge)
if (hoge)
if( hoge )

どう書く？
カッコが入れ子になった場合に一番見やすいのは最後だと思うが野暮ったい
2009/12/06(日) 12:13:30
if (hoge)

関数やマクロの場合は hoge(...) と、カッコの前を空けない。
if (...), for (...), while (...) などは空ける。
2009/12/06(日) 12:29:09
>>392
2番目がふつー。
2009/12/06(日) 13:13:26
if ( hoge )
だな。

for, while も同様。
2009/12/06(日) 13:17:05
カッコの内側に空白を入れるのは、マイクロソフトのサンプルとかが
そのスタイルだよね。
2009/12/06(日) 13:20:39
MSはC++では1番目，C#は2番目
2009/12/06(日) 13:21:20

訂正C++は3番目
2009/12/06(日) 13:24:19
今MSDNのサンプルで確認したら統一されてないな。
あったりなかったり。
カッコの内側のスペース。
2009/12/06(日) 13:28:46
VS2008のオートフォーマットは、デフォルトでは、C#はカッコの
内側にスペース入れない設定。
C++は、設定項目がなかった。
401デフォルトの名無しさん
垢版 |
2009/12/07(月) 17:33:08
一番大切な事は、それを書いて自分が何を感じるかだ
2009/12/07(月) 19:33:21
>>401
もちろんコスモを感じる
2009/12/08(火) 00:30:35
ブランクを感じる。

ごめん、書いてみたかっただけw
404385
垢版 |
2009/12/08(火) 12:23:16
なるほど、色々参考になった。
自分の場合、ソースの流れを追うときに、呼び出される関数が上にあるか下にあるかが
あらかじめ分かってた方がスムーズに追えるかなと思うんだが、順番を気にしない人が
けっこう多いんだね。
2009/12/08(火) 13:46:29
>>404
というより、関数の間に依存関係がありすぎるのはキモイ。
>>385の例で言うとf1->f3->f4ていうのが深い。

俺ならpublicなインタフェースに対し、その実装から、
privateなメソッドを一回呼び出したりする程度。
だから順番としては、（基本、互いに呼び出しあったりしない）publicなものを上にババーと書いて、
下のほうにprivateなメソッドをコソコソと書く。_fなどとprefixをつけて名前を汚して書く。
2009/12/08(火) 13:52:38
>>405
関数の深さ制限って、何のため？深くて何が悪いの？
「そろそろ関数分けるか・・・あ、もう３段目だ。やめとこ。」とか言っちゃうの？

名前を汚すって、何のために？
private なりファイルローカルなり、もっとマシな仕組みが言語側にあるでしょ？

どっちも意味わかんない。
2009/12/08(火) 14:06:17
> 「そろそろ関数分けるか・・・あ、もう３段目だ。やめとこ。」とか言っちゃうの？

言わない。「そろそろ関数分け」たりしない。
適切に設けられた関数は既に簡潔に表現されてる。
結果、そんなに呼び出しが深くなったりはしない。

> 名前を汚すって、何のために？

すまない、完全にこれは蛇足。
privateでかつ、仮状態のメソッドを区別するためにそうしてるだけ。
汚い名前をつけとくと、落ち着かないでしょ？
キレイな名前がつくときは、整理されて明確な役割を担ったとき。
ま、この話題はどうでもいいな。
2009/12/08(火) 14:31:20
f1(){ f2(); f3()}
f2(){ f3(); f4()}
f3(){ f4(); }

のようにスパゲティに依存してるのはちょっと気持ち悪いが、
単に深くなるのは気にしないな。

ていうか関数が2層しかない、って相当単純なものしか書いてないんじゃないの？
2009/12/08(火) 14:36:58
>>407
関数の表記が簡素であることと呼び出しの深さがどう関係するの？

…あ、もしかして「適切にファイル分割された状態であれば、ひとつの
ファイル内でそんなに深くなることはないはず」ってこと？
2009/12/08(火) 14:39:14
> 言わない。「そろそろ関数分け」たりしない。
> 適切に設けられた関数は既に簡潔に表現されてる。

事後の関数分けをしないでもいいって、どんな神プログラマだよｗ
2009/12/08(火) 14:41:21
> ていうか関数が2層しかない、って相当単純なものしか書いてないんじゃないの？

しらんがなｗ

それと、二層どころか、ほとんどは一層だよ。
publicなメソッドから、同じクラスのほかのpublicメソッドを呼び出したりはしない。
メソッドのオーバーロードの場合は除いて、ね。
publicメソッドからたまーに、privateなメソッドを呼び出したりするだけ。

だから、publicなメソッド同士の記述の順番なんぞどうでもいい。
なぜなら、そこに呼び出しあうような関係は無いから。
privateメソッドがそれらの間にあると読みにくいと思うから、
上のほうか、下のほうにまとめておく。邪魔だから。
2009/12/08(火) 14:42:14
> 事後の関数分けをしないでもいいって、どんな神プログラマだよｗ

残念、俺は糞プログラマだよｗ
2009/12/08(火) 14:42:55
底辺はリファクタリングを知らない。
2009/12/08(火) 14:47:21
>>412
なんだ。そうか。納得した。

自覚があるなら >405 みたいなミスリーディングな主張は控えていただきたい。
2009/12/08(火) 15:38:25
コーディング規約の大半は普通のプログラマのためではなく、
あなたの隣に座っているプログラマのような何かが生産し続ける、
見ただけで死ぬような目潰しコードを多少は見られるようにするという
崇高な試みのために存在する。
2009/12/09(水) 00:16:00
むしろコーディングに主義主張を持つ俺らみたいのが二人以上いると
宗教戦争を起こすので「めんどくせえからこーしとけ」的なルールな気もｗ
417385
垢版 |
2009/12/09(水) 02:05:52
>>411
なるほど。たしかにメソッドの記述の順番が気になる箇所は、
関数をどんどん深く呼び出してる箇所とほぼ一致してるなあ。
そういう箇所はコードが読みにくいというよりも、そもそも
クラス構造に問題がありそう。
そういった、クラスの構造や粒度などについて書かれてる
書籍でおすすめのものがあれば教えてくれるとうれしい。
2009/12/09(水) 12:10:51
ソースを上から順に読むとか、飛び先を目で探すとかってことは
めったにないんで、べつに順番はどうでもいい。
気になるんだったら、アルファベット順にでも並べとけばいい。
419411
垢版 |
2009/12/09(水) 13:29:14
>>417
まず大前提としてはKISS(Keep it simple, stupid)があって、
これはいつまでたっても我々にとって有効な指針になると思う…。

「Cプログラミング診断室　藤原 博文」
　構造化のテクを磨くことも大事。楽しい読み物。
　余計なことやヘンなことはしない、ということの大事さが分かる。

「リファクタリング　マーチン ファウラー」
　目新しさは無いかもしれないが、押さえておいていいかも。

「オブジェクト指向における再利用のためのデザインパターン　GoF」
「オブジェクト指向入門 第2版 原則・コンセプト　バートランド・メイヤー」
　自力で独学でOOP能力を高めていくのも大事だけど、
　OOPとは何ぞや、優れた設計とは何ぞや、を本から学びたければ。
　個人的に、デザパタ本は手垢で黒くなってきてるほど読んでる。

> クラスの構造や粒度などについて書かれてる書籍

で、肝心のコレはちょっと思いつかないｗ

ただ、図書館行って片っ端から技術書立ち読みしたら、
それっぽい本にきっと出合えると思う。
アジャイルなんたらっていう赤い本も面白かった気が。
技術系MLアーカイブを追っかけたり
（ttp://java-house.jp/ml/topics/topics.html#style）
するのもいいかも。なんかいい本あったら教えてｗ
2009/12/09(水) 13:35:48
Ｃプログラミング診断室
ttp://www.pro.or.jp/~fuji/mybooks/cdiag/index.html

これならお手軽に読める。内容はちょっと古いかもしれないし、
内容のすべてに同意できるとは限らないけど、
ある程度の距離を保って読めば、やっぱ今でも面白いかと。
2009/12/10(木) 00:01:11
カーニハンの「プログラミング作法」ぐらい読んどけよ。
2009/12/10(木) 00:09:02
診断室で一番共感したのは、糞グラマを無理に使うくらいなら切り捨てた方がマシ、
ってとこだな
423385
垢版 |
2009/12/11(金) 01:01:26
>>419,420
ありがとう。「Cプログラミング診断室」読んでみる。
2009/12/12(土) 02:46:17
関数を分割するべきか否かを、関数の行数や
if等のネストの深さで、機械的に判断するのは間違い。
…などと書いてみるテスト。

一連の処理の固まりを、「処理内容が大体想像できる一文」で
置換する（記述を要約する）のが正しい関数化の手法であって、
行数等を判断基準に関数化するというのは、
ぶつ切りしてるに過ぎないと思う。

でもってこの「〜する」の一文を見つけたり、まとめられるように
フローをアレンジする能力ってのが、プログラムのセンスって奴だと思う。
2009/12/13(日) 00:14:47
バカを統制するのには機械的な基準はある程度有効
2009/12/13(日) 00:28:09
「こういうコーディングスタイル、ダサいよな」みたいな話題で、
わざわざ「俺はバカどもを使ってるから仕方なくやってんだよ」って
反論してくるやつって、実は本人がそのダサいスタイルなんじゃないかって
気がしてならない。
2009/12/13(日) 18:32:43
無能プロジェクトリーダの決める規準より言語設計者の決めるものの方がまし、
という意味で、言語がこと細かにスタイルを規定して欲しい。
2009/12/13(日) 19:15:24
Pythonのことか
2009/12/13(日) 20:28:37
>425
関数名（+引数等） = 処理内容の要約となるよう設計（分割）すべき、
ってルールはさほど難しく無いと思うんだ。

…と思ったけど要約できん奴は、ダラダラ書くんだろうな…
ダラダラ書かせない為に機械的制限は有効だと思うけど、
えてして基本が忘れ去られてる、と思うんだ漏れは。
■ このスレッドは過去ログ倉庫に格納されています
5ちゃんねるの広告が気に入らない場合は、こちらをクリックしてください。
ニューススポーツなんでも実況