投稿 2022年10月9日
更新 2022年10月9日
専門用語の数:多
コーディングって、難しいですよね・・・
人によって感じ方が異なるので、正解がないというのが難しいです。
コーディング規約がガチガチに決まっている場合、
慣れないと書きにくいですが、慣れてしまえば楽になると思います。
正直コーディング規約が決まっていないことも、結構あるかと思います。
個人開発・新規開発・規約がないプロジェクト等々・・・。
正解がない、というのが難しい点です。
そういう時、自分なりに意識していることをまとめました。
これからの内容は、あくまで私個人の意見・主観です。
参考程度にしていただくレベルで、鵜呑みにはしないでください。
何度も言いますが、正解はありません。
自分なりにアレンジしてください。
調べたらすぐ出てくると思うので、簡単に紹介します。
コードを見た時のわかりやすさ、理解のしやすさです。
変数名を省略したり、無理に1行にまとめたりすることで、
コードを書いた本人でなければ、非常に理解に時間がかかってしまいます。
※しかも、だいたい本人でもそのうち忘れて、なにこれってなります。
可読性と似たようなものですが、維持・管理のしやすさです。
可読性が高くなればなるほど、必然的に保守もしやすくなります。
コードを細分化（分割）することで、変更点の抽出・変更のしやすくなります。
また問題発生時の問題か所の特定・修正がやりやすくなります。
ただし、細分化しすぎは逆に保守しにくくなるため、要注意です。
1度書いて終わりではなく、その後更なる開発や運用があるため、
できる限り楽したいですよね。
統一感があるかどうかです。
変数名やメソッド名なども、人によってつけ方は多種多様です。
できる限り同じような名前を付けてあげるほうが、見やすいです。
細かい話ですが、決まった場所に空白があるかないか、改行があるかないか
それだけでも変わってきます。
処理速度です。
言語にもよりますが、書き方だけで処理速度が異なります。
ある1行の処理の位置を変えるだけで、処理速度が変わったりしますからね。
ですが、よっぽど処理速度が必要な個所以外は、
基本的には可読性などを優先したほうがいいと思います。
英語の文法的を意識して名前を付けます。
品詞が変にならないように気を付けています。
翻訳したり検索すると、何パターンか候補は出てくると思いますが、
できる限り誰でも知っていそうな単語を選ぶようにしています。
ちゃんと使い方のあった単語を使う方がいいのは確かなのですが、
実際、英語苦手な方が多いイメージです。（私も含み）
結局のところ勉強しろというのが正しいですが、
仕事などでは即効性がないので、もう英語自体を簡単にしてます。
プログラムの勉強段階とかなら、一緒に英語も勉強したほうがいいと思いますね。
あくまで個人の好みです。
細かくは意味違うのでしょうが、「上昇」を翻訳して出てきた単語です。
ascent
rising
個人的には「rising」のほうがとっつきやすいです。
変数などの名前の付け方は、言語やプロジェクトによって様々です。
キャメルケースやスネークケースが有名ですが、
自分好みの規則で書くのではなく、すでに決まっている規則、または周りの処理に合わせて書くようにしています。
もし、自分の書き方の方がいいと主張するのであれば、
プロジェクト全体を巻き込んで全てを変える覚悟で変えてください。
自分だけ変えることだけは絶対ないように・・・。
変数名が長くなりすぎて略したいことはよくあります。
自分で書いているとわかるのは当たり前ですが、他の人が見たら案外わからないものです。
エンジニアであれば見たことある略し方、有名な略し方以外では略さないようにしています。
変数名が長くなってしまうのは、あまりよろしくはないですが、
略してしまって余計わからなくなるよりはマシだと思っています。
数値や文字列を定数化しない場合、コメントで説明をしないといけないですし、
値が変わったときに変更が大変です。
それより定数で変数名をつけてあげれば、
コメントを書かずとも説明ができるようになり、管理も楽です。
コードを日本語訳しただけの、見たらすぐわかるコメントは書かないようにします。
第三者が分かりにくそうな部分をコメント化します。
あまりにもコメントが長くなったり、それほど難しい処理になっている場合、
処理自体を見直したほうがいいかと思います。
処理の流れを見た前提ではなく、できる限りその場だけでわかるコメントにします。
細かいコメントならいいですが、特にメソッドのコメントは、シンプルで伝わりやすく。
「この」「それ」などのあいまいな表現も避けるようにしています。
// ユーザがクリックしたページによって、そのページ内で表示する記事を変更します。
// リクエストパラメタから指定ページを取得し、表示する記事一覧を返します。
一つのメソッドの処理はシンプルにすると、わかりやすく修正もしやすいです。
一つのメソッドに一つの役割であるのがベストです。
JavaDocやPHPDocなど、クラスやメソッドの直前に、/**と*/で囲まれたコメントを記載します。
Docには説明（処理内容や役割等）を記載していきます。
Docにタグという機能があり、作成者や参照リンク・引数や戻り値などを記載できます。
比較するときに小さいものを左側、大きいものを右側に配置します。
そうするとどっちが大きいか左側の変数だけ見てわかります。
ややこしい条件式になるなら、見直したほうがいいのは確かです。
でもどうしてもややこしい条件式を書く場面が出てきてしまいます。
そういう時は「かつ」「または」の前で改行を入れるとある程度は見やすくなります。
各条件の最初のインデントが揃うと追いやすくなります。
イエスマンになれというわけではないです。
ifの条件に「!」をつけると反転(否定)しますが、elseをつけてしまうと否定の否定みたいになってしまい、わかりにくいです。
ifはイエス、elseはノーで統一した方が見やすいです。
あと、条件式で反転させるより、メソッド名や変数名で反転させる方がわかりやすいです。
すでに動いていることの実績があるなら、コピペすべきだと言うのは確かではあります。
しかしそのコピペ元をしっかり理解せず使ってしまい、本当は少し想定と違う動作をしてしまうロジックでも気づかないことが多いです。
動いているからという「先入観」が、とても邪魔をします。
サンプルコードとかをコピペする時も、責任を持って理解した上でコピペしましょう。
条件外のパターンを最初の方で終了させておけば、ネストが深くなりすぎません。
メソッドの引数と同じ名前のローカル変数を定義するとややこしいです。
Javaでは、そもそもコンパイルエラーになりますが、PHPなどの言語では可能です。
また、引数自体に代入すると、呼び出し元でも変わっているかが分かりにくいです。
参照渡しか値渡しかで変わります。
if文を1行で書く手法で{}を省略したり、
無理やり1行にねじ込んだり、
書き方はたくさんあります。
ただ省略したり、1行で書いたりしないで、どの処理でも同じかきかたで書きましょう。
私なりのコーディング規約でした。
人によっていろいろ書き方ありますが、みんなが見やすいコードを書くのは、エンジニアの永遠の課題ですよね。
以上、ここまで見ていただきありがとうございます。
皆さまの快適な開発ライフに、ほんの少しでもお役に立てれば幸いです。
コメント一覧