コードの行数を減らすと生産性があがりバグも減る @ [プログラマー板]

2020.3.25 21:01
カテゴリー : コンピューター
[ありがちなこと] . [理系考察] . アプリケーション . コメント . コーディングスタイル . シンプル . ステップ数 . スパゲッティコード . ソフトウェア . ソースコード . ネスト . バグ . メンテナンス . ワンライナー . 三項演算子 . 修正 . 可読性 . 生産性 . 行数 . 開発 . 関数 . 類似性
コメントを書く

1: 仕様書無しさん 2015/09/12(土) 10:34:48.38 ID:.net

この事実を発見してから我が社では既存のコードを修正し、行数（正確にはステップ数）を極限までに減らす修正をすることで、バグを大幅に減らして生産性も大きく上げる事に成功した。

2: 仕様書無しさん 2015/09/12(土) 11:41:44.60 ID:.net

>>1
可読性まで犠牲にして逆にバグが発見でき無いコードにならんようにな。

3: 仕様書無しさん 2015/09/12(土) 14:50:35.49 ID:.net

縦スパゲッティか横スパゲッティの違いじゃないの？

5: 仕様書無しさん 2015/09/12(土) 15:09:44.46 ID:.net

全部1行で書けば良いんだな。

6: 仕様書無しさん 2015/09/12(土) 16:24:51.96 ID:.net

アホやw

行数よりも、コードの見やすさとコメント量の方が大事
誰が見てもわかりやすいコーディング
メンテで差がつく

7: 仕様書無しさん 2015/09/12(土) 16:30:30.70 ID:.net

でもコードの行数がすくなければ、メンテする量も減るんですよ。

8: 仕様書無しさん 2015/09/12(土) 17:00:07.26 ID:.net

>>7
そりゃ、処理、機能がないんだからそうなるなw

9: 仕様書無しさん 2015/09/12(土) 18:01:10.45 ID:.net

コメントも多すぎると、そのコメントのメンテナンスも必要になるから、コメントも少ないほうがいい。

10: 仕様書無しさん 2015/09/12(土) 18:06:43.59 ID:.net

>>9
おまえが文章書くのが苦手なのは分かった。

14: 仕様書無しさん 2015/09/12(土) 18:54:26.57 ID:.net

こんなん当たり前の話とちがうん？
昔のエライ人が言ってだろう？

「シンプル・イズ・ベスト」

簡単なモノは壊れにくい。複雑なモノほど壊れやすい。
これはプログラムコードにも当てはまるんよ。
俺はもう設計屋だから、コード書かせるときに必ず若いもんにこれ言うわ。

15: 仕様書無しさん 2015/09/12(土) 19:50:30.60 ID:.net

>>14
その当たり前のことが出来ないんだよね。
ソフトウェアの難しいのは、バージョンアップしていく所。

大きい物と小さい物は作り方が違うんだけど、小さく作って大きくしていく時に、既存の部分を大きい作り方に直さないといけないんだけど、「既存の部分に手を付けるな」とかいう馬鹿な奴が指揮をとると、どんどん複雑になって手がつけられなくなる。

既存の部分を修正すれば、1.1の量で済むことが、手を付けれないからコピーして、2になる。

19: 仕様書無しさん 2015/09/13(日) 00:11:27.61 ID:.net

>>1
生産性の定義すら提示してないから、もともと議論する気はなさそうだな。

20: 仕様書無しさん 2015/09/13(日) 00:22:41.16 ID:.net

生産性の定義なんか必要あるのか？

37: 仕様書無しさん 2015/09/16(水) 00:26:51.04 ID:.net

>>20
お前だけ、経営者が決めた生産性でやってれば良いんじゃね？

22: 仕様書無しさん 2015/09/13(日) 04:20:58.66 ID:.net

シンプルなソースと行数は相関関係がないと思うんだが
一行に纏めて読みづらいif文よか、5行でも読みやすい方が保守工数は減るんでね

24: 仕様書無しさん 2015/09/13(日) 18:00:38.85 ID:.net

>>22
共通関数用意してるのに使えないから、誰も使わなくて至る所で同じような処理が行われてるとか、しかもそれが微妙に違うから、各モジュールでデータをやり取りするときに、変換かけないといけないとかそういうのは？

管理人より：共同作業あるある

25: 仕様書無しさん 2015/09/13(日) 18:20:29.09 ID:.net

つまりなんだ、このスレはソースコードの負の遺産の話でしょ
ゴミや糞は片付けよう！

26: 仕様書無しさん 2015/09/13(日) 18:20:46.50 ID:.net

少ない行で書けるシンプルなコードを書けということで、行数を減らすのが目的ではないよな

28: 仕様書無しさん 2015/09/13(日) 21:06:13.85 ID:.net

行数が問題なんじゃねえよ
instructionが少なくなるように書けっつってっだろ？

29: 仕様書無しさん 2015/09/13(日) 23:10:18.70 ID:.net

>>28
>>1の

> 行数（正確にはステップ数）を

を読んでますか？

31: 仕様書無しさん 2015/09/14(月) 07:09:08.63 ID:.net

>>29
はあ？instructionだよアホ
頭ん中で簡単なアセンブリしながら書けっての

管理人より：「instruction」はここでは「説明」「ヘルプ」「指示書」のような意味。コードを読めば簡単にわかるようにしとけ、ということかと思う。

30: 仕様書無しさん 2015/09/14(月) 01:53:05.12 ID:.net

ワンライナーってやつか

32: 仕様書無しさん 2015/09/15(火) 02:02:28.77 ID:.net

if文に関数コール埋め込んだりすると、行数は減るがデバッガで追いにくくなるんだが

34: 仕様書無しさん 2015/09/15(火) 12:33:59.71 ID:.net

>>32
最近はデバッガで追うようなことはしなくなってるよ。
まずはテストコードが書けるようなシンプルな関数を作る。
テストコードがあればデバッガはほとんど必要ない。

36: 仕様書無しさん 2015/09/15(火) 22:26:56.30 ID:.net

>>34
いいこと言うなあ
その通りだよな

38: 仕様書無しさん 2015/09/16(水) 01:38:23.18 ID:.net

>>34
テストが通らないときはどうするの？

39: 仕様書無しさん 2015/09/16(水) 04:29:24.38 ID:.net

>>38
ソースコードを眺めて（セルフレビュー）して間違いを見つける。
これができない＝コードが複雑ということ

40: 仕様書無しさん 2015/09/16(水) 06:56:26.57 ID:.net

>>39
のんびりとした開発してるんだね

33: 仕様書無しさん 2015/09/15(火) 08:42:35.42 ID:.net

三項演算子とかも二重三重にまとめ書きして行数減らすのが推奨？
解読困難になるけど

35: 仕様書無しさん 2015/09/15(火) 20:55:41.82 ID:.net

コーディングスタイルで行数を減らすって話じゃないだろ
その機能を実現するのに最適なロジックを選択したら行数も減るってことの裏返しを言ったんだよな？>>1

52: 仕様書無しさん 2015/09/18(金) 21:01:01.79 ID:.net

同じコードを2度書くな
大切なことだからもう一度書いとくよ
同じコードを2度書くな

コードの行数は減ることが多い
単体レベルのテストは減る
同等のコードなので生産性は上がらない
コードが分散しないのでバグは減る

同じコードを2度書くな(大切なのでry
違和感があるときはリファクタリングのタイミング

53: 仕様書無しさん 2015/09/19(土) 10:38:44.77 ID:.net

>>52
二度以上書かないとならない数行のコードなんて普通にあるから。
おまいの書いた内容程度の行数なら何回でも同じコードを書いてもいいよw

56: 仕様書無しさん 2015/09/19(土) 11:58:18.51 ID:.net

>>52
大切なことだから何度も同じコードを書いてるってこと？

54: 仕様書無しさん 2015/09/19(土) 11:09:54.23 ID:.net

類似性のある複数のコードは、相違点だけを引数とかで吸収するようにして纏めてしまえ、てことなんでしょ
纏め方も、サイズ重視か速度重視かで関数なのかマクロなのか変わるだろうけど

58: 仕様書無しさん 2015/09/19(土) 15:37:44.61 ID:.net

>>54
似てるからまとめました
は後でメンテするときに非常に迷惑。

59: 仕様書無しさん 2015/09/19(土) 15:38:44.41 ID:.net

むしろ、似てないけど同じ意味だからまとめましたを推奨すべき

75: 仕様書無しさん 2016/04/22(金) 04:24:44.03 ID:.net

同じような処理はメソッドにまとめろってことだろ
それはそのとおりだ

61: 仕様書無しさん 2015/09/19(土) 17:04:29.25 ID:.net

うむ、コピペ推奨だな

62: 仕様書無しさん 2015/09/19(土) 18:44:30.51 ID:.net

コピペはそれはそれで間違えるんだよな
コピペのあと一箇所変更しないといけない、みたいな時に変更忘れたり間違えてたり

67: 仕様書無しさん 2015/10/26(月) 06:17:13.37 ID:.net

アプリケーションの生産性と、アプリケーションを構成するソースコードの情報エントロピーの相関から情報理論を組み立てている人がいるよ。
その人は今、その情報理論に基づいて、

Coop Lights
でライセンスやアーキテクチャを作っているみたいだけど、スレ主は注目する価値があると思うよ。

68: 仕様書無しさん 2015/10/26(月) 06:23:57.53 ID:.net

>>67
その人にサイトの可読性が悪いって伝えておいて
目がチカチカする

72: 仕様書無しさん 2016/02/16(火) 23:19:25.13 ID:.net

職種にもよるが、業務系であればコードの整理よりも扱ってるデータの整理が最優先。
データを整理・管理・保守しやすい形にすればコードは自ずとスマートになる。
コードは結果だお。

73: 仕様書無しさん 2016/02/18(木) 19:35:31.47 ID:.net

それをデータ中心設計といってだな。

79: 仕様書無しさん 2017/06/07(水) 03:32:59.03 ID:.net

なんで「Code Complete」を参照しないのかわからんね
第二版（上巻）の7.4で

・ルーチンは100～200行に増えてもよしとすべきである

・200行を超えるサイズのルーチンについて、コストの低下、エラー発生率の低下、またはその両方を報告している調査は一件もない

と、マコネルがすでに調べてくれている

80: 仕様書無しさん 2017/06/07(水) 03:51:07.75 ID:.net

マコネルのはPythonみたく「コードは全部数式みたいにワンライナーしてるのがキモチイイ！」みたいなグイドの発想は反映してなかったと思うんでアレだが、切り詰め主義はお勧めできない

ワンライナー主義ってのは、意味論的にはネストかましてるのと一緒だから、状況がアレでも3段、どんだけひどかろうが4段(ジャグドアレイとか行列あつかってたらあり得る）それ超えたら後のメンテに影響する

平均的な人間なら変数とか全部含めて7コ以上の何かを超えたら、脳みその短期記憶からなんか落ちる、ってのは心理学の世界で知られてることだ

83: 仕様書無しさん 2017/06/07(水) 12:27:35.40 ID:.net

コードが長いからダメ
コードが複雑だからダメ

んなこと言ってる奴は向いてないから辞めれw

84: 仕様書無しさん 2017/06/07(水) 23:40:41.09 ID:.net

>>83
ダメではないが後日の改修時に「コードを読んで改修ポイントを断定する」の工数が伸びて無駄遣いになるから褒められたことではない、程度

85: 仕様書無しさん 2017/06/08(木) 08:39:09.36 ID:.net

改修しなきゃコメントなんていらねーんだよ。
改修なしでいいほどの良プログラマもいないだろうけと。

89: 仕様書無しさん 2018/09/30(日) 00:45:58.26 ID:.net

>>1
マルチステートメントでもしてろ社会の癌め

90: 仕様書無しさん 2018/09/30(日) 20:53:15.33 ID:.net

当たり前のことを言われても…・

馬鹿ほど、いろんなことを想定して汎用性のあるプログラム書こうとして大変なんだよ。
そして無駄にコードを長くする
実際には再利用はされても変更が発生するときには、さほどの汎用性は役に立たないことが知られているのに。

91: 仕様書無しさん 2018/10/12(金) 21:38:40.86 ID:.net

廃棄できるコードなら良いだろ。
gotoスパゲッティで書かれたコードなんか、簡単に破棄なんて出来ないぞ。何が起こるか予想できないからな。

93: 仕様書無しさん 2018/10/14(日) 16:23:55.44 ID:.net

下手なやつほどコードが長くて複雑
確かにこれは真理だは

シンプルに短くというのはマにとっては永遠のテーマでしょうかねぇ。

下手なやつほどコードが長くて複雑

という最後に持ってきたこれ。特にマ初心者のころっていうのは、長く複雑なロジックを問題なく動かせることにカタルシスを感じたりするから、まったく厄介な性質なのです。
デザイナーなんかもよく似てる。初心者デザイナーは、とにかく奇をてらうデザインをしたがるものですが、しかしどちらも、やがては自分の間違いに気づくことでしょう。

というわけで、短くてシンプルなコードにバグが混入しにくくメンテも容易なのは、まぁ当たり前なのですが、要求される動作は満たさなくてはならず、これがなかなか難しいですね。
スレでは、シンプルさと長さは別に相関関係にないとか、ワンライナーにこだわると可読性もメンテ性も落ちるよとか、むしろコメントやデータの取り扱いを気をつけろとか、メソッド（あるいはサブルーチン）にまとめるのは意味の類似か目的の類似か…などなどと語られています。

どれも別に間違ってはいないと思うけど、バグの出やすさに関して言えば、もうマ本人の資質によるところのほうがずっと大きいと思う。平たく言えばどうやってもバグを出すマは出すし、出さないマは出さないです。
複雑な要求を短くシンプルにとか、ロジックは細かく分割して再利用しろとか、口でいうのは簡単ですが、ちゃんとやるには経験が必要ですよね。
管理人はシンプル短くは最初からはできなかったけど、バグについては初心者のころからほとんど出さなかったので、あまり関係なさげというか、やっぱり几帳面かつ注意深いとか、秩序や整理分類を愛するとか、そういうほうが効果がでかいと思うな！

Code Reading ~オープンソースから学ぶソフトウェア開発技法~ (プレミアムブックス版)

Generated by Hakase Channel at 20.3.24

ランキング: 本 - 236,173位 (売れ筋を見る)

Amazon.co.jpで詳細を見る

元スレ：http://nozomi.2ch.sc/test/read.cgi/prog/1442021688/

- ※1 : ドクター・ノオ・ネーム
- 2020.3.25 23:29
- 返信
- 引用
SICPとか読んでたら、そんなの当り前じゃないの？
- ※2 : ドクター・ノオ・ネーム
- 2020.3.26 8:35
- 返信
- 引用
オトナノジジョウのせいで該当箇所に手を入れられずにどんどんスパゲッティになっていくのって、ほんと腹立たしいわ。
うちの会社でも「オレの技術ステキ」って鼻高々にひとりで誇ってる管理職がぐちゃぐちゃ言うから、必要があるから触るって言うてんのにそれを止められて、同じようにスパゲッティになってってる。
そのくせスクラッチのときはインジェクションが～とか共通化が～とかとかとかカッコイイこと言うんよな。
確かに「いじった箇所はテストする」の範囲が広がるのは避けたいって気持ちもわからなくはないけど、それのせいで更にあとでテストする範囲が広がるってのもどうよ？って話。
- - ※6 : ドクター・ノオ・ネーム
  - 2020.3.26 13:42
  - 返信
  - 引用
  ＞※2
  ユニットテストから出来るところは全てテストするという方向にかなり前からなってきてる
  あなが老害扱いしてる管理職よりあなたのほうが古い考えだと思う
- ※3 : ドクター・ノオ・ネーム
- 2020.3.26 9:30
- 返信
- 引用
ワイド比率の液晶でエディタ画面を二分割した時
スクロールが発生しない程度の長さがワンラインのギリギリだと思ってる
それより長くなるならステップ増えてもいいから、分かりやすい様に変数に格納した方がいいと思ってる
- ※4 : ドクター・ノオ・ネーム
- 2020.3.26 9:38
- 返信
- 引用
書き直した方がいいことがある。
よくある原因：
　１．プロトタイプをそのまま製品化してしまったため、最初のコードがそもそも良くない場合。
　２．機能が肥大化する際、付け足しただけで、最適化しなかったため本来の複雑性よりコードの複雑性がとても大きい場合。
メンテナンスコストが払えない会社で２が発生することが多い。
その場合、コードの年齢が５～１０歳を超したあたりで破綻する。
- ※5 : ドクター・ノオ・ネーム
- 2020.3.26 11:12
- 返信
- 引用
オッカムの剃刀ってのは、プログラミンにも通じるんじゃない
アインシュタインも、「簡潔な数式こそ、より完璧な理論に近づく」って言って、
E＝ＭＣ²っていうのに辿り着いたんだし
- ※7 : ドクター・ノオ・ネーム
- 2020.3.27 3:03
- 返信
- 引用
今どき
void strcpy(char *dst, char *src) {while(*dst++ = *src++);}
みたいな書き方を推奨されるとは思わなかったぞw
- ※8 : ドクター・ノオ・ネーム
- 2020.3.28 0:24
- 返信
- 引用
常に保守性を考慮するのが頭の隅にあればいい。ただそれを実践できるPGが少ないだけ。
見通しの良いソースは自然と不具合もなく性能を満たす。
- ※9 : ドクター・ノオ・ネーム
- 2020.3.29 0:24
- 返信
- 引用
そもそも何を問題視してるとか何を犠牲に解決するとかの共通認識を持つことが重要だと思う
各々が力業でゴリゴリやったけど
後から見て何でそんなことしたのかとかでもめるの無駄すぎる
- ※10 : ドクター・ノオ・ネーム
- 2020.3.30 8:27
- 返信
- 引用
コードの行数が０行ならバグも０だから正しい気がするが、
コードの行数が０行なら生産してないから、全体としては間違いだな。
- ※11 : ドクター・ノオ・ネーム
- 2020.3.31 8:29
- 返信
- 引用
三項演算子好きそう。