ソフトの質はコード量に関係するか？ 70
ストーリー by wakatono
小さいことは良いことだ 部門より
小さいことは良いことだ 部門より
どこかの親切な人曰く, "@ITの opinion に「ソフトの質はコード量に関係するか？」というコラムが掲載されている。 以前話題になった「ソフト開発を成功させる1つの方法」の続編的内容であるが、今回はエクストリーム・プログラミングと絡めて話が展開されており興味深い。"
コラム自体はXPが何かというのを知らなくても読める。取っ掛かりにはいいかもしれない。
XPを分かってないね (スコア:3, すばらしい洞察)
XPの話をするのはいいんだけど、もっとも重要な「変化を抱擁せよ」をまったく触れていないのは、まずいでしょう。XPにはいくつかのpracticeがありますが、要は、以前の仕様書重視の工業生産型に対するアンチテーゼなのに。仕様書から離れることが、共同共有（だっけ？）や頻繁なリリース、顧客サイドなどの考えにつながっているのに。
ペアプログラミングにこだわっているように見えたけど、ペアプログラミングは共同共有を実現するのに有効ということだし（それだけではないけど）、XPの本質ではない。
rm -rf /bin/laden
Re:XPを分かってないね (スコア:2)
こないだ、XP本買って読み始めました。とりあえず、@ITの彼は、/.のネタ [srad.jp]を読んだ後、最初の一冊をちょこっと読んで終ってるような気がします。まだ、本文からXPの本質を見極めた感じのする文章ではないということが読みとれます。
それはなぜかと言うと、ほとんど本にそのまま書いてあることが載ってるだけだから。いわゆる鵜飲み(悪く言えばコピペ)ってやつです。締めが経験云々と言っているのはおおやけ間違いではないですが、プログラミングを事務的な要素でしか片付けられない人を見るとすごく可哀想な気がします。プログラミングが面白いと感じられるような文書じゃ無いからね。
まあ、彼もネタが無いと食って行けないのでしょう。
俺としては、プログラミング能力よりは、現実的な仕様にまとめあげられる能力とかが重要だと思ってます。それはまた、XPに不可欠な要素でもあるからね。
Re:XPを分かってないね (スコア:1)
リファクタリングの本に書かれてますが、長すぎるメソッド、巨大なクラスが駄目というのは正しいと思います。ただし、全体のコード量と質はほとんど無関係でしょう。
御用聞きによる開発の限界 (スコア:3, すばらしい洞察)
XPだかなんだか理論を振り回すのはいいけど、実際にそれで数十年開発を持たせるという実績を挙げてから物を言ってもらわないと実感が沸いてきません。川俣氏に一番欠けているのはこれです(もっとも「理論と実践は異なる」と言った時点で理論に頼ることを知らず識らずのうちに否定しているので、今回のコラムは自己矛盾を含んでいるのだが)。
Unixはこの世に存在するソフトウェアとしては大規模であり、かつ30年の歴史があります。これだけ歴史があれば、少なからず要求の変化があります。例えば、以下のようなものです。
Unixで注目すべきは、これらを成し遂げたのがあくまで自ら志を持った人達であるということなんです。他人に言われるのではなく、自分で新奇かつ有用なアイデアを考え、実装した人達です。川俣氏やピーデーはモノは作っているかも知れませんが、結局は人に言われるままに作ることしかしておらず、Unixを作った人達のような素晴らしさがありません(実際、「りすと亭」を見て「これならMajordomoで動かした方がましだ」という結論に達した)。
自分から興味を示し、何か取り組もうとする人でなければ、XPを使ったって何を使ったって大したものは作れません。そもそもUnixを作るのに開発モデルなんか存在していません。
りすと亭 (スコア:2)
Re:りすと亭 (スコア:2)
なんか、結論としては、「誰もが欲しがりそうなものは既に出来上がっている」てことなんだろうね。
もう一個言うなら、「客に金を払わせてまで作って、公のフリーソフトウェアと全く同じか、それ未満の機能しか提供しないならば、それは詐欺以外の何ものでもない」とか。っていうか実際そればっかだけど(--;
フリーソフトの薦め方 (スコア:1)
でもなぜかお客さんは、「金を払って手に入れた」という妙な理由に安心感を求めるんですよね。
フリーソフトウェア(具体的にはperlだったんですけど)の利用を提案すると、お客さんも私の上司もいやな顔をするし。(上司は金にならないと言う理由もあるんですけどね)
なにか良い説得方法ないですかね(ーー)
オフトピックですけど、
＞なんか、結論としては、「誰もが欲しがりそうなものは
＞既に出来上がっている」てことなんだろうね。
「自分が悩んだ問題は、既に誰かが悩んでいる」
Re:フリーソフトの薦め方 (スコア:2, 興味深い)
みたいになっているから、Solaris8上のperlで開発すると
納得したりして?
Re:フリーソフトの薦め方 (スコア:1)
> 理由に安心感を求めるんですよね。
これ、音楽も同じです。
エムピーなんとかを友達にもらったりネットで盗んだりしても、
どうも「持ってる」感じはしないので、結局パッケージを買っちゃう。
結局「持ってる」「取得した」って、どういうことなんだろう。
と考えてしまいます。
[udon]
Re:フリーソフトの薦め方 (スコア:1)
ていることの実感を求めているというようなこともあるような気がします。
Re:フリーソフトの薦め方 (スコア:1)
タブレット中毒者。
Re:フリーソフトの薦め方 (スコア:2)
> 隣人の独り言(^^;を聞くと、時として私と同じことを悩んでいたりするようなので…
/. の日記を勧めて上げませう。
隣人同士で幸せになれる（かも）
って冗談はさておき、貴方がそう思ったその瞬間から、即行動しては如何？
尻込みしてても何も産まれません。
所属会社を気にしない積極的な交流を個人的には実践してますが、結構、助けたり助けられたりすることで、お互いのスキル向上に役立つことが多いです。
特に他社の文化に触れることは個人的に面白かったりもします。
○○はこの人のほうが詳しい、でも××は自分のほうが詳しい、こんな関係が築けるとお互いメリットありかも。
※この場合、××のスキルも更に上げてかないと何時か必要とされなくなるので、否応なしに継続的自己研鑽が要求されますが、それも言い方替えればメリットと考えてます。
如何なもんでしょうかね。
Re:フリーソフトの薦め方 (スコア:1)
開発者の掲示板とかメーリングリスト（FreeTalk系）の方が 悩み事とか独り言のコミュニケーションがスムーズなような 感じがします。
「門前の小僧、習わぬ経を唱える」みたく、その場に属してい る事で吸収できるものがありそうな感じがするのだが、そうい ったものが職場では皆無なような。
まぁ、生半可な知識で行動するなという事かもしれないが。
全くその通り (スコア:1, 興味深い)
全くその通りだと思います。
こういった「御用聞き」というか「言われたことだけやる」開発屋にドップリと浸かって、これが「ソフト屋さ、こんなもんさ」なんて思っている人の一人だね。このなんとかいうオッサンは。
客の言うことを、あるいは世間でこれは売れるよ！なんていわれ尽くしたことだけやって、その中に自分の「創造」と言う行為をいやしく貶めているから、こういう了見の狭いソフト屋がはびこるんだと思うよ。日本という国は。
XPの書籍を読んでも読まなくてもいいけどさ、それに感心してるだけじゃなくて、そこに自分の独創というモンがカケラもない。あるものをありがたがってるだけ。
「おれを肯定する奴はオレの敵だ！」くらいな強烈な個性と独創がないと、これからの否応なしのグローバリズムにはついていくことさえできないよ。
もっとも、日本じゃそういう個性は嫌われるがね。今までは。それに耐えて、突き抜けたファイトと知性を獲得してほしいもんですね。少々名前が売れた程度のプログラマ&SE程度で満足しちゃいけないね。
ココロザシの低い人はどこでも同じ、という見本みたいなコラムだわね。
前回と比べて (スコア:2)
前回と比べて、批判を受けにくいように気をつけて書きましたね。プログラムのソースなんかは出さなくて良いような内容になってますし。/.の影響恐るべし。
Re:前回と比べて (スコア:3, 興味深い)
XPで言われている「クラスの数とメソッドの数が最低限に」とかを引用して、大きなコードより小さなコードの方が良いという論理展開みたいだけど、XPの言わんとする事は余計なものは除けという事であって、「短いプログラムは無条件で正しい」という川俣氏の主張とは全く別次元の話でしょ？
Re:前回と比べて (スコア:2)
まずはじめに結論ありきで後から理由を付け足してみたものの、それではまだ足りなくて今回XPを引き合いに出したと。そうでなければ、前回の時点で言及していたと思うけど、そこは文字数不足を言い訳にしているみたい。物書きがそういう言い訳をするのもどうかと思うが。
で、これ以上後づけする理由が見付からなくなると、「経験に依存」云々で逃げるのでしょう。なんかあやしげな宗教の勧誘みたいだ。
違う経験を持つ人にも伝えないと (スコア:2, 参考になる)
でも、「経験」で逃げちゃ、だめだと思う。たしかに人間って、経験その他の理由でびっくりするほど違う意見を持ったりするもんだけど、違う経験を持つ人にもその意見が伝わるように書かなければ、筆者は書いてる意味がないですし、編集者は載せてる意味がありません。
同じ経験や意見を持つ人に伝えるだけなら、誰にだってできることです。
Re:違う経験を持つ人にも伝えないと (スコア:2)
と引用すると反発受けそうだ（笑）
-- wanna be the biggest dreamer
Re:違う経験を持つ人にも伝えないと (スコア:2)
いや、経験したことに気がついていないのかもしれないな。
char *A;
モータースポーツ部 [slashdot.jp]
Re:違う経験を持つ人にも伝えないと (スコア:1)
Re:違う経験を持つ人にも伝えないと (スコア:2)
「知識なき経験は、経験なき知識に優る」。
経験が大切なのは当たり前で、それを土台にしながらも他者の経験を混ぜ合わせて普遍的な経験則を見つけ出すのが知恵なわけですね。
どちらの格言も、自分の経験をいきなり普遍則に持っていく態度を戒めております。
ついさっき本読んだと臆面もなく述べ、その権威を盾に自説補強の説教垂れるあたり、自分の経験しか見ない言説と思われても仕方なし。
というわけで、論の中身以前の問題です。
こんな記事読むなら、ハリーポッターでも読んで経験豊かにしましょう;-P
-- wanna be the biggest dreamer
よくあるのは (スコア:1)
自分と違う考えの人がいることを知らないっぽい人って、よくいますよね。
たとえば「よい意味で」とか「わるい意味で」とか。どのようなものをあなたは「よい」「わるい」と考えているのですか。人によって違うでしょう。それをまず説明しないことには、情報量ゼロ。
よく似たのに、ほめ言葉として「ほんとうの意味で」。最初に、「自分は [具体的な内容をここに入れる] をほんとうの意味だと考えます」と言ってから、「ほんとうの意味」という言葉を使え。
「正常な判断力をもってすればおのずと結論は明らかだ」とか「すなおに考えれば」とか系。だから、あなたのいう「正常な判断力」というのは「自分と同じ考え」という意味なんだって。同じ判断力を持っているけど違う考えに至っている人間もゴマンといるという現実を見たほうがいいよ。そうして、自分と相手の意見の相違はどこから生じたのかを考えないと。「ヤツは異常だから」「キ千ガイだから」「正常な判断力を持ってない」とかたづけてしまうのはいただけない。
とくに、「いい意味で」とか「ほんとうの」とかは、表面上みんなの同意が得られたような錯覚に陥ることがある。なぜなら、みんなそれぞれ自分自身が考える「ほんとう」があり、その自分自身の「ほんとう」の具体的内容に置き換えて元の文を解釈するから。元の文は「あなたは自分の意見に賛同する」というくらいの意味しか持たなくなる。「自分の意見」の具体的な内容がそれぞれ違っていても、「あなたは自分の意見に賛同する」にはみんなイエスと答える。そうすると、みんなはそれぞれ、他のみんなが自分の意見に賛同してくれているかのように感じる。
Re:よくあるのは (スコア:1)
いやほんとっすね。
今回のあの文章、最初の1段落で、読む価値ないんじゃないか？と思わされました。
「経験すれば判る」だなんて、「ちょうど逆の経験をした」人が出現したらどうすんのよ？って感じです。
あるいは逆に、筆者ローカルな「特殊な(笑)」体験に由来した話なのかも知れませんし。
UFOを見たことが有る(のでUFOは存在する)と主張してるUFO狂信者、と似ているかも知れない。
せめて物書きなら、そういう地を這うレベルの事柄は、
よしんば脳裏に浮かんだとしても、意地でも記事に反映させないで欲しいものだ。
これでは単に、自分勝手な判断基準に基づいて、敵(笑)を自分より劣等なものだと決めつけてるだけ、です。
ところで、
>不幸にも記事の趣旨が分からない読者も多かったことが分かった。
と有るが、せめてその「判らない読者」のポインタを示して欲しかったね。
どっちが「判ってない」のかを第三者が判断しやすいように、さ(笑)。
そうでないとアンフェアでしょ？
余談：
数々の御指摘のとおり、おかしな日本語(?)を弄する人々って、
なんだか多いですよね。困ったもんだ。
特に「素直に考える」には俺もほとほと困っています。
そういう無茶な言葉を言い放つような「野蛮な人格」は、少なくとも俺は嫌いだなあ。
Re:前回と比べて (スコア:1)
確かに。でも、「守り」に入っちゃったせいで、何を主張したいのかが見えない文章になってますね。
せっかく「Opinion」と名づけてるんだから、大雑把なXPの紹介より、自分の意見を述べてほしかったです。「趣旨が分かってもらえなかった」と認識しているのですから。
いまだにはびこっています。 (スコア:2, 興味深い)
いまだに、ステップ数なるものを基準にしています。
いわゆる行数です。
プログラマをバカにしているとしか思えません。
Re:いまだにはびこっています。 (スコア:2, 興味深い)
マイナーな環境のマイナーな言語ですが、毎年理解が進み、ステップ数が減っていく。
対して、VC++で山盛りスパゲティを作っている人間の方が待遇が良かったりするんだよね。
（別にVC++に悪意はありませんが）
Re:いまだにはびこっています。 (スコア:1)
-----
[よいSEにはよい報酬を，“人月いくら”はもうやめよう]
http://itpro.nikkeibp.co.jp/free/ITPro/OPINION/20011118/1/
-----
ステップ数カウントは「伝統行事」と割り切っています。たまに前versionよりステップ数が減ると何故か私の能力が疑われるので、コメント文で補充しています =)。
こんなことで給料が貰えるなら毎日でもやりますよ。
Mc.N
Re:いまだにはびこっています。 (スコア:1)
すいません、茶々になってしまった。
しかし、RECURSIVEなプログラムは短いけど読むのは難しい。
---- sinbo
趣旨としてはいいこと言ってると思うんだがね (スコア:2, すばらしい洞察)
「よく聞く意見」で言っているのは
「読みやすい長いプログラム」は許されるべきだ､というもの。
しかし彼自身の意見は
「読みにくい長いプログラム」はXPのような手法を用いて
「読みやすい短いプログラム」にすべきだ､というもの。
＃普通考えて､いくらすっきり書いてあったとしても
＃目的と関係ないコードのたくさん入ったプログラムは
＃「読みやすい」とは言えないよな。
＃同じコードが繰り返し出てくるのも、
＃特別な理由がない限り一般的には「読みやすい」とは言えないだろう。
同じ「長いプログラム」と言っていても、実は違うものを指している。
だから、「短くした方が良い」というのは彼の主張からすれば当然だ。
しかしまあ、実際現場では「長くても読みやすいプログラム」
なんてほとんど存在しなくて「長くて読みにくいプログラム」が蔓延してる。
その意味では、一般的には「短くしろ」でいいと思うんだけどなぁ。
＃XP的に考えれば、「長いプログラム」から「短いプログラム」
＃に書き換える時点で、ほとんどのプログラマはわかりやすくなるように
＃書き換えるだろう、ってことだよね。
# mishimaは本田透先生を熱烈に応援しています
シンプルなコード (スコア:1)
だからこそ単純にコードの長さを問題にするのではなく、Martin Fowler [martinfowler.com] の「リファクタリング [mmjp.or.jp]」のような、より具体的なプラクティスが必要とされると思うのだが、どうだろうか。
Re:シンプルなコード (スコア:1)
問題点はそこ。
つまり、筆者は
「プログラムを短くする＝プログラムをシンプルにする」
だと言ってて、/. の多くの人の意見としては
「プログラムを短くする≠プログラムをシンプルにする」
だと言ってるワケよ。
しかし、ほとんどの場合
「プログラムを短くする≒プログラムをシンプルにする」
だと思うがな（正確には
「プログラムをシンプルにする⇒プログラムが短くなる」
なんだけどさ）。
それを「無条件で」と言ってしまうのは当然ウソなんだが、
それで長くて読みにくいプログラムが少しでも減るなら、とは思うね。
もちろん、「短ければいいんだろ？」と読みにくいのを書く奴が
いないとは限らないが、そんな奴はどんなこと言っても無駄だと思われ。
＃それは置いといて、最近多機能というか「and kitchen sink」の
＃アプリケーションが多いのにはうんざりさせられるな。
# mishimaは本田透先生を熱烈に応援しています
結局、何が言いたいのだろう?? (スコア:2, すばらしい洞察)
今回の記事と前回の記事を読む限り、川俣氏は、
という、UNIX的考え方を提示した上で、
と、言いたいのかと思うのだが、実際の説明内容はまた違った感じだし・・・。
わけわかんねー(笑)
思うに、「短いプログラム/長いプログラム」の話は、一連の記事の本質ではないはずなのに、記事の中でそこにこだわるあまり、結論を喪失しているのだろうか?
本当に提示したいテーマは、
で、そのためには、
と、いうことなのだと、とりあえず勝手に解釈しとこう。(文面からは、そうは読み取れないけど・・・)
--- Melloques Les Covdrasey ---
ご本人のコラムより (スコア:2)
川俣氏のご本人のコラム本文より、この短い「要約」のほうがはるかにわかりやすいのは、なぜなんだろう？
（笑ってません、ええ、わたし、絶対に笑ってませんよ）
Re:ご本人のコラムより (スコア:2)
長いからバグが入ったんでしょう。
Re:結局、何が言いたいのだろう?? (スコア:1)
を読んで、参考にしてください、ということに尽きるとか・・・？
それじゃ単なる本からの受け売りだから違うのかなあ。
ここでコメントしている人の誰かがコラムを書いた方がわかりやすいかも？（でも文字数が足りなかったり多かったりするかもですけれど）
-------- SORAMINE Yukino
Re:結局、何が言いたいのだろう?? (スコア:1)
正しいんだけど瑣末なことをいってる気がします。 たくさんある大切なことのひとつに過ぎないというか、 @ITのコラムにするほどのことでも(しかも2回も)ないような。
バグの無い短いコードと、もういっこ別の バグの無い短いコードを結合して長いコードになるときにバグが生まれるかもね、 ということなのかもしれない。 要素が正しくても要素どうしの関係をちゃんとしないといけない、というか インターフェースを設計しようということかもしれん。
もっと単純に、バグの存在確率が一定なら 短いコードより長いコードのほうがバグの数が多い確率が高い、 ということを言いたいだけかも知れん。
文章構造の設計不足? (スコア:1)
思うに, そんなに長い文章じゃないからと構造設計をしっかりしないで書き始めたら, 結果として訳が分からなくなっちゃった. と, そんなところじゃないですかね.
小さなプログラムだとなめてかかると, 短いにもかかわらず異様に難解になってしまうのと状況としては非常に似通っているように思えます. 言ってみれば複雑さの本質とは単純な長さではなく, 構造の簡潔さの方が重要であるということを, この文章自体が逆説的に証明してしまっているわけですね.
XPに言及するくらいなら (Re:文章構造の設計不足?) (スコア:2)
こんなコラムを書く程度じゃ (スコア:1, おもしろおかしい)
こんなコラムを書く程度のアタマしかないソフト屋を「センセイ」にする、なんとか協会のなんとか委員にする、なんてのは、アルツハイマーか狂牛病の影響としか思えませんね。
つくずく、シアワセな国に住んでるねぇ。俺たちは。
Re:こんなコラムを書く程度じゃ (スコア:2)
クソの役にもたたなかったそうです。現場を混乱させソースをスパゲッティ化させ、どうしようもなくなってお引取り願った、という話でした。立て直すの大変だったそうな。
まあ記事とかコラムとか書いて食っておられる方々が皆そうであるとは申しませんが…。
Re:こんなコラムを書く程度じゃ (スコア:1)
それって、「案件のほうが」クソだった、という可能性もありますね(^^;
まともな人間は、クソすぎるものには却って対処しにくいものじゃないかと。
しにくいってのは、手の施しようがないのが判るという意味だったり、
報われない苦労に向けての気力が萎えるという意味だったり…色々。
ぐちゃぐちゃすぎてまとめようもない案件、って出会ったこと無いですか？>all
案件とか要求仕様とかで。「無茶言うなよおまえ！」と叫びたくなるような。
Re:こんなコラムを書く程度じゃ (スコア:2)
> 案件とか要求仕様とかで。「無茶言うなよおまえ！」と叫びたくなるような。
根本的に（業務仕様レベルで）要件定義を間違えてる仕様と出会ったことはあります。
※そのまま実装したら業務が混乱して、ホントに動かないコンピュータで特集されてしまいそうな・・・
逆に要求仕様が無茶な場合のほうが、（調整相手がアホじゃなければ）却って扱いやすいです。
無茶な仕様をまっとうな仕様に論理的にスジを正してあげればいいだけですから。
（調整相手がアホだと無茶な仕様でズルズルと・・・）
スジが通っていれば、あとは実装するために緻密にパズルを解いてくだけ。
※個人的にはパズル大嫌いですが（笑）
中途半端な技術スキル（プログラミングやデータベースとか）に根拠のない自身を持ってるアホが、業務上要求されている要件を無視して（っていうか気づかないで）、適当な業務仕様を纏め上げ、自分が試したい機能とかを、なかば趣味でいれてるんか？と疑いたくなるような実装仕様を作ってるケースとか、たまに見受けられます。
とあるプロジェクトでのお話。
【客】
さぁシステムテストだぁ。
あれ？こっちのサブシステムとあっちのサブシステム、業務上連携できてないじゃん。
【アホ】
えっと、こっちのサブシステムはこーんな技術を投入して作ってまして、そんで、あっちのサブシステムはですねぇ、これこれこういう技術基盤に乗っかってて・・・
【客】
そんな話聞いてなくって、どうすればつながるの？
【アホ】
・・・（汗）
《後日》
【アホの上司】○○クン、アホの関わってるプロジェクトで問題が起きてるらしいんだけど、なんとかまとめてきてよ【○○】（プロジェクトの現状を見て）
どないせぇっちゅうねん（怒）
※フィクションです。でも似たような場面は・・・
Re:こんなコラムを書く程度じゃ (スコア:2)
仰せの通りではありますが（笑）話を聞かせてくれた人に対する私の信頼度から計算するとあまり確率としては高くないと思っています。それに本当にアホ案件なのだったら、自らリーダーシップを発揮して立て直すのに邁進するとか、逆に一目でダメだと見抜いてイチヌケタするとか、マトモな人だったらそういう行動に出るものではないものか、という気もします。単なる呼ばれてやってきたバイト君の立場で、他人から引っこ抜かれるまでズルズル破壊魔として存在しつづけたという時点ですでに…。
いや、本当にひとから聞いた話なんですよ。（って念を押すと嘘っぽくなるけど。）元コメントでは「ライター某氏」と書きましたが名前は聞きそこなったので実際には、それが誰なのかは私は知らない。
センセイと呼ばれるほどのバカじゃなし (スコア:1, おもしろおかしい)
man のコピペで稿料もらってる [ascii24.com]センセイもいましたかな。
Re:センセイと呼ばれるほどのバカじゃなし (スコア:1)
pLaTeX2eなど便利に使わせてもらってる身としては、
つい弁護したくなるというか、まさかそんな、と
思ってしまうのだけれど……。
世界人類が平和ボケでありますように
コード量は関係ないような… (スコア:1)
(´д｀;)
Re:コード量は関係ないような… (スコア:2)
きっと彼は、仕事でコードが無闇やたらと長いのを作らされた、あるいは、長い奴をつくった方が高給だったから、それのはらいせにこのアーティクルが出現したという邪推もできないこともないです。
コードなんざ短いに越したことは無いし、読みやすければそれで良い。別に長さは必要なだけ確保すればそれでいいんじゃないの?という考え方をするのが技術者サイドなら一般的だと思うのですが。
main(){printf("HelloWorld\n");}が正しい?って言われるとアレだし。
Re:コード量は関係ないような… (スコア:1)
汎用性を否定しているようですけど、汎用性が高いとコードが長くなるなんて言う話は聞いたことがありません。STL(Standard Template Library)は高い汎用性がありますが、十分に短いですよ。インターフェイスをできる限りシンプルにしろっていうのは良く聞きますが、そのこととコードの長さとは関係ありませんよね。
とありますが、それが要求されない状況は普通はないと思います（私が無知なだけなのかな...）。不必要な機能や重複した機能を推奨する設計や実装っていったい...。実装時にそんなことを議論するような状況が起きているということは、きちんと設計ができていないということではないでしょうか。
あ、そうか。だから、
っていう言葉がでてくるのね。妙に納得。
Re:コード量は関係ないような… (スコア:1)
当然コード量も限られる。%d、%x ぐらいあればいいよねという 意見と、いや printf なのだから %f 等もあって当然！という意 見もある。
前者は使いもしないような機能は削減してコード量、バグの盛り 込みを防ごうと思っているし、後者は printf ライクな関数があ るからと設計していたのに、機能制限とかあると泣くめに陥る。
私は何処で泥沼に陥ってしまったのでしょう？