コードを読みやすくするために意識していることを教えてください。
解決済
回答 6
投稿
- 評価
- クリップ 5
- VIEW 3,044
最近開発をしていて思うのはコードリーディングは自分でコード書くより大変な時があります。
なんとなく、自分はコードリーディングが下手なのか、書かれているコードがおかしいのか、大した動作をしていないのに、ものすごくコードを読むのに時間がかかることがあります。
読みやすいコードを書くのは基本ですが、現実は読みにくいコードをなんとか読まなければならない状況の方が多いと思っており,共同開発者やオープンソースコミッターがデザインパターンに沿ってコードを書いていることを期待してはいけなく,最近では無からコードを生成する能力に比して,読みにくいコードでも読める力のウエイトの方が実務では大事なのではないかと思うようになりました。(自分が1から書けば良くなることがわかってる状態だとしても,何がしたいのかをコードから読み取らなければならないことが多いからです)
どうすれば読みにくいコードでも効率良く読み進めることができるか方法を思索しています。
最近ではものすごく時間をかけて調査した結果、些細なバグの原因が全くそのクラスと関係ない場所で定義されたメソッドで副作用起こしてるから等がありました。
特に読みづらいと思ったのは以下のような特徴を持つプロジェクトのコードです。
- moduleと継承が混在していて名前空間で分かれていないメソッドの呼び出し(どのファイルで定義された関数,メソッドなのかがわからない)
- そのスコープにおいて有効な変数が多すぎる(やむを得ない場合もありますが一時変数すらインスタンス変数に設定してあるものなど,インスタンス変数の定義場所と使用場所の区別がつかない場合など)
- 処理の途中で違う処理が挟まってる(単一処理できないこともありますが)
- 継承の多用(概念的に綺麗であれば大丈夫ですが分岐や深過ぎる継承同じ概念でまとめられるはずの継承)
- 大き過ぎるメソッド
- 小さすぎる大量のメソッド(的確に切り分けられてないと定義を飛び続けて元のコードの処理を追いづらくなる)
- 処理フローがめちゃくちゃなメソッド（名前と実行してる処理が違う,名前に対して色んな処理をしすぎ）
- 同じ処理が複数ファイルに散在している(読みづらい上に一箇所の変更が複数ファイルに伝播して直すのも大変)
このような特徴を持つコードでも読む時に意識すると読みやすくなるってことありますか？もしコードリーディングで意識していることがあれば教えて下さい。(ファイル上に存在しないメソッドは継承,標準ライブラリ,mixinで的を絞るなど)
よろしくお願いします。
-
気になる質問をクリップする
クリップした質問は、後からいつでもマイページで確認できます。
またクリップした質問に回答があった際、通知やメールを受け取ることができます。
クリップを取り消します
-
良い質問の評価を上げる
以下のような質問は評価を上げましょう
- 質問内容が明確
- 自分も答えを知りたい
- 質問者以外のユーザにも役立つ
評価が高い質問は、TOPページの「注目」タブのフィードに表示されやすくなります。
質問の評価を上げたことを取り消します
-
評価を下げられる数の上限に達しました
評価を下げることができません
- 1日5回まで評価を下げられます
- 1日に1ユーザに対して2回まで評価を下げられます
質問の評価を下げる
teratailでは下記のような質問を「具体的に困っていることがない質問」、「サイトポリシーに違反する質問」と定義し、推奨していません。
- プログラミングに関係のない質問
- やってほしいことだけを記載した丸投げの質問
- 問題・課題が含まれていない質問
- 意図的に内容が抹消された質問
- 過去に投稿した質問と同じ内容の質問
- 広告と受け取られるような投稿
評価が下がると、TOPページの「アクティブ」「注目」タブのフィードに表示されにくくなります。
質問の評価を下げたことを取り消します
この機能は開放されていません
評価を下げる条件を満たしてません
質問の評価を下げる機能の利用条件
この機能を利用するためには、以下の事項を行う必要があります。
- 質問回答など一定の行動
-
メールアドレスの認証
メールアドレスの認証
-
質問評価に関するヘルプページの閲覧
質問評価に関するヘルプページの閲覧
checkベストアンサー
+4
はるか昔からコードの解読しやすさというのは永遠の命題でして（ちと大げさ？）、人がコードを書く以上は避けられないことになっています。
※がちがちに規則を決めて、誰が書いても似たようなソースにしかならないようにする、というアプローチを取ったのが COBOL というのは言い過ぎですかね？
最近はリファクタリングツールや、ソースの整形ツールがあるからまだしもですが、昔はそんなのありませんでしたし。
結局のところ、コードリーディングについては行う人のスキルに依存するしかない、でしょう。
せいぜいがツールを使って、自動整形とか自動で不要なローカル変数を消してしまうとかくらいでしょうか。
あとはデバッグに関して言えば、コードの全てを追いかけようとはせず、まず問題が起きている場所を特定すること。エラーになるとすれば、何らかのエラーを引き起こす情報が変数にセットされたわけですから、そこから変数の内容を全部洗いだして、逆にたどる（どこでその変数の内容がセットされたのか？）、くらいですかね。
投稿
-
回答の評価を上げる
以下のような回答は評価を上げましょう
- 正しい回答
- わかりやすい回答
- ためになる回答
評価が高い回答ほどページの上位に表示されます。
-
回答の評価を下げる
下記のような回答は推奨されていません。
- 間違っている回答
- 質問の回答になっていない投稿
- スパムや攻撃的な表現を用いた投稿
評価を下げる際はその理由を明確に伝え、適切な回答に修正してもらいましょう。
+4
命名がすごく大事だと思います。
コメントがなくても意図が伝わるようなコードを書ければベストなのではないでしょうか？
http://qiita.com/chooyan_eng/items/72f86a2ce2ca67d3b4a4
個人的にすごく参考になった記事です。
後はメソッド分割。テスタブルなコードを書くことでリファクタもしやすくなります。
投稿
-
回答の評価を上げる
以下のような回答は評価を上げましょう
- 正しい回答
- わかりやすい回答
- ためになる回答
評価が高い回答ほどページの上位に表示されます。
-
回答の評価を下げる
下記のような回答は推奨されていません。
- 間違っている回答
- 質問の回答になっていない投稿
- スパムや攻撃的な表現を用いた投稿
評価を下げる際はその理由を明確に伝え、適切な回答に修正してもらいましょう。
+3
先人の残した良いやり方を学び、素直に取り込んで行く努力ですね。
投稿
-
回答の評価を上げる
以下のような回答は評価を上げましょう
- 正しい回答
- わかりやすい回答
- ためになる回答
評価が高い回答ほどページの上位に表示されます。
-
回答の評価を下げる
下記のような回答は推奨されていません。
- 間違っている回答
- 質問の回答になっていない投稿
- スパムや攻撃的な表現を用いた投稿
評価を下げる際はその理由を明確に伝え、適切な回答に修正してもらいましょう。
+2
ソースにコメントがあれば少しは読めるかもしれませんが、コメントすら無いソースだとかなりきついですね。（コメントが間違っているときもあるので厄介ですが）。
そういう時は、自分でコメントを入れていく場合があります。コメントなら動作に影響はないですからね。（ソースを改変してはいけないというのはありますが、コメントを自分で入れたソースは解読のためだけに使用し、ビルドに使わなければ問題はないでしょう）
またはUML図を起こしながら読んで見るというのも有効かもしれません。（私は余りやりませんが、UMLに慣れている方ならそのほうが良いかもしれません）
投稿
-
回答の評価を上げる
以下のような回答は評価を上げましょう
- 正しい回答
- わかりやすい回答
- ためになる回答
評価が高い回答ほどページの上位に表示されます。
-
回答の評価を下げる
下記のような回答は推奨されていません。
- 間違っている回答
- 質問の回答になっていない投稿
- スパムや攻撃的な表現を用いた投稿
評価を下げる際はその理由を明確に伝え、適切な回答に修正してもらいましょう。
+2
Rubyの話が多いようですが、ほかの言語の話で良ければ・・・
読みずらいなとおもった場合、私の場合はリファクタリングします。
変更後、コミットできない場合も多いですが、理解するには手を動かすのが一番なので、お構いなしにリファクタリングします。（個人でこっそり持っておきます。）
ある程度、ぐちゃぐちゃしたコードだといくつか新しいバグが見つかります。
ロジックの見落としでバグがある場合の原因は、いつもソースコードが読みずらいことに原因があるとみなしています。
あと、自分で書くときは単体テストがやりやすいように書けば、ある程度きれいに書けたとみなしてます。
投稿
-
回答の評価を上げる
以下のような回答は評価を上げましょう
- 正しい回答
- わかりやすい回答
- ためになる回答
評価が高い回答ほどページの上位に表示されます。
-
回答の評価を下げる
下記のような回答は推奨されていません。
- 間違っている回答
- 質問の回答になっていない投稿
- スパムや攻撃的な表現を用いた投稿
評価を下げる際はその理由を明確に伝え、適切な回答に修正してもらいましょう。
0
まだまだ読みづらいコードだし、命名が自分で書いてひどいなぁ…と思うときは沢山ありますが、これは勉強になりました！
https://books.google.co.jp/books/about/リーダブルコード.html?id=Wx1dLwEACAAJ&redir_esc=y&hl=ja
投稿
-
回答の評価を上げる
以下のような回答は評価を上げましょう
- 正しい回答
- わかりやすい回答
- ためになる回答
評価が高い回答ほどページの上位に表示されます。
-
回答の評価を下げる
下記のような回答は推奨されていません。
- 間違っている回答
- 質問の回答になっていない投稿
- スパムや攻撃的な表現を用いた投稿
評価を下げる際はその理由を明確に伝え、適切な回答に修正してもらいましょう。
15分調べてもわからないことは、teratailで質問しよう！
- ただいまの回答率 88.09%
- 質問をまとめることで、思考を整理して素早く解決
- テンプレート機能で、簡単に質問をまとめられる
2017/02/23 18:38
COBOLで書けば、似たような見た目になるのは事実ですが、見た目が同じでも、ほっとけばかなりづらくなるので、構造化プログラミングを取り入れ読みやすいコードを意識するようになりました。（日本だとたぶん８０年代の話。）
と書いてプロフィールたら、tacsheavenさんもCOBOL書けるみたいですね。
読みにくさに関しては言語の制限以前の問題であることの方が多いというのが印象です。
2017/02/23 18:46
構造化なにそれなコードばかりでしたねえ……
2017/02/24 11:44
COBOLの話ってする場所がないのでつい、話題がそれてしまいました。失礼しました。
2017/02/24 12:06 編集
読めば大体なぜ読みにくいかは分かるのですが,読みにくさのパターン化はしにくいですからね・・・。
> 最近はリファクタリングツールや、ソースの整形ツールがあるからまだしもですが、昔はそんなのありませんでしたし。
これは本当にその通りですね。それでも時間がかかって気になるところは絶えないので、今後ももっといい時代になっていく気がしてます。もっとIT業界の生産性があがる技術が出てくるといいですよね。
2017/02/24 12:12