skillup

技術ブログ

プログラミング全般

短いコードを書く

投稿日:2016年7月10日 更新日:

私が普段コードを書くときに考えていることは常にいかに短くかけるか、ということといかにバグを生み出さないかということです。

基本的にはできるだけ、短くシンプルに書くようにしています。

そうすることであとで読んだ人間にとってわかりやすく、バグも少なくなります。

といってもプログラムって基本バグがあるものなんですけどね・・・そのために大切なのはできるだけコードを書かない工夫をすることです。

人間が書く以上、かけばかくほどバグの可能性は高くなります。そのためにはまずコードをできるだけかかない、という心構えが大切になってきます。

そのための工夫として下記のようなことが大切になります。

ライブラリを使う

配列の処理などいわゆるユーティリティー系の処理に属するものはなるべく用意されているものを使いましょう。JavaならApache commonsやPerlだったらCPANのライブラリを使うなど自分で作るよりはすでに実績あるものを使うほうが安全です。

再利用可能なコードは別にまとめる

何回も繰り返していますが、重複した処理をいろいろなところにかかないことが大切です。なるべく1か所でまとめるようにしましょう。

MySQL,Unixコマンドなど他のことでできないかを考える

例えば値のグルーピングならプログラムよりもデータベースが、テキストの処理ならUnixコマンドのほうが楽かもしれません。できるだけ得な仕事は得意なものにまかせましょう。

ちなみに下記リンクはこのような考え方をもっと広範囲にわたっていろいろと書いており、参考になります。一度リンクを貼りましたが、リスペクトの意味もこめてもう一度はります。

プログラミング中級者に読んでほしい良いコードを書くための20箇条

-プログラミング全般
-

執筆者:


comment

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

関連記事

no image

画面の制御フローなど

複雑な帳票系アプリではよくあると思うのですが、ある入力値が複数の場所から影響を受けており、制御がなかなか難しいときなどがあります。 例として クリアボタンなどでクリアされる 他のプルダウンなどで影響を …

no image

エディタatomについて

今までのエディタですが、 gvim eclipse をメインに使ってました(PHPでは)。 エディタとか一旦なれるとなかなか変えにくいのでずっと上記のままでいこうと思ったんですが、今の現場でatomを …

no image

CIことはじめ

業務でJavaのテキスト変換ツールを作成。 プログラムよりもCIツールを使って他人の環境下で正常に稼動させるためにどうするかの調査に時間かかりましたね。 今回やりたかったことは下記の通りです。いわゆる …

no image

テスト分類について

一般的なテスト工程での分類や個人的に大事だと思うこと Contents1 全プロセス共通1.1 テストデータ作成バッチ1.2 ローカル、開発、ステージング、本番の分岐2 PT(プログラムテスト)、単体 …

no image

テストコードの考え方

一般的なプログラマにとって日々の業務で何がいやかというと、 理不尽な納期 むちゃくちゃな仕様変更 頻発するバグ・不具合 であることは異論がないでしょう。仕様変更や納期などは自分で何とかしがたい部分もあ …

アーカイブ