コードの行数を減らすと生産性があがりバグも減る @ [プログラマー板]
- 2020.3.25 21:01
- カテゴリー : コンピューター
- [ありがちなこと] . [理系考察] . アプリケーション . コメント . コーディングスタイル . シンプル . ステップ数 . スパゲッティコード . ソフトウェア . ソースコード . ネスト . バグ . メンテナンス . ワンライナー . 三項演算子 . 修正 . 可読性 . 生産性 . 行数 . 開発 . 関数 . 類似性
- コメントを書く
![コードの行数を減らすと生産性があがりバグも減る @ [プログラマー板]](http://science-2ch.net/wp-content/uploads/2020/03/MWtzhJ4s.jpg)
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
そりゃ、処理、機能がないんだからそうなるな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になる。
その当たり前のことが出来ないんだよね。
ソフトウェアの難しいのは、バージョンアップしていく所。
大きい物と小さい物は作り方が違うんだけど、小さく作って大きくしていく時に、既存の部分を大きい作り方に直さないといけないんだけど、「既存の部分に手を付けるな」とかいう馬鹿な奴が指揮をとると、どんどん複雑になって手がつけられなくなる。
既存の部分を修正すれば、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行でも読みやすい方が保守工数は減るんでね
一行に纏めて読みづらい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が少なくなるように書けっつってっだろ?
instructionが少なくなるように書けっつってっだろ?
29: 仕様書無しさん 2015/09/13(日) 23:10:18.70 ID:.net
>>28
>>1の
>>1の
> 行数(正確にはステップ数)を
を読んでますか?31: 仕様書無しさん 2015/09/14(月) 07:09:08.63 ID:.net
>>29
はあ?instructionだよアホ
頭ん中で簡単なアセンブリしながら書けっての
はあ?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
その機能を実現するのに最適なロジックを選択したら行数も減るってことの裏返しを言ったんだよな?>>1
52: 仕様書無しさん 2015/09/18(金) 21:01:01.79 ID:.net
同じコードを2度書くな
大切なことだからもう一度書いとくよ
同じコードを2度書くな
コードの行数は減ることが多い
単体レベルのテストは減る
同等のコードなので生産性は上がらない
コードが分散しないのでバグは減る
同じコードを2度書くな(大切なのでry
違和感があるときはリファクタリングのタイミング
大切なことだからもう一度書いとくよ
同じコードを2度書くな
コードの行数は減ることが多い
単体レベルのテストは減る
同等のコードなので生産性は上がらない
コードが分散しないのでバグは減る
同じコードを2度書くな(大切なのでry
違和感があるときはリファクタリングのタイミング
53: 仕様書無しさん 2015/09/19(土) 10:38:44.77 ID:.net
>>52
二度以上書かないとならない数行のコードなんて普通にあるから。
おまいの書いた内容程度の行数なら何回でも同じコードを書いてもいいよw
二度以上書かないとならない数行のコードなんて普通にあるから。
おまいの書いた内容程度の行数なら何回でも同じコードを書いてもいいよ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
でライセンスやアーキテクチャを作っているみたいだけど、スレ主は注目する価値があると思うよ。
その人は今、その情報理論に基づいて、
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で
第二版(上巻)の7.4で
・ルーチンは100~200行に増えてもよしとすべきである
・200行を超えるサイズのルーチンについて、コストの低下、エラー発生率の低下、またはその両方を報告している調査は一件もない
と、マコネルがすでに調べてくれている80: 仕様書無しさん 2017/06/07(水) 03:51:07.75 ID:.net
マコネルのはPythonみたく「コードは全部数式みたいにワンライナーしてるのがキモチイイ!」みたいなグイドの発想は反映してなかったと思うんでアレだが、切り詰め主義はお勧めできない
ワンライナー主義ってのは、意味論的にはネストかましてるのと一緒だから、状況がアレでも3段、どんだけひどかろうが4段(ジャグドアレイとか行列あつかってたらあり得る)それ超えたら後のメンテに影響する
平均的な人間なら変数とか全部含めて7コ以上の何かを超えたら、脳みその短期記憶からなんか落ちる、ってのは心理学の世界で知られてることだ
ワンライナー主義ってのは、意味論的にはネストかましてるのと一緒だから、状況がアレでも3段、どんだけひどかろうが4段(ジャグドアレイとか行列あつかってたらあり得る)それ超えたら後のメンテに影響する
平均的な人間なら変数とか全部含めて7コ以上の何かを超えたら、脳みその短期記憶からなんか落ちる、ってのは心理学の世界で知られてることだ
83: 仕様書無しさん 2017/06/07(水) 12:27:35.40 ID:.net
コードが長いからダメ
コードが複雑だからダメ
んなこと言ってる奴は向いてないから辞めれw
コードが複雑だからダメ
んなこと言ってる奴は向いてないから辞めれ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スパゲッティで書かれたコードなんか、簡単に破棄なんて出来ないぞ。何が起こるか予想できないからな。
gotoスパゲッティで書かれたコードなんか、簡単に破棄なんて出来ないぞ。何が起こるか予想できないからな。
93: 仕様書無しさん 2018/10/14(日) 16:23:55.44 ID:.net
下手なやつほどコードが長くて複雑
確かにこれは真理だは
確かにこれは真理だは
シンプルに短くというのはマにとっては永遠のテーマでしょうかねぇ。
デザイナーなんかもよく似てる。初心者デザイナーは、とにかく奇をてらうデザインをしたがるものですが、しかしどちらも、やがては自分の間違いに気づくことでしょう。
というわけで、短くてシンプルなコードにバグが混入しにくくメンテも容易なのは、まぁ当たり前なのですが、要求される動作は満たさなくてはならず、これがなかなか難しいですね。
スレでは、シンプルさと長さは別に相関関係にないとか、ワンライナーにこだわると可読性もメンテ性も落ちるよとか、むしろコメントやデータの取り扱いを気をつけろとか、メソッド(あるいはサブルーチン)にまとめるのは意味の類似か目的の類似か…などなどと語られています。
どれも別に間違ってはいないと思うけど、バグの出やすさに関して言えば、もうマ本人の資質によるところのほうがずっと大きいと思う。平たく言えばどうやってもバグを出すマは出すし、出さないマは出さないです。
複雑な要求を短くシンプルにとか、ロジックは細かく分割して再利用しろとか、口でいうのは簡単ですが、ちゃんとやるには経験が必要ですよね。
管理人はシンプル短くは最初からはできなかったけど、バグについては初心者のころからほとんど出さなかったので、あまり関係なさげというか、やっぱり几帳面かつ注意深いとか、秩序や整理分類を愛するとか、そういうほうが効果がでかいと思うな!
下手なやつほどコードが長くて複雑
という最後に持ってきたこれ。特にマ初心者のころっていうのは、長く複雑なロジックを問題なく動かせることにカタルシスを感じたりするから、まったく厄介な性質なのです。デザイナーなんかもよく似てる。初心者デザイナーは、とにかく奇をてらうデザインをしたがるものですが、しかしどちらも、やがては自分の間違いに気づくことでしょう。
というわけで、短くてシンプルなコードにバグが混入しにくくメンテも容易なのは、まぁ当たり前なのですが、要求される動作は満たさなくてはならず、これがなかなか難しいですね。
スレでは、シンプルさと長さは別に相関関係にないとか、ワンライナーにこだわると可読性もメンテ性も落ちるよとか、むしろコメントやデータの取り扱いを気をつけろとか、メソッド(あるいはサブルーチン)にまとめるのは意味の類似か目的の類似か…などなどと語られています。
どれも別に間違ってはいないと思うけど、バグの出やすさに関して言えば、もうマ本人の資質によるところのほうがずっと大きいと思う。平たく言えばどうやってもバグを出すマは出すし、出さないマは出さないです。
複雑な要求を短くシンプルにとか、ロジックは細かく分割して再利用しろとか、口でいうのは簡単ですが、ちゃんとやるには経験が必要ですよね。
管理人はシンプル短くは最初からはできなかったけど、バグについては初心者のころからほとんど出さなかったので、あまり関係なさげというか、やっぱり几帳面かつ注意深いとか、秩序や整理分類を愛するとか、そういうほうが効果がでかいと思うな!
Code Reading ~オープンソースから学ぶソフトウェア開発技法~ (プレミアムブックス版)
Generated by Hakase Channel at 20.3.24
ランキング: 本 - 236,173位 (売れ筋を見る)
関連記事:
うちの会社でも「オレの技術ステキ」って鼻高々にひとりで誇ってる管理職がぐちゃぐちゃ言うから、必要があるから触るって言うてんのにそれを止められて、同じようにスパゲッティになってってる。
そのくせスクラッチのときはインジェクションが~とか共通化が~とかとかとかカッコイイこと言うんよな。
確かに「いじった箇所はテストする」の範囲が広がるのは避けたいって気持ちもわからなくはないけど、それのせいで更にあとでテストする範囲が広がるってのもどうよ?って話。
ユニットテストから出来るところは全てテストするという方向にかなり前からなってきてる
あなが老害扱いしてる管理職よりあなたのほうが古い考えだと思う
スクロールが発生しない程度の長さがワンラインのギリギリだと思ってる
それより長くなるならステップ増えてもいいから、分かりやすい様に変数に格納した方がいいと思ってる
よくある原因:
1.プロトタイプをそのまま製品化してしまったため、最初のコードがそもそも良くない場合。
2.機能が肥大化する際、付け足しただけで、最適化しなかったため本来の複雑性よりコードの複雑性がとても大きい場合。
メンテナンスコストが払えない会社で2が発生することが多い。
その場合、コードの年齢が5~10歳を超したあたりで破綻する。
アインシュタインも、「簡潔な数式こそ、より完璧な理論に近づく」って言って、
E=MC²っていうのに辿り着いたんだし
void strcpy(char *dst, char *src) {while(*dst++ = *src++);}
みたいな書き方を推奨されるとは思わなかったぞw
見通しの良いソースは自然と不具合もなく性能を満たす。
各々が力業でゴリゴリやったけど
後から見て何でそんなことしたのかとかでもめるの無駄すぎる
コードの行数が0行なら生産してないから、全体としては間違いだな。