同僚の書く酷いコード、どうやって気づかせる？ 155
ストーリー by headless
泥沼 部門より
泥沼 部門より
あるAnonymous Coward 曰く、
本家/.「Ask Slashdot: How Can I Explain To a Coworker That He Writes Bad Code?」より。
私の同僚は非常に頭がよく、ソフトウェアの知識も豊富だが、想像を絶するほどひどいコードを書く。たとえば、
- すべてのプログラムは1つの関数に詰め込まれ、際限ない繰り返しのせいで無駄に引き伸ばされている
- 変数名やクラス名から得られる情報は泣きたくなるほど少ない
- コードを短く、読みやすくするための基本的な言語機能は無視されている
- オブジェクト指向プログラミングの虐待は吐き気を催すほどで、戦争犯罪レベルといえる
しかし、彼は私が生まれる前からプログラミングをしており、非常に頭が良いことで、人の意見に耳を貸そうとしない。そのため、「この関数をこのように書いたら良くなると思いませんか」といった簡単な提案は受け入れられないだろう。彼に事実を伝え、良いコードと悪いコードの区別をわかってもらうにはどうすればいいだろうか。
問題の彼がどう「頭が良い」かは不明だが、/.J諸兄方ならどうする？
気づいても直らないかも。 (スコア:5, すばらしい洞察)
> 同僚の書く酷いコード、どうやって気づかせる？
気づいても直らないかも。
気づかせるだけなら、スマートなコードを書いて比べさせればいいと思う。
メンテナンスのしやすさ、修正が来たときの直しやすさ、良く使うならクラス化とか、
そういうのは比べさせれば、とりあえず気づくと思う。
一番いいのはダメージが大きくてもハッキリ言うこと。
でも直らないんじゃなかろうか。
私は人並みにしかコードが書けませんが、人並み以下のコードを指摘しても直った試しがないです。
Re: (スコア:0)
自分もそう思います。この人は１にしか対処できない人で、複数が見えないのだと
思います。
１にしか対処できないので、世界をそれで対処可能な様に再定義しないと生きて
行けないので、自然と再定義能力に富み、頭がいいと思われているだけかも、
知れません。
あきらめて、（本家の）私さんがそのソースの全面的権限を得た時に、リファクタ
すればよいだけでは？
＃人間の認識形態の問題になったら、なんであれ、直らないと思います。
Re:気づいても直らないかも。 (スコア:2)
「ベースがクソコードだと」という条件は、
とうの昔にリファクタリングが必要になったにもかかわらず、
それは長期間してこなかった結果だから。
そこまで行ったら既に手遅れ。
＃まるで「末期癌で、もはや手が付けられません。」状態。
もしやるならば、それは「リファクタリング」ではなく「作り直し」。
「リファクタリングの必要があるか？」なら、この場合は「必要があった」だろう。
「リファクタリングする機会があるか?」なら「無いことも多い」。
なぜならば、リファクタリングする必要がある時に、それに気付かず手をこまねいているだけで、
手遅れになるまで放置する無能なマネージャーがゴロゴロしてるから。
その昔「プレイングマネージャーって"Praying Manager"じゃね？」というのを見て、なるほどと思った。
Re:気づいても直らないかも。 (スコア:1)
なぜマネージャーが気付かないんですか？マネージャーがコードレビューしないから？
コードの質は誰が把握してるんです？
警告は誰が行う事になってるんですか？
#なんだろう、自分で書いていてなぜか胃の辺りが痛い…
Re:気づいても直らないかも。 (スコア:1)
ある中小企業での話。
＞なぜマネージャーが気付かないんですか？マネージャーがコードレビューしないから？
コードレビューどころかコードが読めません。
上がってる報告も理解できないと豪語してました。
#というか、コードが読めるマネージャーって、日本に実在するんですか？
#せいぜい「プログラミング言語の文法の基礎が分かる」程度では。
#ちょっと難しいコードになるとお手上げで、コードの善し悪しを判断するなんて夢のまた夢。
＞コードの質は誰が把握してるんです？
おそらく私だけでしょう。
私以外は誰一人読めなかったので、質が悪いことは他のメンバーも薄々気がついていたでしょうけど。
＞警告は誰が行う事になってるんですか？
特に決まっていませんでした。
でも読めるのが私だけだし、そもそもコレを作った人たちは既に退職ずみなので後の祭り。
前任者の負の遺産は、そりゃあ酷い物でした。
でもこういうことって、日本では増えてるんじゃないかな。
ただでさえ若者の数が減り続けてるのに、その上ＩＴ業界のブラックさがネットで共有されて、
新卒就職活動の常識になり、優秀な人材がＩＴ業界を目指さなくなれば、ＩＴ業界の人材の質は
年々悪化する一方だから。
体感的にもそんな感じしませんか？
＃絶対ＡＣだ。
適材適所、、ですかね。 (スコア:5, 興味深い)
とても頭の回転が速く、バグをあまり出さない。が、ソースがあり得ないほどに汚い。どうやったらこれで動くんだと愚痴られる程。なのでチーム作業で一度問題（…というか怒号飛び交う大喧嘩）になって、一人でも十分こなせる作業、または独立性の高いモジュール開発をやってもらってます。
その方が本人も周りもハッピーなようなのでヨシとしました。そういった方のコードはどんだけ指摘しても変わらないと思いますから、あきらめてポジションを替えるなどして最良のパフォーマンスを出せるようにしたほうが良いと思いますよ。
Re:適材適所、、ですかね。 (スコア:1)
一旦コンパイルして、逆コンパイルしたものを共有するとかねw
でもその人、無駄なところに能力割いてる器用貧乏な気がするなー。
それと過去のコードを思い出せるんだろうか。
正義は人の数だけあるんだよ (スコア:3)
ソースコードの善し悪しの判断もまた同じようなものじゃないだろうか。
他人の書いたコードは汚いものなんだよ、きっと。
この本家のACはガベージ・イン／ガベージ・アウトを熟読すべき (スコア:2, 興味深い)
とりあえず、プロジェクト杉田玄白協賛参加テキストのガベージ・イン／ガベージ・アウト：善き人々が悪しきプログラムに手を染める時 [practical-scheme.net] 原文 [pipeline.com]を読もう。
そして知能指数が20も違えば会話が成り立たないことを思い出そう。
そこまで言っても分からない馬鹿ならば。
djbやクヌースのように、自分の書いたプログラムのバグや脆弱性に対して賞金をかけろと言ってやれ。
破産するころには理解してくれるだろう。
馬鹿には体で教えるしかないのだ。
馬鹿がdjbやクヌースをどれだけこき下ろそうとも、彼等の書いたプログラムは、
綺麗なプログラム（笑）とやらを書く、馬鹿や凡人のプログラムよりバグや脆弱性が少ない。
そもそも人に読ませる必要などないのだ。
コンパイラが読み、正しく実行できればそれで良い。
それが理解できないから馬鹿は馬鹿であり、我々凡人は凡人のままなのだ。
釈迦に説法とは正にこのこと。
天才のすることに口を出してはいけない。
うまく動いているのなら放っておけ、我々如きが口を出すべきじゃない。
結論 (スコア:2)
この世で必要とされるすべてのプログラムをdjbとクヌースが手分けして書けばよい。
Re:この本家のACはガベージ・イン／ガベージ・アウトを熟読すべき (スコア:1)
際限ない質問攻めにするとか、どうでしょうかね。「ちょっと複雑すぎて私にはこの部分が分からないんですが」と延々みんなで聞き続ける。
・・・それでチームか会社としての生産性が上がるかどうかは分かりませんが。
Re:この本家のACはガベージ・イン／ガベージ・アウトを熟読すべき (スコア:1)
そうそう。その通り。
でね。
それを前提にして。
我々「圧倒的大多数の」凡人、逆立ちしても死んでも希少な彼らのような天才にはなれない凡人たちが（おそらくはチームで）プログラミングをするにあたって、どうしたらいいと思う？
というのが元々のACの問いなんだと思うんだよね。
元ネタの困ったコードを書く同僚が天才なのか凡才以下の凡凡才なのかはわからないけど、とにかく彼に周囲の凡人にあわせてもらうにはどうしたらいいか、ってこと。
周囲にあわせる必要が無いような環境で働く超のつく天才たちはいざ知らず、周囲に同僚がいる環境においては、周囲の迷惑になるのは全体の生産性を下げる行動だよね、という観点で見てみたほうがいいんじゃないかと思うんですよ。
それと、現場的に言うと、動けばいい、というのは超短期的な話ですよ。
書き捨てのプログラムとか、ライフサイクルが短かかったり代替商品があったりするものとか。
半年以上とかそれなりに長く働くものであったり、社内／部内システムのようにユーザーの要望に強く結びついたものなどは、上記のものよりも強めに「メンテナンスコスト」を意識しますよ。
それこそ1バイトのメモリをやりくりしてギリギリで商品開発をしていた頃とは違いますからね。
それよりも、多少は実行効率が悪くてもメンテナンスしやすい構造にしておけば、あとが楽（どころかコストの安いところに丸投げとか）できますからね。
全体的なコストを考えれば、そして中・長期的に見れば、プログラミングに所謂天才と凡人以下の存在は不要です。
凡人の、凡人による、凡人のためのプログラムこそが正義ですよ。
あえて例外をあげるとすれば、趣味のプログラムなら別ですけどね。
Re:この本家のACはガベージ・イン／ガベージ・アウトを熟読すべき (スコア:1)
＞メンテナンスしやすい構造にしておけば、あとが楽
と言うのは共通認識になっていないと思います。
と言うより、メンテナンスしやすくする手間など、真っ先に仕分けの対象に
なると思います。
もちろん先になれば仕分けた人間（たぶん収支責任者）が真っ青になるのは
確かですが、ビジネスはファクトが基本で、なかなか先の話は飲み込んで
もらえません。
さらにそういう責任者体質の人は、「後で真っ青になる」と脅すと、自動的に
不屈の精神が起動し、脅した人間を、万難を排してでも討滅すべき対象と
見なすと思います。
そんな簡単に正義だと言えるとも思えません。
たぶん言われてる側だな (スコア:2)
「コメント長すぎますよー」って何度言われた事か。
そりゃそうだ。ギャグ満載で書いてるからな。
でも、ちゃんと読めば理解できるはずだ。
肝心な事はキチンと書いてあるから。
ただ、コメントのうち７割ほどギャグ要素の為のコメントだがな！
って事で、コメントについては悪かったと思ってる。ちょっとだけ（ヲイ）。
ただ、「コードが理解できない」は、僕から言わせれば「頭使えよ」って感じ。
「構造体苦手です」とか「多重配列難しいです」とかは、言い訳じゃね？
（注：以下、愚痴だらけです。気を悪くする人もいると思いますが、吐き出させて～！）
ってか、十年以上一人でコーディングさせといて、今更言うんじゃねーって感じ。
こっちは無理難題な要件をクリアする為に、脳みそフル回転させてんだよ。
で、自分の得意なコーディングは「構造体」や「（多重）配列」をフル活用するんだよ。
僕だってバカじゃないから、キチンと細かく関数化してるじゃん。
引数渡す時に楽になる様に、構造体や多重配列をアドレス参照にしてるじゃん。
その関数の中で値を入れられるようにさ。
オブジェクト指向だか何だか知らんが、クラスもちゃんと作ってるわ。
これが僕のコーディング術じゃ！何が悪い！？
もちろん拡張する時の事も考えて、関数作ってんだよ。
ファイル名も変数名もクラス名も関数名も、分かり易くしてるだろ？
ってかさー、サービス増えても増えても僕一人ってどうよ？
ってかさー、「これ、一回ボタン押すだけで（各サービス）全部出来るようにならないかなぁ？」って・・・。
ああ、やったさ。作ってやったさ。毎日の運用が楽になる為ならと思ってな。
で、クリアすればするほど、要件は更にメンドクサイわ期間は短くなるわ・・・。
いい加減限界で「要員よこせや！」って言っても上はシカト。
そうかいそうかい、僕がつぶれなきゃ人は増えんってか。へ～～～。
な～んて思ってたら、本当にブっ潰れた。体も精神も。
そりゃ一人でさぁ、要件来た後（箇条書きの時もあったな）、社内SEとして
「基本設計」「外部、内部設計」「開発」「テスト」「リリース」「保守」を、全部一人でやってきてさー。
あ、サーバも「UNIX系出来る人少ないから」って、合計で２０台近く面倒みてたんだよ。
ってかさ～、何で社外のサーバまで僕が面倒みなきゃならんの？
IDSを引っ越しするという（相手側都合で）お仕事も、何で僕がPMになっちゃうの？
ASPサービスなんだから社外でしょ？（社外）開発部隊でやれよ。
Solarisをまともに扱えるのが（僕を含め）２人しかいないって、そんなの知ったこっちゃねーよ。
こっちは社内だけで大変なんだよ！って声ももちろんシカト。
結局やったよ。やってあげたよ。ホントめんどくさかったぜ！
ま、そんな状態でやってりゃ、いつかはぶっ壊れる運命だったな。
で、僕の休職中に、新しいサービス立ち上がったらしく、
ついでに「今までの社内システムも見直そう！」ってなったらしい。
で、僕のソースを見て「全然理解できんわ！」って声が殺到したらしい。
結果として、半分くらいはそのまま使ってるらしい。
それでも、工数は相当使ったらしい。おかげ様でヤツらには恨まれます、僕。
でも、新しくリニューアルしたものは、使いづらいとの噂も・・・。
（これらは僕を慕ってくれてる後輩から聞いた話ですので、話半分で）
ちなみに、サーバ関連は外部委託にしたらしい。
クラウドだか何だか知らんが、それでいいなら良いんじゃない？
で、去年の忘年会で、そいつらが表彰された。
運用のシステムリニューアルを成功させたからだって。
で、表彰受けた後の挨拶で、
そのプロジェクトのPMのヤツが、（僕に対する）嫌味を言ってくれまして。
ま、元々お互い嫌い合っていたのもあるけど。
その時、危うく再び精神的に来る所だったので、
僕の今年最初の日記の様な事になったのだ。（さりげなく宣伝）
あ、何か全然別の話になっちゃいましたね。
本当にすみません。ゴメンなさい。
＃今更「健康第一でね」なんて言ってくんじゃねーよ！クソ上層部共め！！
Re:たぶん言われてる側だな (スコア:1)
コメント長すぎますよー
#これでいいですか？
Re:たぶん言われてる側だな (スコア:1)
OKです！
＃こういうツッコミ入れてくれる人が少なくてねー。ありがたいです。
Re:一言二言。 (スコア:1)
＞まずは、本当にお疲れ様、まぁ縁の下の力持ちって意外と評価につながらないんだよね、、、、。
＞もうねこの辺、お前以外はあほかと思う。
ありがとうございます。素直に嬉しいです。
こういう言葉を、社内の人に言ってもらえれば、まだ違ったんですけどね・・・。
＞二言、会社はチームなので一人でやらない努力はすべきです。
＞言っても分からんというのは理解できますが、でもこういった流れになることを
＞あなたは良く知っていたわけですからそれでも、上層部には口すっぱく言うべきです
そうですね。その通りだと思います。
今思えば、途中から「言ってもムダだろうけど一応言うか」くらいになってたので・・・。
もし次も同じ様な事になりそうだったら、何度でも上申します。手を変え品を変えで。
助言、ありがとうございます。
Re:たぶん言われてる側だな (スコア:1)
何でも自分でやっちゃダメよー。
PMさせられたならマシなメンバを何人か要求するとか。
>「構造体苦手です」とか「多重配列難しいです」
それは周囲のレベルがかなり残念だ。
河岸変えたほうがいいんじゃないか？
だいたいにおいてダメな会社には優秀な人は残らないもんよ。
Re:たぶん言われてる側だな (スコア:1)
> tarosukeさん
＞PMさせられたならマシなメンバを何人か要求するとか。
その要求自体が通らないんです。
「（マシなメンバは）皆忙しいから何とかして」で終了。
というか、マシなメンバ自体少なかったかな・・・。
ま、僕の要求の仕方が悪かったのかなぁとも考えてはいますけど。
（スケジュールとか工数とか資料出しても無駄でした）
＞>「構造体苦手です」とか「多重配列難しいです」
＞それは周囲のレベルがかなり残念だ。
やっぱりそうですよね？
僕自身もそう思うのですが、周りの反応は・・・。
残念な会社だったのかなぁ？
＞河岸変えたほうがいいんじゃないか？
結果としてそうなりました。
時期も決まってるので、それまではゆったりさせてもらいます。
Re:たぶん言われてる側だな (スコア:1)
無理っす（笑）
Re:たぶん言われてる側だな (スコア:1)
＞ヘルプサインを放置して倒れたら悪者扱い。
これなんですよね・・・。
ずっと、「失敗しなきゃ何も変わらないかもね」って、
社内DB管理してる人と話してました。
ま、世渡りが下手だという事で、何とか自分を慰めてます（苦笑）
＃そのDB管理者も最近ヤバい・・・
Re:たぶん言われてる側だな (スコア:1)
実質、社内に関しては一人でサービスしてた様なものですがね（苦笑）。
フリーの方が良いのかな？
あ、後、具体的にどの辺が「迷惑」になってるのか、教えていただけますか？
＃イヤ本気で。直せるものなら直したいので。
Re:たぶん言われてる側だな (スコア:1)
えっと・・・マジレスした方がいいのかな？
> 長すぎて読みづらいから書き直して
これを見た時、「コメント長すぎますよー」に対するボケだと思ったので
> 無理っす（笑）
って答えたんですけどね。
＞これがまずいと思わないなら、「迷惑」なのかをいくら教えても無駄。
別にまずいとは思わないので、無駄ならやめときます。
Re:たぶん言われてる側だな (スコア:1)
＞コメントはあなたの鬱屈した精神の掃き溜めどころではありません。
ゴメンなさい・・・
Re:たぶん言われてる側だな (スコア:1)
＞開発はチームでの作業であることが多いので、周りの人を納得させられないお前が全面的に悪い。
そのチームのメンバーが僕一人なんですけど・・・周りの人がいない状態だったんですが。
手伝ってくれるメンバーいたなら、ちゃんと分担しますよ。
＞いやならやめれ
うん、実はそう考えてます。違う方向を考え中です。
Re:たぶん言われてる側だな (スコア:1)
＞さすがにないものからは読みとれないよ。プログラムコードで「行間を読め」はちょっとマジ勘弁
まぁでもギャグ入れすぎて肝心な部分を探すのに
手間をかけさせるのも悪かったなぁと（苦笑）。
＃でも僕が異動した当初のコードにはコメントなかったね・・・
＃だから一から全部書き直した（笑）
Re:たぶん言われてる側だな (スコア:1)
＞> ただ、コメントのうち７割ほどギャグ要素の為のコメントだがな！
＞ここんとこ、詳しく。見てみたいです。
フフフ、それを書くと、
「コメント長すぎ、もっと短く」
ってレスが大量に来る悪寒がするので、辞めときます（笑）。
＃まぁ麻雀に例えたり、直近に見た演劇を利用したりしただけなのになぁ。
Re:たぶん言われてる側だな (スコア:1)
＞そういう俺のノリについてこい的な空気読めなさって、ただただサブいだけですよ。
うん、そうなんだけどさ。
ただ、十年以上一人で書かされた方の身としては、
その辺くらい好きにさせてくれよって思うんですよ・・・。
「どうせ僕以外誰もコード見ないんだろうし」
って思い込んじゃいますから。
＃実際つぶれるまでそうだったしね・・・
Re:たぶん言われてる側だな (スコア:1)
＞コメントを幾つか拝見しても
＞防衛的というか
＞自分のノリをテンション高く押し付けるだけで
＞人の話を聞く気がないように見えます。
そうですね、その通りかもしれないです。
自分を正当化したいと思っているのは事実です。
でなきゃ、自分の十数年が報われないと思っているので。
でも、人の話は聞こうとしてます。
出来てないかもしれませんが・・・。
何か「荒らし」みたいになってしまって、申し訳ないです。
問題ない。 (スコア:2)
もちろん退職前や交通事故で死ぬ前には全てのコードを読めるように直してもらう。たとえ家族との最期の別れをする必要がある場面でも、だ。
つまり、コードを書く人含めて「部品」として取り扱う。改修も夜間障害対応も全部丸投げ。
それが嫌なら書き直させる。
この手の人は直らない気がします (スコア:1)
本人視点では多分何も困っていない。傍目には問題になっていることであっても本人は問題と思っていない。
価値観が違うのだからスマートなコードと比較したところでおそらくかみあわない。
生命の危機とかよほどのペナルティなりインセンティブがない限り変わることはないのではないでしょうか。
単刀直入に (スコア:1)
提案するからだめなのだと。
するなら依頼か命令で。
「読みにくいから直してくれ」と
具体的にどこがダメなのかを明確に
Re:単刀直入に (スコア:2)
タレコミのようなコード書く人が居るから
・ループの入れ子はnこまで
・1行ｎ文字以内
・1メソッドｎ行居ない
等などのアホなコーディング規約出てくるのでしょうね。
でもそういうので縛るのが単純で効果ありそう。
業務系の画面なんかは美しくないかもしれないけど
だらだら書いたほうが読みやすいです。
勝手な解釈でやたらめったら分割されたら読み難い。適切で誰でもわかって短くて見分けのつきやすいわかりやす～いメソッド名、引数の変数名がするする出てくる人なんてそうそう居ない。ってか無理でしょう？
Re:単刀直入に (スコア:1)
底辺で仕事してるとなぁ…。
そういうコードを書く人は、静的解析ツールの指摘内容が理解できないんですよ。
もしくは指摘を黙らせるためだけに、更に悪化させるコード修正をしてきます。
それが現実。
わざとそう書いている (スコア:1)
可能性はないだろうか。
とある現場できっちりとオブジェクト指向設計されたPerlのコードがあった。変に妥協したようなところもなく、素晴らしいコードだと思ったが、そのコードをちゃんと読める人はあまりいなかった。
その「頭のいい」人はそういう状況を避けるため、周りのレベルに合わせるつもりでひどいコードを書いているのかもしれない。
Re:わざとそう書いている (スコア:1)
てっきり、
「他の人にも読めるコードだと他の人にもメンテできるので、自分がクビになる恐れがある。
他の人に読めないオレオレコードならば、メンテできるのが自分以外にいないので、クビになる恐れが少ない」
かと思った。
そういう例は日本だとあるかもしれない。
Re:わざとそう書いている (スコア:1)
以前勤めていた会社、ポーティングすることが前提の業務だったため完全とは行かないものの他の人がメンテする前提で無茶なコードを書くとダメだよと言う社風でした。
（残念ながら明文化はされていない）
その会社へ途中入社したとある人物。（私とは部署違い）
その人物のコードがひどくて、社内で技術トップだった人が可読性も移植性も悪いのでこれこれこういう風に直して欲しいと指摘する事例がありました。
そのときの件の人物曰く「私は技術レベルが高いから他の人間が読めるようなコードは書かないんだ！」とのこと。
周りぽかーん。
その人物は、たしかあまり長く在籍しなかったはず。
javascriptならJSLintを必須に。 (スコア:1)
この手の話は、コード規約をキツめにして守らせる、静的なコード解析や、コメント記載やらを
ちゃんとする、ということにつきると思います。
一例ですが、javascriptは インタプリタが賢すぎてヒドいコードでも 勝手に読みこなして
くれるため、かなり「きれいに」書くのが難しい言語だと思いますが、
静的コード解析器 jsLint を通して 警告が出なければ ほぼ 均質なコードになります。
indentなどもチェックしますので使いはじめこそ膨大なエラーが出てしまいますが、
習慣にしてしまえばラクですし、デバッグ作業も大幅に減りますのでいいことづくめ。
coffeescriptの場合も jsLintでエラー０にすることを必須にしています。
変数名やクラス名がひどい場合には、「名前をきちんとすればコメント記載を減らしてもよい」
というルールがあればいいんじゃないでしょうか。
ちょっと待ってくれないか (スコア:1)
それがすごく知的なソースコードという事はありませんか？
実は、貴方はソースコードを読めないから落書きのように見えるという事はありませんか？
虎の威を借る (スコア:1)
「Googleはこういう規約でやってるよ」とか、他の権威と絡めて説得します。
コードの書き方を提示するだけでは宗教論争で終わってしまうので。
Re:動いてナンボ (スコア:1)
すでに述べられていることなので、マトメ的な話になろうかと思いますが、
一度だけ動けばいいのであれば、好悪は全く問題になりません。
たとえば perlなどで onelinerなプログラムは 記載量が少ないことが
正義であって可読性などは全く求めません。動けば捨ててしまえばいい
コードですね。
二度以上動いて欲しいなら、それは間違った動作をするかもしれないし、
将来的には若干違う動きをしてほしいかもしれない。
となれば、未来の自分を含めた第三者が理解できるように
記載しなくては、それは「悪いコード」となります。
コードコードといいますが、やってることは 自然言語と同じく、
命令を連ねることによる主張そのものですから、何をやっているかを
きちんと人間が分かるように書く必要があります。
とすれば、「読みやすい」ことが良いコードの条件の１つになります。
コメントがその補助になるなら記載すべきでしょう。
あとは保守を考えた場合、同じことを 様々なところに記載してしまうと
問題が起きた場合に、修正箇所の特定が難しくなるばかりか、
修正の網羅性が疑われる状況が発生してしまいます。
エンバグも起こりやすくなります。
随時 リファクタリングをして、同じコトを別箇所で書く、ということが発生
しないようにしなくてはいけません。
ひいては、できるだけ 小さく処理を分けて、メソッドやプロシージャで
分けておくようにしておくこと、が求められます。
モジュール化しておけば、DBやら各種入出力などの変更があっても
ビジネスロジックを守る(そのまま使える)ことができます。
この「保守性」も 良いコードの条件となります。
最後に忘れがちですが、「パフォーマンス性」、
というのも条件のひとつです。
まず、計算量が高い箇所を特定するにはコードがシンプルで
あることが必要です。また、高頻度に稼働する箇所が
不必要な処理で計算量が上がっているなら、そこだけ
別の単純な処理に換えてやる、というようなことをすれば
いいわけで、このようなことを考えれば strategyパターンが
適用できるところはないか、などと考えながらコーディング
することが重要になるでしょう。
Re:動いてナンボ (スコア:1)
>経営者的には少ない金額で同じ機能、
>つまりは費やした時間が短い、
可読性が低ければメンテナンス時の読解に余分な時間を費やすので
経営者的にも同じ結論じゃないですかね
Re:頭が良いからこそ (スコア:1)
小林秀雄、という一般人には難解な評論を書く人がいたが
すごい人だったらしい。
一般人は赤川次郎のネコの話を好んだわけだが。
仕事だから動くことは当然として、誰向けに書いているのか、
を縛るのはなかなか難しいのかも。
Re:えっと (スコア:1)
そういう記述が必要な場面もある、ということはわかりますが、
いまどきのコンパイラはしかるべきコンパイルオプションを指定すれば関数呼び出しのインライン展開やループ展開くらいしてくれます。
（最適なオプションを見つけるのに多少の試行錯誤は必要ですが、手で展開するよりは楽でしょう）
初期のガラケーのJavaアプリなんかはメモリ制限やJavaランタイムの最適化機能の関係でOOP言語らしからぬ記述が必要でしたが、そのうちバイトコードレベルの最適化変換機が出現し、さらに機器やJavaランタイムの性能も向上して、いまどきはそういう記述の必要も薄れています。
MozillaがOSSになった頃のC++ Coding Style Guidelineには「C++じゃなくてBetter Cだからな、コードを短く、読みやすくするための(CになくC++で追加された)基本的な言語機能は無視しろ」とあったのですが(今もかな？)
これはMozillaは移植性を高く保つ必要があり、当時のC++コンパイラの中には実装が不十分なものがあった、という制限の元での特殊事情です。
件の同僚は「私が生まれる前からプログラミングをしており」とのことなので、
貴方の言うようにオーバーヘッドを考慮してそういう記述をしているのだとしても、
コンパイラの最適化がしょぼくて手で最適化せざるを得なかった時代の記述スタイルのままの可能性があります。
最終バイナリのアセンブリダンプとベンチマークで確認しながら進めていれば、
そういう記述が必要な場面というのはそれほど無いと思います。
処理系によるけど（Re:えっと (スコア:1)
inline関数って、レジスタで引数渡してレジスタで返り値受け取るのは明示的にやってやらないとダメだった気が(^_^;
関数渡しのオーバーヘッドというとcallだけ考える人が多いけど、スタックにpush/popする手間とかあるんですよね。
Re:えっと (スコア:2)
そもそも inline は register と同様のヒント情報なので、実際にどんなコードを生成するかは環境次第ですね。
HIRATA Yasuyuki
Re:職業プログラマじゃないけど、「悪いコード」を想像してみました。 (スコア:1)
＞switch文の中に5case以上書かれている。
これは違うと思う。
分岐が非常に多い場合は、いずれにせよ非常に多くのcaseやif文が必要になる。
その場合だと、switchを使うのが一番綺麗な場合がある。
クラス構造とポリモフィズムに置き換えた方が綺麗になる場合もあるが、
いつもそうなるとは限らない。そもそもC言語だと無理だしね。
この手の処理で困るのが、
switch( flag ){
case 1:
ret = funcA();
break;
case 2:
ret = funcB();
break;
.....
default:
.....
}
と関数やメソッドで分割して書かずに、そこに直接ベタで処理を書くこと。
特に上記funcA()やfuncB()の中身が百行以上に及ぶ場合は、後のメンテが面倒になる。
言語によってはオートインデントもマトモに使えないしで、
けっこうな地獄を見ることもあるよ。
あと、break; を省略するコードを書く時は、ちゃんとコメント付けろってのもあったなあ。
Re:職業プログラマじゃないけど、「悪いコード」を想像してみました。 (スコア:1)
んー、多分「５個以上の分岐をするんだったら関数テーブル作ったほうが効率的」と言う話じゃないかと思います(^_^;
と言う型で統一したエントリ関数を作っておいて、分岐後の処理はここでやるようにする。
で、
とか言うアドレステーブルを作っておいて（文法に自信ないけど）、
実際のcase分岐は
とかやっちゃう訳ですよ。
# 色々とツッコミどころがある気がするが、そこら辺はコンパイラのチェック通してないので;-)
CPUエミュレータとかの物凄い大きな分岐をやるときにこの手のテクニックを使いますが（後、同じ分岐が何百回も繰り返されるので流石にコスト考えたらね…とか）。
Re:職業プログラマじゃないけど、「悪いコード」を想像してみました。 (スコア:1)
＞んー、多分「５個以上の分岐をするんだったら関数テーブル作ったほうが効率的」と言う話じゃないかと思います(^_^;
すくなくとも #2301000 の方にはそのように書かれてません。
もしそれを意図したものだとしたら、問題文の方に誤りありですな。
Re:黒いコードでも白いコードでも役に立つソフトが良いソフト (スコア:1)
そういう詭弁は良く聞くけれど、実際には汚いコードは動かないコードであることが多い。
当の本人にだけ読めるけど他の人には読めない安定したコードって、ほとんどの場合は
架空の物語なんだな。