ソース当たりのコード適当量とは？

Question

お世話になっております。

＠ITの、とある記事で下記のようなことが書かれていました。

『転載したソースは650行あり、かろうじて1ファイルで扱えるサイズだが
　2倍になるなら分割を考えたい』

今まで、ファイルサイズが肥大しないように意識はしていましたが
まさか650行が1ファイルの（理想）最大サイズだなんて思いもしませんでした。

この情報が本当なら、その理由を教えて頂けませんでしょうか？

また、その場合のメリット/デメリットも併せて教示頂けると助かります。

宜しくお願いします。

追記：

また、デザイナファイルはコントロールを多用すると2000行くらいすぐに
達すると思われますが、それも考慮すべきことなのでしょうか？

Answer 1

その記事を見た事が無いのではっきりとは言えませんが、恐らく誤解があると思います。
その650行という数字は、何かしらの前提条件があるかソースをアップする際といったケースではないかと思われます。

外部端末等の特殊なスクリプト言語だとソースファイルサイズの上限がある物もありますが、
1ファイル650行だとpartialしまくる破目に・・・
※もちろんシンプルなソースに越した事はありませんが。

何にしても元の記事のURLなり全文なりが無いと判断は難しいと思います。

Answer 2

仮に、

「作業者が1ファイルで管理できる量って1000行もないよねー。1ファイル500行前後がうれしいなぁ」って話があったとして、

「そしたら IDE が自動的に生成するコードで作業者が直接みることはほとんどない部分はまとめて別のファイルに集めておこっか」

ってことで分けてあるのがデザインファイルでしょう。それをさらに分けるってのは本末転倒な発想。

Answer 3

現在のOOP的な手順においては、

1.ひととまとまりのソースコード内で一つの「意味」又は「物」を表現している。

事が求められます。
具体的には、単独のソースファイルが唯一の意味又は物を示していることが
理想的と考えられます。
人がそれを編集する場合は、行数が少ないほうが楽であると容易に想像できまが、
個人的には、先の理屈を優先すべきであると考えます。

Answer 4

ご回答ありがとうございます。

アドレスを添付します。

http://www.atmarkit.co.jp/fdotnet/extremecs/extremecs_08/extremecs_08_03.html

ことの真偽を確かめたいというよりは、メリットや制約があるのであれば
知りたいと言ったところです。

またデザイナファイルに対しては仰る通りですね。

自動生成ファイルに対して分割するという意味ではなく、それ自体も考慮しなくちゃ
いけなくなるのでは？

という意味でした。

Answer 5

言語的な制限としては、1000行程度を扱えないというようなものはないでしょう。

記事の
>1つのソースファイルに収まらないような巨大なクラスを作成すると保守性が下がるので、作るべきではない……というのは1つの健全な発想だ。

から、巨大なクラスを作らずに済む方法の一つとしてこの記事の手法を紹介しているのだと思います。

ただし、仲澤＠失業者さんの通り、あるクラスがそれを表す意味や物を的確に表現しているのであれば、いくらかコード量がかさむとしてもそういう設計を優先すべきだと思います。
でも公開するインターフェイスは適切にねってことで。

Answer 6

ことの真偽を確かめたいというよりは、メリットや制約があるのであれば
知りたいと言ったところです。

制約、制限という意味では、１つのファイルに記述できる行数は、268,435,454 行までです。

コンパイラ エラー CS1033
http://msdn.microsoft.com/ja-jp/library/w6yz61s5(v=vs.90).aspx

とはいうものの、実際、人間が扱える行数には限界があるでしょう。ただし、何行だから限界であると一律には扱えないと思います。例えば、ソースコードが整然と書かれ、regionで折りたためるようなっている場合、特に読みにくいということはないかもしれません。プロパティがたくさんあっても、それをregionで畳んでしまえば、表示上は１行になります。また、プロパティも自動プロパティを使うなど書き方によって、同じ機能を実装した場合でも、それだけですぐに数行の差が出てしまいます。

また、人間が弄らないソースコード、例えばVisual Studioが自動で生成したコードなどは、いくら長くても基本的に問題ないはずです。

以上のように、１つのファイルに何行までと決めるのはあまり意味がないように思います。それよりも大事なことは、人間にとって如何に読みやすく保守しやすいソースコードであるかだと思いますので、それを実現するための弱い影響力の少ない条件として、１つのファイルには何行ぐらいまでというのがある程度だと思います。要するに、行数を削ることよりも読みやすさを優先すべきでしょう。

ですから、むしろコード規約に目を向けるべきだと思います。例えば、基本的に１つのファイルには、publicなクラスは１つまでというような規約です。この規約によって、ソースコードがある程度長くても、読みやすさや保守性は確保できると思いますし、それらを優先すべきだと思います。

＃（追記）Visual Studioの進化によっても、長いソースコードが扱いやすくなっていると思います。例えば、自分が編集したところのマーカーが表示されるようになりましたが、これによって長いソースコードでも、すぐに自分の編集したところに行くことができます。このように時代と共に変化しているところもあり、Visual StudioのようなIDEの進化によっても考え方が変わってくるのかもしれません。

---

★良い回答には回答済みマークを付けよう！ わんくま同盟 MVP - Visual C# http://d.hatena.ne.jp/trapemiya/

Answer 7

皆様、ご回答ありがとうございます！

＞1.ひととまとまりのソースコード内で一つの「意味」又は「物」を表現している。

＞人間にとって如何に読みやすく保守しやすいソースコードであるか

仰るとおりですね、それらを踏まえた上で読んでみると納得できることがあります。

あの記事を書いた方は、そういった面から膨大なステップ数になるとダメなので分割という手も
あるんだという結論に至ったのだとおもいます。

ただ、６５０というステップ数に驚いて『そういう慣例のようなものがあったのか』と、ぜひこちらで
ご意見を頂戴したかった次第です。

また以前、N△△データに外注したアプリケーションのメインフォームのステップ数は1万を超えて
いたのでそういった面からもお話を聞きたかったのです。

色々と勉強になりました。皆様本当にありがとうございました！