【雑談】美しいコードとは？

[Rittai_3D]

お久しぶりです。3Dです。C++の勉強を始めてもう2ヶ月近くなりましたが、演算子のオーバーロード、仮想関数、継承辺りが危ないですが、順調に進んでいます。

さて、本題に入ります。題名の通り、「美しいコード」とは何かが知りたいです。

とあるプログラミング実況解説動画で、「あまり美しい書き方では無い」と言っていた事を不意に思い出しまして、上の通りです。

綺麗なコードと美しいコードはどこが違うのか、美しいコードの書き方、自分が考える美しいコードとは、等を教えていただきたいです。

言語はC言語、C++、Java、C#...なんでもOKです。

非表示エリア

この非表示エリアを表示するには、登録し、ログインする必要があります。

[FUNK]

例えば「誰もが美しいと思う絵とは？」と言う問いの答えは永遠に出ないように、
美しさの基準は皆違うと思いますので、
コードであってもあくまで「自分が美しいと思うコードは？」にしか答えられないと思います。
（ある人が思う「美しいコード」に対し、また別の人は「美しくない」と思うこともあるでしょうし）

また視点も違うかもしれません。
ある人の「美しいコード」はインデントなどがきっちりされているものを差すかもしれませんし、
またある人は機能的なことを指しかもしれません。


では私が思う「美しいコード」ですが、
それはどんな仕様変更でもコードをより少ない改修で対応できる様に柔軟であることです。
また、より少ない演算数で動くものも美しいと思います。
ただ、この二つは結構相反してるところがあったりとしますので、
私は未だに自分は美しいコードを書けるまでには至っていないと思ってます。

[softya（ソフト屋)]

私にとっても美しいプログラムは永遠の課題です。
・コード的にシンプルである。
・自分にとっても他人にとっても可読性が高い。
・メンテナンスが容易である。
・デバッグが容易である。
・ライブラリの場合、機能的で合理的である。
以上を常に満たしたいものだと思っております。

【追記】
ちなみに、こんな本があります。
「Amazon.co.jp： リーダブルコード ―より良いコードを書くためのシンプルで実践的なテクニック (Theory in practice): Dustin Boswell, Trevor Foucher, 須藤 功平, 角 征典: 本」


こっちは、ちょと本が高すぎ。
「Amazon.co.jp： Code Complete第2版〈上〉―完全なプログラミングを目指して: スティーブ マコネル, Steve McConnell, クイープ: 本」

[usao]

>美しいコードの書き方

逆説的になりますが，
「コードを書くときに『これはどうにも美しい書き方では無い』と思わないような形に書く」
という感じでしょうか．
言い換えれば，「その時最善だと思う形に書く」…かな？

オフトピック

その時そうしたつもりでも，しばらく後に見ると
「なんだこのコードひどい」とか見えたりするけれども，それは自分がその時よりも成長しているからなのだと思うことにする．
で，それが起こらないコード，すなわち，後で「そういや書いたことあるなぁ再利用しよう」となったときに
特に美しくないコードだと思わなかったとき，そのコードは自分の中では「美しいコード」の部類に入るのかも？

[sozai]

初心者なのですが、
・一目で処理が分かる
・シンプル
・一つ一つの関数（メソッド）が長すぎない。
ということだと思います。

コーディングルールについて色々書いてあります。
きれいなコードを書くための鉄則 [単行本](Lepton著)

[Rittai_3D]

皆様、返信ありがとうございます。

>>FUNK様

私が思う「美しいコード」ですが、
それはどんな仕様変更でもコードをより少ない改修で対応できる様に柔軟であることです。
また、より少ない演算数で動くものも美しいと思います。
ただ、この二つは結構相反してるところがあったりとしますので、
私は未だに自分は美しいコードを書けるまでには至っていないと思ってます。

ご意見ありがとうございます。もう少し伺いたいのですが、柔軟なコードとはどのようなコードでしょうか？自分は意識してコードを書いたことがないので、例を挙げて頂けると嬉しいです。

>>softya様

私にとっても美しいプログラムは永遠の課題です。
・コード的にシンプルである。
・自分にとっても他人にとっても可読性が高い。
・メンテナンスが容易である。
・デバッグが容易である。
・ライブラリの場合、機能的で合理的である。
以上を常に満たしたいものだと思っております。

ご意見ありがとうございます。シンプルで可読性が高くてデバッグやメンテナンスが楽に出来るようなコードは自分には一生かかっても書けそうに無いです…。ですが、それらを目標にしてコードを書いて見たいと思います。

>>usao様

>美しいコードの書き方
逆説的になりますが，
「コードを書くときに『これはどうにも美しい書き方では無い』と思わないような形に書く」
という感じでしょうか．
言い換えれば，その時「最善だと思う形に書く」…かな？

ご意見ありがとうございます。言われてみれば、自分がプログラミングを始めた時はその時の、今現在は今は書き方で書いている様です。その時ごとに「この書き方美しい！」と思う書き方で書いているので、書いている内に自然と書けるようになる気がします。逆説的に考えた事がなかったのでとても参考になりました。ありがとうございます。

オフトピック

その時そうしたつもりでも，しばらく後に見ると
「なんだこのコードひどい」とか見えたりするけれども，それは自分がその時よりも成長しているからなのだと思うことにする．
で，それが起こらないコード，すなわち，後で「そういや書いたことあるなぁ再利用しよう」となったときに
特に美しくないコードだと思わなかったとき，そのコードは自分の中では「美しいコード」の部類に入るのかも？

オフトピック

オブジェクト指向の時に勉強した使いまわしが出来るコードに似ているなと思いました。オブジェクト指向こそが本当の美しいコードなのでは？と考えましたが、オブジェクト指向は可読性が高いとは言えるのでしょうか？個人的に読みづらくなると思います。

>>sozai様

初心者なのですが、
・一目で処理が分かる
・シンプル
・一つ一つの関数（メソッド）が長すぎない。
ということだと思います。

ご意見ありがとうございます。一目で処理がわかるような書き方やシンプルなコードは一生の課題になると思います。一つ一つの関数（メソッド）が長くならないということは関数を増やして長くならないようにするという様な解釈であっていますでしょうか？関数一つ一つが長くならないとメンテナンスやデバッグが楽に出来そうですので、これからのコードに取り入れて行きたいと思います。

[Rittai_3D]

自分の知りたい事がわかったので解決とさせて頂きます。

今後、コーディングする時には

• シンプル
• 可読性が高い
• デバッグ、メンテナンスが容易にできる
• 関数（メソッド）一つ一つを短く

を意識して書きたいと思います。

オフトピック

まともに書けるようになるには何年、いや、何十年かかることやら…
早くまともに書けるようになりたいです。

[softya（ソフト屋)]

オブジェクト指向の時に勉強した使いまわしが出来るコードに似ているなと思いました。オブジェクト指向こそが本当の美しいコードなのでは？と考えましたが、オブジェクト指向は可読性が高いとは言えるのでしょうか？個人的に読みづらくなると思います。

に関して言えば、可読性が低くなるのならクラス化が適切に行われていない可能性が高いです。
つまり、オブジェクト指向を取り違えているかもです。

【追記】

まともに書けるようになるには何年、いや、何十年かかることやら…
早くまともに書けるようになりたいです。

あと一番必要なのはプログラムを設計・構築・デバッグできる事です。
その過程で身に付けていくべき事柄と私は思います。
少しづつ進歩するので、明日急に変わることはありません。
とりあえずプログラムを沢山組んで、リファクタリングを沢山行ってください。

【補足】
これ、自分で組んだプログラムに問題意識が無い人には難しいです。
・なんで、こんなに面倒な組み方しちゃうんだろう？直そう。
・デバッグが面倒だな。デバッグしやすくしよう。
・自分でも読んでも意味不明だよ。なんだこのマジックナンバーは？直そう。
・これ使いまわせそうだな。ライブラリ化するためにリファクタリングしよう。
・これより良いアルゴリズムが有るんじゃないだろうか？調べよう。
などなど。こういう感じで自分で疑問・意識を持てるかです。特に意識するのではなく自然にできないと難しいですかね。

[Rittai_3D]

>>softya様

返信ありがとうございます。

オブジェクト指向の時に勉強した使いまわしが出来るコードに似ているなと思いました。オブジェクト指向こそが本当の美しいコードなのでは？と考えましたが、オブジェクト指向は可読性が高いとは言えるのでしょうか？個人的に読みづらくなると思います。

に関して言えば、可読性が低くなるのならクラス化が適切に行われていない可能性が高いです。
つまり、オブジェクト指向を取り違えているかもです。

オブジェクト指向の理解が曖昧なので上手く分けられてないかもしれません。実際、SEクラスとPlayerクラスが上手く分けられてないと思います。（ショット音とかです

あと、一番必要なのはプログラムを設計・構築・デバッグできる事です。
その過程で身に付けていくべき事柄と私は思います。
少しづつ進歩するので、明日急に変わることはありません。
とりあえずプログラムを沢山組んで、リファクタリングを沢山行ってください。

今までは、下手にコードをいじると動かなくなるので遠慮がちでしたので、
既存のコードをリファクタリングしてリファクタリングに慣れて行きたいです。

【補足】
これ、自分で組んだプログラムに問題意識が無い人には難しいです。
・なんで、こんなに面倒な組み方しちゃうんだろう？直そう。
・デバッグが面倒だな。デバッグしやすくしよう。
・自分でも読んでも意味不明だよ。なんだこのマジックナンバーは？直そう。
・これ使いまわせそうだな。ライブラリ化するためにリファクタリングしよう。
・これより良いアルゴリズムが有るんじゃないだろうか？調べよう。
などなど。こういう感じで自分で疑問・意識を持てるかです。特に意識するのではなく自然にできないと難しいですかね。

上にも書いたとおり、遠慮してしまっていました。よく考えれば、バックアップをとっておけばいい事でした。リファクタリングがまともに出来るようにしたいです。

オフトピック

リファクタリングだけでなくて上の事が全てできるようになりたいです。

[FUNK]

ご意見ありがとうございます。もう少し伺いたいのですが、柔軟なコードとはどのようなコードでしょうか？自分は意識してコードを書いたことがないので、例を挙げて頂けると嬉しいです。

実際のソースの提示であれば、標準関数やメジャーなライブラリのソースを参照にしてください。
たぶん一番いい例だと思います。
（私が書いているソースはそれに居たっていないので例として挙げられません）


柔軟とは、関数の目的に対してより完璧に実装されていると言うことです。
例えば、目的が【文字列を出力する】というものに対し、
「マルチバイト文字は使えない」、「変数の値は使えない」といった仕様であれば、
目的を完璧に実装しているとは言えません。
その場合は新しい関数を作成するか、この関数を修正するかというコスト（作業量）が発生します。
その点、標準関数の「printf」は目的に対して柔軟に対応できていると言えます。

ゲームで言えば、昔の「インベーター」では自機の移動は左右のみですが、
ここでそのまま自機の移動を実装する関数を左右に限定してしまうと、
「仕様を変更して四方八方に動かすようにする」となった場合、
また新しく作成するか修正が必要になります。
また初めから四方八方に動かせる様に実装していれば、
他のゲームの作成にもそのまま持ってこれるという利点も出てきます。

つまりここで言う「美」とは「機能美」の事を言っているといえます。


また、時間が無いから等の理由で限定的な実装をするにしても、
今後修正が入る可能性があることを見越して、修正が楽に出来るような書き方をしておくのも大事です。
（ここら辺の話しはソフト屋様の話の方が詳細です）


一人でプログラミングしていると、
目的に対し最短の実装をしてしまいがちで、
それは別に問題は無いとは思いますが、
もしこういうことを意識して柔軟な実装をしていれば、
後々自分を助けることになったり、
それをライブラリ化して世間に広められたりということが出来たり、
また設計脳を鍛えることにもなるかもしれません。

[せんちゃ]

ちゃんと動いて止まらないコードが美しいといえるのではないでしょうか。
予期しないデータが入ってそこでハングアップさせるような作りは美しくないですし、
コードを読み解くときにあちこちジャンプしなければいけない作り方も美しくないです。

よく「関数に分けろ～」とか「クラス化しろ～」とか「継承つかえ～」とかありますが
やりすぎはやりすぎで問題なんですよね。
goto文がダメな理由は自由度が高すぎてあちこちにジャンプできるからですが、
結局クラス化も関数分けも継承も実装内容を見て回らなければいけないという点ではgotoと変わらないし
これらをふんだんにつかったスパゲティコードは下手したらgotoより追えないくらい性質が悪いです。
機能は必要最小限にしましょう、ということですね。


正しくない使い方をしたらちゃんと正しくないよアンタっていうログを出してくれるととても親切です。

機能美としての美しさならそこに尽きると思います。


コードとしての美しさなら誰が読んでもわかるとかじゃないですかね。
あとは直しやすいとか。

例えばある機能を一時的に止めたい、として
１行コメントアウトしただけで止められたらすごく便利ですよね。
これがあちこち見て回ってコメントアウトしなきゃいけなくて、しかもそれをふさいだ途端にまたあちこちで影響が波及して
別のところでエラーが出たり、はたまたハングアップなんてしたらもう作りとしては最悪です。

あと制御構造がネストしすぎてるのも追いづらいですよね。
elseが多いプログラムはちゃんと考えてないコードであることが多いです。

そういうことしないようにってコーディングしてれば必然的に美しくなるはずなのですが、
プログラミングって大抵の場合、業務用なら制作期間付き納期ありで仕様の180度変更も日常茶飯事なので
時間の都合上わかっていてもそうならないケースが多く不細工なコードを量産してしまった悲しい思い出がたくさんあります。

[softya（ソフト屋)]

考え過ぎな気もするので、3D_3Dさん位の経験状態なら、とりあえずコードを書いて書いて書きまくってください。
美しさって言うより、自分が修正やバグでハマらないコードを心がけるだけで良いです。
意識してコードを書いていれば、やがては落ち着く所に落ち着くはずです。

コードを作って、コードの汚さが気になってリファクタリングをしてを繰り替えして、作品として完成できなくなった人も沢山いるので、ほどほどに。

[Rittai_3D]

皆様、返信ありがとうございます。ここ数日忙しくて返信が遅れてしまいました。すいません。

>>FUNK様

柔軟とは、関数の目的に対してより完璧に実装されていると言うことです。
例えば、目的が【文字列を出力する】というものに対し、
「マルチバイト文字は使えない」、「変数の値は使えない」といった仕様であれば、
目的を完璧に実装しているとは言えません。
その場合は新しい関数を作成するか、この関数を修正するかというコスト（作業量）が発生します。
その点、標準関数の「printf」は目的に対して柔軟に対応できていると言えます。

つまりここで言う「美」とは「機能美」の事を言っているといえます。

柔軟とは柔軟に対応出来るという意味だったのですね。自分はまだ柔軟なコードが書けそうにないです。ガチガチに固められたコードが精一杯です。この辺りはプログラミング歴が長くなれば自然とできるようになると思います。そのためにも、コードを書いて書いて書きまくればよくなると思います。あくまで自分の意見ですが。

一人でプログラミングしていると、
目的に対し最短の実装をしてしまいがちで、
それは別に問題は無いとは思いますが、
もしこういうことを意識して柔軟な実装をしていれば、
後々自分を助けることになったり、
それをライブラリ化して世間に広められたりということが出来たり、
また設計脳を鍛えることにもなるかもしれません。

自分は一つのプログラムを書くとき、必要最低限の物だけで書こうとします。処理が遅れそうな気がして。(たとえば、上下キーは使わないゲームで毎回if( /*上キーの処理*/ )～としていたら柔軟性はあっても無駄な気がして何と無く嫌です。)
プログラミングをしていて一番苦手なのは設計です。どのように組んだらいいか、どんな実装にするかで悩んで諦めたりします。設計が得意になる方法が知りたいです。

>>せんちゃ様

ちゃんと動いて止まらないコードが美しいといえるのではないでしょうか。
予期しないデータが入ってそこでハングアップさせるような作りは美しくないですし、
コードを読み解くときにあちこちジャンプしなければいけない作り方も美しくないです。

なるほど、新しいご意見ありがとうございます。自分の書くコードはその美しくないコードの様です。

正しくない使い方をしたらちゃんと正しくないよアンタっていうログを出してくれるととても親切です。

機能美としての美しさならそこに尽きると思います。


コードとしての美しさなら誰が読んでもわかるとかじゃないですかね。
あとは直しやすいとか。

例えばある機能を一時的に止めたい、として
１行コメントアウトしただけで止められたらすごく便利ですよね。
これがあちこち見て回ってコメントアウトしなきゃいけなくて、しかもそれをふさいだ途端にまたあちこちで影響が波及して
別のところでエラーが出たり、はたまたハングアップなんてしたらもう作りとしては最悪です

自分のコードはエラーを吐かずにいきなり落ちる超不親切設計です。
そこで質問ですが、一行コメントアウトしただけで止められる処理はプリプロセッサなどを使うのですか？#ifで分けたりするような仕組みでしょうか？

>>softya様

考え過ぎな気もするので、3D_3Dさん位の経験状態なら、とりあえずコードを書いて書いて書きまくってください。
美しさって言うより、自分が修正やバグでハマらないコードを心がけるだけで良いです。
意識してコードを書いていれば、やがては落ち着く所に落ち着くはずです。

コードを作って、コードの汚さが気になってリファクタリングをしてを繰り替えして、作品として完成できなくなった人も沢山いるので、ほどほどに。

質問するために此処にコードを貼り付けるときに「自分のコードは読みづらくないかな」とか意識をし始めてしまってこのような雑談トピックを建ててしまいました。やはり考え過ぎなのでしょうかね。
とりあえず、書いて書いて書きまくります。一通り完成しましたら、また雑談トピックを建てて自分のコードのレビューをしていただければと思いますが、この間の様にモチベーションが下がらない様に気をつけます。

[softya（ソフト屋)]

当面気をつけることを書いておきます。
１．変数名、関数名、構造体名、クラス名、ファイル名に十分考慮して名前をつける。これだけでかなり変なことはしなくなります。
※　関数名に反するコードを書かなくなるので。
２．長くなりそうな関数はすぐさま分ける。
３．マジックナンバーはconstやenumで名前をつける。分かりやすい数値の1とか0まで名前をつけるやり過ぎに注意。
４．スコープを考慮する。

[sozai]

一つ一つの関数（メソッド）が長くならないということは関数を増やして長くならないようにするという様な解釈であっていますでしょうか？

はい。ですが、その時の処理に応じて関数(メソッド)を短くするか否か、判断すべきだと思います。

[Rittai_3D]

返信ありがとうございます。

>>softya様

１．変数名、関数名、構造体名、クラス名、ファイル名に十分考慮して名前をつける。これだけでかなり変なことはしなくなります。
※　関数名に反するコードを書かなくなるので。
２．長くなりそうな関数はすぐさま分ける。
３．マジックナンバーはconstやenumで名前をつける。分かりやすい数値の1とか0まで名前をつけるやり過ぎに注意。
４．スコープを考慮する。

ありがとうございます。分かりやすい変数名、関数名などをつけたいと思います。

ところで、ハンガリアン記法は使用したほうがいいでしょうか？龍神録のC++版をダウンロードさせていただきましたが、変数名がm_uPowのようになっていたので気になっていましたので。

>>sozai様

はい。ですが、その時の処理に応じて関数(メソッド)を短くするか否か、判断すべきだと思います。

わかりました。関数を増やしたほうがコードが長くなるということもありそうな気がします。

[softya（ソフト屋)]

ところで、ハンガリアン記法は使用したほうがいいでしょうか？龍神録のC++版をダウンロードさせていただきましたが、変数名がm_uPowのようになっていたので気になっていましたので。

ハンガリアン記法信者ではないので、どちらとも言えません。
ただし、分かりやすい変数名などのルールは統一して設けるべきだと思います。

わかりました。関数を増やしたほうがコードが長くなるということもありそうな気がします。

分かりやすさを優先すればコードが増えるのは必然です。
一つの関数のコードが長いのと、整然と関数分けされて長いのでは後者の方が可読性が高いです。
つまるところ可読性の高さが必要なのであって、コードの長さはケースバイケースです。
※　関数が１画面に収まらないと許せない人もいます。