09/09/25 11:26:08
そんなルールおとなしく守ってるプログラマなんてほんとにいるの？
何なの？ばかなの？しぬの？
311:デフォルトの名無しさん
09/09/25 12:08:10
>>310
元請けにコードの監査部隊がいて意地でも書き直させる方法を取っていた
うざくってしょうがなかった
312:デフォルトの名無しさん
09/09/25 12:10:14
その監査部隊を短絡評価の講習要員にすればいいのに。
313:デフォルトの名無しさん
09/09/26 21:43:06
308の書き方だと、正しく読めない/書けない奴が居るから仕方が無い。
一方、漏れらに308の書き方を強制しても、せいぜい能率が落ちるだけ。
実戦の世界じゃ、手駒の性能を上げるよりは数を増やす方が効果的だしな。
平均能力UPの為に手駒を減らすより、平均能力を下げてでも手駒を増やそうってのは
冷徹ではあるが正しい方策。
314:デフォルトの名無しさん
09/09/26 23:32:37
へぼいコーディングルールの話になると、その理論がよくでてくるけど、実際はコーディングルールを
決めてるやつがヘボいだけだろうな。ほとんどの場合。
それに「ヘボいヤツを使うためにヘボいコーディングルールが有効」理論が、本当に正しいかすごい疑問だし。
315:デフォルトの名無しさん
09/09/26 23:42:03
まぁ俺の持論とは真逆だな
ウンココーダの頭数揃えても、精鋭一人にも劣る
316:デフォルトの名無しさん
09/09/27 09:34:49
> 実戦の世界じゃ、手駒の性能を上げるよりは数を増やす方が効果的だしな。
> 平均能力UPの為に手駒を減らすより、平均能力を下げてでも手駒を増やそうってのは
> 冷徹ではあるが正しい方策。
「人月の神話」に燦然と挑戦しているな。
まぁそのような開発分野もあるんだろう。多分。
317:デフォルトの名無しさん
09/09/28 09:09:58
「ヘボいヤツを使うためにヘボいコーディングルールが有効」理論は確かに疑問だが、
十分な精鋭を確保できるプロジェクトなんてほとんど無いんだから、大量のヘボが存在
するのは前提だと思う。
加えて上司も無能だと、そのヘボが逐次投入されてチームは恐竜に、プロジェクトは
タールの沼に。
318:デフォルトの名無しさん
09/09/29 21:53:42
>316
そうでもないと思うが。
1つのプロジェクトに投入する人員については、「人月の神話」の理論で良いけど、
複数のプロジェクトに人員を配置する場合は、>313の理論の方が適している。
308みないなルールは大規模なプロジェクトほど多く、小規模なプロジェクトほど比較的フリーだろ?
（逆な例もある事は承知している）
319:デフォルトの名無しさん
09/09/29 21:57:10
短絡評価が分からないだけならまだしも、「教えても理解できない」という人員なんか
さすがに切り捨てても困らないと思うけどな
320:デフォルトの名無しさん
09/09/29 22:31:14
簡単なコードを量産するような人海戦術プロジェクトでも、上位の2,3割だけ使って、
のこりはじゃまにならないように遊ばせておいても、あんがい生産性あがるんじゃないかって気もする。
321:デフォルトの名無しさん
09/09/29 23:13:59
>>318
人月の神話、読んでないか忘れてるだろ。
>>319
短絡評価に限って言えばその通りだけど、教えられても理解できない部分は人によって違うから。
>>320
論文報告を楽しみに待ってる。
322:デフォルトの名無しさん
09/09/30 00:10:59
どうでもいいけどstrlen()が返すのはintじゃなくてsize_tだよ
323:デフォルトの名無しさん
09/10/01 20:40:57
ストレンツォ容赦せん！
324:デフォルトの名無しさん
09/10/11 14:52:50
>>318
つまり、たとえば優秀なプログラマなら3ヶ月で終わる仕事を一年かけて
（原則同じくらいの人数で）やるけど、
同時に抱えられるプロジェクト数を増やして会社としてのスケールメリットを得るって話？
要するに節約できるのは総務だの人事だのの管理コストの話であって
プロジェクトそのものの効率は上がってないと思うが…
325:デフォルトの名無しさん
09/10/12 02:57:19
>324
プロジェクトの効率は上がらなくても、利益は上げられる罠。
場合にもよるが。
下手すりゃ投入人員と期間を増やせばその分儲かる。
糞ルールがまかり通ってる現場って、大体は上がこんな思想で動いてる希ガス。
326:デフォルトの名無しさん
09/10/12 03:57:31
まぁ、その思想を最高だと思って布教しようとしたりしなきゃどうでもいいけどな
327:デフォルトの名無しさん
09/10/17 11:55:45
javaで
public void XXX() throws YYY, ZZZ {
}
のthrows以下が長くなると80桁超えますけど見やすい折り返し方ないですか？
eclipseのデフォルトで整形すると
public void XXX() throws YYY,
ZZZ {
}
とやってくれましたけど見づらいな。
328:デフォルトの名無しさん
09/10/17 12:44:58
>>325
思想とか計算づくで、レベル低いんじゃなくて、ただレベル低いだけなんじゃないの?
効率が利益に結びつかないから、淘汰されないだけで。
329:デフォルトの名無しさん
09/10/18 21:42:59
>>324
保守要員みたいなところにエース級は投入せんだろ。
むしろ OJT で勉強させるために新人を。。。
330:デフォルトの名無しさん
09/10/20 11:51:05
>>327
行が長くなるときどう折り返すか
URLﾘﾝｸ(java-house.jp)
331:デフォルトの名無しさん
09/10/20 12:09:53
C++ 使っててカンマとか演算子の「前」で折り返して、演算子の類が行頭にくるように
してたんだけど、 Python 使い出したらそうもいかなくなって、今は微妙な気持ちです。
332:デフォルトの名無しさん
09/10/20 12:20:08
>>331
英語では普通、カンマやセミコロンなどは単語の後ろに空白なしにつける。当然、改行はその後。
演算子もそれに準じる。
333:デフォルトの名無しさん
09/10/20 13:57:32
>>331
（ ・∀・）人（・∀・ ）ﾅｶｰﾏ
.append(foo)
.append(bar)
.toString();
+ fooooooooooooooooooooooo
- (baaaaaaaaaar % baaaaaaaaz);
= {
11111111111
, 2222222222
, 3333333333
}
if (
(cooooooooooooooond)
|| (baaaaaaaar && bazzzzzzzz)
)
文末を見るより、文頭を見るほうが目の動きが少ない。
334:デフォルトの名無しさん
09/10/20 14:05:42
. を先頭にもってくるのは許せるが、 , を先頭にもってくるのが許せないのはなぜだろう。
335:デフォルトの名無しさん
09/10/24 22:25:29
if ～ else if ～ else の各節にコメントをつけたいとき、俺はこのように書いているんです。
// こういう場合はこう
if (...)
{
}
// こういう場合はこう
else
{
}
ところが、節を分断するのはよくないと言う人がいるんですね。それはそれで一理あります。
その人はこう書いている。
if (...) // こういう場合はこう
{
}
else // こういう場合はこう
{
}
このやり方だと、条件式が長くなったり複数行にわたると、ちっと面倒なことになる。
みなさん、if文のコメントはどのように書いていますか？
336:デフォルトの名無しさん
09/10/24 22:35:25
>>335
if にコメント付いてれば else へのコメントは冗長だろ？考えるだけ無駄。
337:デフォルトの名無しさん
09/10/24 23:21:52
冗長なんて言ったらコメントなんて書けなくなる。
それに複数のelse ifがある場合はコメントがあった方がいい。
338:デフォルトの名無しさん
09/10/25 00:16:58
>>337
お前はなんのためにコメントが書きたいの？
コメントを書くことが目的なの？
339:デフォルトの名無しさん
09/10/25 01:41:21
// コメント
if(...) {
}
else {
// コメント
}
340:デフォルトの名無しさん
09/10/25 02:39:09
>>339
俺もそれだ。
341:デフォルトの名無しさん
09/10/25 02:43:33
俺はこうだわ。space efficiant!!
if(...) { // コメント
foo();
} else if(...) { // コメント
bar();
} else {
foobar();
}
342:デフォルトの名無しさん
09/10/25 07:39:57
漏れは内容に応じて使い分けた方が良いと思うけど。
// 分岐全体について。
if( ... ){ // 式について。
// ブロック内の処理&実行条件の概要
}
else {
// ブロック内の処理&実行条件の概要
}
（例）
// ～と～を切り分ける
if( … // ～をチェック
&& … ) { // ～をチェック
// ～の場合、～する
}
else {
// ～の場合、～する
}
343:デフォルトの名無しさん
09/10/25 14:06:52
こうしてる
if(...) {
// ...なら～
} else {
// ～(条件についての記述は無し)
}