Q&A
回答ありがとうございます。
統一感はあるかもしれませんね。特にわかりやすさとは必ずしも一致しない場合もあり得ると思います。
特に、Dosのバッチファイルを作るなど、文法が豊かでない環境でのコーディングの際には、統一感を出すときれいだと感じたことを思い出しました。
ソースが汚いという質問をみて、そういえはいろいろ詳しい人に聞いてみたかったことを思い出しました。
それほど困ってはいないのですが、”きれいなコード”という表現を聞くことあります。抽象的で何を指しているのかわからずこの言葉を聞くたびに軽く混乱してしまいます。
その時々で尋ねればいいのですが、ついでで訊くにはややこしい問題かもしれないと思い控えていました。
数学的な美しさがあるアルゴリズムに対して美しいと呼ぶのはわかります。これは”美しいコード”であって、”きれいなコード”と呼ぶときの文脈とは違って使っているように思えます。
”わかりやすいコード”が近いと思っていますが、そう呼べるのならそう呼ぶはずです。そんなに長い表現でもないとおもいます。（私は、いつもわかりやすい結果として、バグがないコードが書ければ充分と考えています。）
意見がばらけるのか、誰かの説明に高評価がつくのかもわかりませんが、いろいろな意見が聞けると嬉しいです。
回答8件
0
ベストアンサー
きれいなコードとはどんなものでしょうか？
実装のキレイさと、設計のキレイさがあります。
実装のキレイさは、『リーダブルコード』で述べられていた
理解するのにかかる時間の短さが尺度になります。
実務上は最終的に開発や保守のコストを減らせればいいので、
宗教論争に陥らない具体的なモノサシとして使えます。
たとえば、連番の変数名とか、関数が長過ぎるとか、
入れ子が深いとか、循環的複雑度が高いとか、どれも
理解するのに時間がかかるから、キレイでないのです。
設計のキレイさも、同じ考え方で理解時間を尺度にできますが、
設計の場合とくに、コード変更時の読む量の少なさが目安になると思います。
よく言われる、グローバル変数を追放するとか、高凝集・疎結合とか、
DRY原則とか、単一責任の原則とか、どれも突き詰めていくと、
コードを変更・修正・拡張したいときに、読む量を減らしたいわけです。
たとえば、グローバル変数を使いまくると最悪、一行目から全部読むハメになります。
すると仕様変更に弱くなったり、保守コストが高くなったりします。
だから、なるべくスコープを限定して、読まなくてもいい部分を増やそうと。
つまり、なるべく実装を読まずに済ませられるのが良い設計であり、
オブジェクト指向（のカプセル化）もその延長線上にあると考えます。
要するに、プログラミングは書くより読む方が大変なので、
楽に読めるのがキレイな書き方、インデントをつけなかったりして、
楽に書ける（が読むのは大変な）のがキタナイ書き方、という考え方です。
これは単純化し過ぎているきらいもありますが、
原則は単純な方が汎用的で守りやすいので、まずこれらを意識しています。
投稿2016/11/12 14:13
総合スコア5592
0
一言で言うなら、「統一感があるコード」でしょうか。
「わかりやすいコード」にも繋がることかもしれませんが、個人的には以下のような点がきれいなコードだと感じる部分ですね。
- ネストに応じてインデントが適切に揃えられていること
- 処理や内容毎(定数、変数、取得用／設定用メソッド、等)に集約し、区切られていること
- 類似の処理は同じ記述で統一していること
投稿2016/11/11 01:15
総合スコア408
0
読みやすく何をしているのか少し読むだけで簡単に頭に入るコードではないでしょうか
投稿2016/11/11 00:53
退会済みユーザー
総合スコア0
回答ありがとうございます。きれいな字と同じように誤解なく読みやすいということですね。
”読みやすいコード”と呼ばないのはなぜでしょうか？印象よりも正確な表現を好むのがプログラマーだと勝手におもっているので、なんとなく違和感があるのです。そんなことはないですか？
大抵読みやすいコードはインデントが完全で(それ以外だとまず読みづらい) どれも似たような完全な形をしていて変数の類も誰が見てもわかる名前になっていてやはり同じ機能には似たような名前がつけてあり個人差がなく統一された規格書のような様相を呈していて一目で「きれい」と感じられるためそう呼ぶ方が感覚的に違和感がないのでそう呼ぶのではないでしょうか
「読みやすい」だと一目見た時の独特の完璧な印象が伝わりません
”独特の完璧な印象”があるのが、”きれいなコード”とういことですね。
私にはその感覚がないので、理解できない原因がわかった気がします。
例えば、私はインデントについて、コーディング規約には沿うべきとは思いますが、同一ファイル内で一致していれば２文字だろうと４文字だろうとさほど気にしません。
命名規則については、論理的に問題なければコレクションクラスの表現が、xxList/xxs/xxCollectionが混在していても気にしません。（もちろん継承があるものは親クラスの表現をまねるのは当然だとおもいます。）
書式に関しては、Excel報告書を廃止して、プレーンテキストで提出するように変更しました。
これらの点は周りと意見がずれていて気持ちが悪かった点です。
0
他の方の意見と被る点もありますが、敢えて日本語的な考え方をしてみます。
「きれい」という言葉の内、コードに対する用法として当てはまりそうなのは以下の通りです。
１．色・形などが華やかな美しさをもっているさま。
２．よごれがなく清潔なさま。
３．乱れたところがないさま。整然としているさま。
つまり「きれいなコード」という言葉には、
「数学的・論理的な美しさがあるコード」も
「余計なゴミ（例えばどこにも使われていない変数など）が無いコード」も
「インデントや命名規則がしっかり整頓されている（＝読みやすい≒分かりやすい）コード」も
全て内包されている訳です。
どれか１点を強調したいならそれこそ「整頓されているコード」などと言うと思いますので、
「きれいなコード」と言われた時は上記全てをひっくるめて言っているんだな、
と私は認識しています。
（言葉の認識は個々人により差がありますので、真意を確かめたいなら言った相手に説明を求める他無いとは思いますが）
ちなみに「きれいだけど動かないコード」も存在し得るので、きれいさとバグがあるかどうかは別問題になるかと思います。
投稿2016/11/11 07:06
総合スコア11427
回答ありがとうございます。
なるほど、３点をひっくるめていると確かに”わかりやすいコード”でなくて、”うつくしいコード”という表現がいいですね。
「きれいだけど動かないコード」も存在し得るというのも同意します。ただ、論理的で余分な部分がなく、しっかり整理できているコードが動かない場合、そうでなくて動かない場合に比べて動くようにするのはずいぶん簡単なことだと推測します。
0
’きれいな’というの事に’コード’に限らず仕事の面で考えると、
0. あるべきところに配置されている。
コードで言えば、機能別のモジュールがあり、集約されている。
仕事で言えば、キャビネットがあり、机の引き出しの意味を知っている。共用のものは用途別に配置されている。
0. まとまりがある。
漠然としていますが、乱雑でない。
仕事環境ではキングファイルなど特定の形でドキュメントがファイルされている。
0. アクセスしやすい。
コードで言えば、パラメーターのルールなどが直感的に分かりやすい。
仕事で言えば、どの資料はどこ？って探したり考える時間が無駄なので。
0. 一目で分かる。
コードの場合、ある程度のまとまりをモジュール化して、エディターの画面に移動が少なくて済む。
コメントは取扱い説明書と注意事項。
仕事で言えば、視覚的に検索する範囲が少なく済む工夫。
0. 使いやすい。
コード的には自分も含めてだれでも分かる。（できるだけトリッキーでない）
重複する部分も多いですが、古典的なアセンブラやBASICなど'GOTO'多用して’スパゲティー’なんて呼ばれたコードが、構造化へ。C辺りから’小さく作って大きく動かす’と数画面で１つの関数、階層化して'main'などをコンパクトになんて流れは上記の基本思想からと考えています。
余談ですが机の引き出しの話、意外と知られていないのが元々の設計コンセプトでは、一番上の薄く幅広の部分は収納ではなくて作業切り替えの一時退避場所、右側の引き出しは上から’ステーショナリー’、’辞書類’、’ファイル収納’って役割がある。
コードだけでなくて、システムでも各フォルダー（ディレクトリー）の構造も上記の考え方からでしょう。
投稿2016/11/11 01:48
総合スコア3747
回答ありがとうございます。
具体的な話でわかりやすいです。
ただ、これらの点はすべて”わかりやすい”も同時に含んている気がするのです。”きれい”でも”わかりやすい”でもどっちでもいいよという話であれば全くその通りだと思います。
机の引き出しの話、初めて聞いて驚きました。リファレンス系の本のサイズがあのサイズなのは、やはりその引き出しに入れる為なのでしょうね。
0
この２つは同じ計算をしています。
go
1c := complex(1.0, 2.0) 2fmt.Println(cmplx.Abs(c)) //[2.23606797749979]
go
1f1 := 1.0 2f2 := 2.0 3fmt.Println(math.Sqrt(math.Pow(f1, 2) + math.Pow(f2, 2))) //[2.23606797749979]
下は上よりも関数が入れ子になっていて、きれいでない印象を受けるかと思いますが、
ピタゴラスの定理とプログラムを知っていればなんの計算をしているのかひと目見てわかります。
逆に上は、複素数(虚数と実数を足したもの)を使用しているので、苦手意識を持つ人が多いです。
きれいでわかりにくいコードと、きれいでないけどわかりやすいコードといえるでしょう。
ここから考えるに、入れ子が少ない、一行が短いものがきれいなコード
逆に、一般的な書き方をするものがわかりやすいコードとなるのではないでしょうか。
他にも個人的には
- 文字数が少ない
- インデントが少ない
- 行ごとの文字数の差がすくない
- 同じコードが複数箇所に存在していない
- 書き方が一貫している(同じ基本的に関数を呼び出す、)
こういったコードをきれいに感じます。
投稿2016/11/11 06:09
総合スコア868
回答ありがとうございます。
複素数を知ってるからかもしれませんが、私には上のほうがわかりやすいコードに見えます。
また、大げさな比較かなと思います。私はわかりやすさのためには、２番目のコードは下記のようなコードを書きます。(goのコンパイルが通るかは判りませんが・・・)
// ピタゴラスの定理 c^2 = a^2 + b^2 より原点からの距離absを求める
abs := math.Sqrt(math.Pow(1.0, 2) + math.Pow(2.0, 2))
fmt.Println(abs) //[2.23606797749979]
このコードと上のコードではわかりやすさでは差がないように感じられます。ただし、ComplexクラスのAbsがあるのに使わないのはDRYの原則に反している点はありますが、この点はメンテナンス性の話なので別の問題だと思います。
・ピタゴラスの定理は義務教育、複素数はそうでない
・Sqrt()やPow()は一般的だけど虚数型は存在する言語が限られる
主観的に素早く理解できるかどうかではなく、このように客観的に考えると理解できる人の割合はやはりピタゴラスの定理の方が多いと思います。
質問者さんのコードの方がきれいですね。
また、コメントをつければわかりやすさの差は埋まるのかもしれません。
見る人がソースコード自体は流し見してコメントだけで処理の流れをつかむのなら、差はまったくないと言えますね。
知識を義務教育に限るというのは、どうかと思います。誰が読むかはもっと色々な偏りがあるはずで、それによって最適な表現は変わってくるはずです。（話題がずれて来ていますね。すみません。）
”きれい”というのは何を形容しているのかが、私には理解できないのです。当然、主観的な判断を含んでいることは理解出来ますが、どのような場合にそういうのかが解りません。
コーディング規約を守り、適切な命名をしたら、”きれい”なのであれば反対は、「規約を守っていない」とか、「全体的に名前が不適切」など具体的な指摘があるだけで、”汚いコード”はないことになるので、不思議なのです。
その"具体的な指摘があること"と"汚いコードであること"は両立しないのでしょうか？
すみません。よく解りませんでした。
説明が適切ではなかったかもしれないので、言い換えます。
intelfikeさんが挙げているきれいなコードの条件は、基本的にコード規約て定義できる程度に具体的な内容で、規約が守れていればきれいと言って良いのでしょうか？（もちろん逆よりきれいです。）
0
一言で言うと美学があるコードですかね
こう云う風に整理するという美学、ある一定のメソッドを使う為の美学等、
生き様といっては言い過ぎではありますが、
そのコードにおける一定の美学を感じられるかがキレイなコードの判定基準ですね
投稿2016/11/18 02:01
総合スコア702
回答ありがとうございます。
生きざまが入ってくるとちょっと怖いです。インデントの好みの話とか振りたくない感じですw。
美学あるコードという意見ありがとうございます。
0
私は、コードを「●●なコード」と表現する時は、
どのような自然科学的事実を基準として、そう表現したかを
合わせて表明すべきと考えました（理由は後述に補足しました）。
言い換えると、基準のないただの「●●なコード」と言った場合は、
確実にそうであるようなコードは実在しない、と考えました。
「きれいなコード」であれば
例えば「会社のコーディング規則にそっている」という事実を基準に「きれい」と表現した、などです。
基準のない「きれいなコード」は幻であり到達しえないので、目指すべきではないのでしょうね。
「わかりやすいコード」も「●●なコード」の一部でしょう。
こちらは個人の知性に大きく依存していると思われる為、
基準となる事実を示しにくいのではと考えています。
従って、基準を示しにくい「わかりやすいコード」と言うものは、
基準を頑張って考えるより、そもそも実在しえないと考えてしまったほうが良さそうに思います。
そう考えますと、技術的な事を語るべき場面では、
不適切な表現なのではと自戒の念を込めてそう思います。
よく、例えばオブジェクト指向プログラミングについての質問が出ると
「わかりやすい」という旨の回答を見かけますし、
そのように回答をしてしまいがちです。
しかし、これは例えばオブジェクト指向プログラミングは何者か、
という基準を示さずに（示せずに）個人の主観的な表現に逃げている可能性に気づき、
反省すべきなのだろうなと思いました。
～～～～～～～～～～～～～～
補足
「●●なコード」という「●●な」というものは形容詞です。
形容詞は本質的に主観的であり、
「●●と感じている」と表現した「ある特定の個人」が必ず存在しています。
「ある特定の個人」は、別の個人からすると他人です。
人間は他人の感じたこと（知覚）を、そのまま感じることは出来ません。
つまり、そういった知覚に関する情報（形容詞）を確実に共有する為には、
個人と結びついている知覚以外の情報、つまり検証可能な自然科学的な情報が必要であろうと結論付けました。
投稿2016/11/14 09:10
総合スコア227
回答ありがとうございます。
私も同じ意見です。具体的に伝えてほしいのに形容詞をつたらえれると困惑してしまうのです。
このサイトでは「オブジェクト指向で書きたいです」と書く人が多くあります。多くの人がどうしてオブジェクト指向で書きたいのかは書かずに質問していいて違和感を覚えます。なので毎回、オブジェクト指向でなくても問題がないこと、その点を踏まえてオブジェクト指向の良い部分を説明するようにしています。この点は同意してもらえるのではないでしょうか。
ただし、形容詞は主観なので、コードを評するのに不適切かというとそうでもないと思います。
というのも、主観的な評価であってもコードを読む人の一人で、コードはコードを読む人・メンテする人（利用者）のためにあります。（使い捨てのばあいはだれも見ないですみます。）主張を聞いた人から見れば、客観的な意見の一つです。
利用者の多くが肯定的な意見を持つコーディングは推奨されるべきだと思います。そういった意味でどういった印象かを主観で表明することは必ずしも悪いことではないと思います。
私の場合も、可能であればその根拠を示してもらって私も相手も納得するコードにしたいと考えています。そういった場合に、相手が持つ”きれいなコード”という言葉から連想されるものが想像できず質問をしているというわけです。
あなたの回答
tips
プレビュー
バッドをするには、ログインかつ
こちらの条件を満たす必要があります。
2016/11/13 13:48
2016/11/14 21:40
2016/11/18 01:18
2016/11/18 01:52 編集
2016/11/18 08:55