skillup

技術ブログ

プログラミング全般

読みやすいコードについて

投稿日:

コードリーディングにおいて聖典となっているリーダブルコードについて読んでいこうかと。

ただ読んでいくだけではつまらないので、自分なりの考え方も書いていきます。

優れたコードの定義

まずは優れたコードの定義から。

リーダブルコードでは「読みやすい、理解しやすいコード」って書いてあります。

目的としては当然、保守しやすくするためで「他人が読んでもわかる状態」にすることが大切。ちなみにこの場合の「他人」で最もあり得るのは将来の自分でしょう・・・

少し時間がたつとコードって基本わけがわからなくなるので・・・これには完全に同意。

読みやすいにもいろいろあるかとは思いますが、下記のようなことが大事。

短いコード

自分の場合、一番注意しているのはこれですね。基本的にプログラムは長ければ長いほど理解しにくくなります。なるべく処理ごとに分割して短いコードを目指しましょう。目安としては20~30行以内になるようにしています。

50行を超えるような場合、特別な理由がなければ別メソッドに切り出したほうがよいでしょう。長くしていいのはコントローラー的なメソッドか並列的な処理(switch)が続いた場合のみにしてます。

処理が複雑でない

短くても無理やり1行にしていたりとか、かえってわかりにくくなっているコードは少なくありません。

短くするのは理解しやすくするための手段なので長く書いたほうが理解やすい場合は当然長く書いたほうがよいです。

次回以降もっと具体的に書いていきます。

ちなみにコードに関して参考になった記事を下記に。

http://anopara.net/2014/04/11/%E3%83%97%E3%83%AD%E3%82%B0%E3%83%A9%E3%83%9F%E3%83%B3%E3%82%B0%E4%B8%AD%E7%B4%9A%E8%80%85%E3%81%AB%E8%AA%AD%E3%82%93%E3%81%A7%E3%81%BB%E3%81%97%E3%81%84%E8%89%AF%E3%81%84%E3%82%B3%E3%83%BC%E3%83%89/

 

-プログラミング全般
-

執筆者:


comment

メールアドレスが公開されることはありません。 * が付いている欄は必須項目です

関連記事

no image

バッチスクリプトで気をつけたい点

実務でバッチ処理を作る際に気をつけるべきと思ったこと。 基本的にエラーをいかに捉えていかにログに吐くかを最初に考える。まずはエラーありき。失敗するもの、想定した値がこない、あるいは値がないを前提として …

no image

便利すぎる道具の弊害

現在、Javaのプロジェクトでは会社でNetbeansを使っていますが、IDEを使っているばっかりに理解できていないところがありました。便利すぎる道具の弊害ですね・・・ IDEについて一応説明をしてお …

no image

フレームワーク作成時の注意ポイント

以前も多分書いていますが、フレームワーク作成時のポイントなどを列挙。 次元が違うものも多々含まれているかも。 ルーティング機能 基本設定情報の読み込み キャッシュ機能 データベース Form情報の管理 …

no image

シェル基礎2

シェルコマンド使い始めて数年たちますが、いまだに知らないことはおおいですし、早く知っとけばよかった的なこともたくさんあります。 そんな小ネタ集を alias よく使うコマンドを別名で登録することができ …

no image

オブジェクト指向 アプリケーション層に関して

本日も引き続き「現場で役立つシステム設計の原則」を読み進めてます。 本日は主にアプリケーション層(以下AP層)。MVCモデルでいうところのコントローラーに近い?)の考え方について。 Contents1 …