読みやすいコーディングをしよう
スポンサーリンク
日々コーディングをしていて思うところや、実際に抽出しました。
読みやすいコーディングのいろはをあげると
・コメントが書き込まれている
・処理がシンプルである
・汎用性が高い
コーディングとか関係ある？ と思うかも知れませんが順を追って説明していきます。
コメントが書き込まれている
コメントが無いコードは魔境です。
書き手しか分からない処理と名称で包まれています。
よくプロはコメントを書かないと言いますが実体は少し違います。
コメントを書かなくても問題ない程、処理や命名規則がプロジェクト全体で共有されている状況
そんな環境のプロならコメントは不要です。
ですがその様なケースは超レアケースです。
人の入れ替わりも激しいし、使用やスケジュールもコロコロ変わります。
その様な環境にいるプロだからこそ、一目見ればすぐに理解できるソースコードを書くべきです。
コメントがしっかりと書き込まれているかでソースコードの見易さは全然違います。
その処理の意図、流れ、結果、不整合時の対応などを一つ一つ丁寧にコメントしましょう。
もし未来の自分がもう一度見たときに、「何て分かりやすいソースコードだ！」と唸るレベルのものを作りたいですよね！。
そのためにもコメントは大事です。
処理をシンプルにする。
これはコーディングよりアルゴリズムのはなしじゃ・・？
と思うかも知れませんがこれも関係しています。
よくスパゲティコードの話題が出ます。
スパゲティの様に処理が入り組んでいて、地獄絵図なソースコードの事を指します。
何故そうなるのかというといくつか理由があります。
・使用変更などでツギハギだらけになった
・未設計のまま、感覚でコーディングした
ツギハギだらけになってしまう原因はスケジュールの問題が大きいです。
納期が短く、使用がコロコロ変わると保守点検や設計が間に合わず、とりあえず動けばいい状態になってしまいます。
こうなると綺麗なソースを書く というのは後回しになり、何よりもスピード重視 になっていきます。
こうなるともうどうにもなりません。
感覚コーディングは初心者がやってしまいがちです。
経験も浅く、チームコーディング初心者の場合、自分の処理を他人が使う という考えは殆どありません。
そのため、自己流のやり方でコーディングを開始してしまい、その場凌ぎでソースを組み立てます。
経験がある人は、ここら辺は後で変わりそうだなー と思うと、その部分はいつでも変更可能な設計をしてコーディングします。
設計といっても一つ一つの変数などを細かく定義するら必要はありません。
まずは大まかに全体像を把握して、範囲を狭めながらコーディングプロセスを組み立てていきます。
設計がしっかりしているとある程度のスパゲティ化は防げます。
そして本題の処理をシンプルにです。
シンプルにすらメリットは
・仕様変更に強い
・コメントが書きやすい
・処理の意味をしっかりと理解できる。
上2つは先程説明した通りです。
最後の部分は、理解できる というより、理解している とも言えます。
書き手側の理解力というのは、そっくりそのままコーディングに現れます。
汎用性が高い
汎用性の高さは使い回し安さを意味します。
誰かに使ってもらいたい。 または、誰かが使う
という意識で作ると、自然と機能の複雑化を抑制し、ソースコードは見やすくなっていきます。
不特定多数の人々にレビューされる訳ですからね。
以上が読みやすいコーディングで気をつけている部分です。
コーディングで悩んでいる人の力になれたらとても嬉しく思います！
私の文章力も向上していきたいですね。。
