人によって手法が違いそうなプログラミング・コーディングテクニック集

自分の観測範囲でこういうコードを見て、良いなとは思ったけど、人によっては違う解釈をしそうだ、というモノを集めてみる。

ソロエルノスキー

縦方向のインデントを揃えて書くタイプ。

Cron の書式をコメントで記す時に、こんな書き方を見て以来、縦方向に情報が揃うと分かりやすいのだな、と思うようになった。

+------------ 分   (0〜59)
| +---------- 時   (0〜23)
| | +-------- 日   (1〜31)
| | | +------ 月   (1〜12)
| | | | +---- 曜日 (0〜 6)
| | | | |
H * * * *

JavaScript の import 文なんかをこうやって揃えたりしがち。

import { HogeComponent   } from './src/hoge.component.ts';
import { FooBarComponent } from './src/foo-bar.component.ts';

SQL のインデントスタイル

SQL を書く際は4スペースで書くと可読性が良いと思う。特に AND と OR の条件文の縦位置を揃えると見やすいかと。

変数名の先頭にアンダースコア _ でローカル定数を示す？

Python の場合、メソッド名の先頭にアンダースコア2つ __ を付けることで、プライベートメソッドとして定義できる。

そうしたプログラミング言語が定める仕様ではなく、変数名の先頭にアンダースコアを付与することで、何らかの意味を示す場合があった。

JavaScript や Ruby でよく見るのは、未使用の変数の先頭にアンダースコアを付与し、「今回は未使用だが、こういう引数や戻り値がある」ということを示しておく書き方だろう。

アンコメントして使用しうるコードは、コメントアウト記号の直後にスペースを開けない

「コードをコメントアウトした」のと、「コメントとして文章を記している」のを区別するために、単一行コメント記号の直後にスペースを開けるか開けないかを意図的に変えるコードが多い。

// 開発時は以下のフラグ変数を定義することでデバッグログが出力される
//const isDebugMode = true;

# Example:
# LoadModule foo_module modules/mod_foo.so
LoadModule authn_file_module libexec/apache2/mod_authn_file.so
#LoadModule authn_dbm_module libexec/apache2/mod_authn_dbm.so

; To disable this feature set this option to empty value
;user_ini.filename =

//・#・; といった単一行コメント記号の直後にスペースが入っているところはコメント文章、スペースが入っていなければその行をそのままアンコメントしてコードとして利用できる、ということが示されている。

1行 if return でブレース {} を省略するかどうか

if(isInvalid) {
  return;
}

のように、1行で終わる if 文を

if(isInvalid) return;

このようにブレース記号を省略して書くかどうか問題。

僕は長らく「必ず省略しない派」だった。処理を増やしたくなった時に Diff が少なくなるし、処理を増やした時にブレースの記述漏れでバグが発生するリスクを減らせるからだ。

だが、最近別の考え方もするようになった。ブレースを書かずに1行で済ませた場合、「その早期 return に処理を増やされたくない意思」が示せるのでは？ということだ。この辺、読み手がどう受け取ってくれるか次第なのでなんともいえない。

空行もスペースを入れてインデントしている

僕は空行でもスペースを入れてインデントしている。世間的には少ない例で、メリットらしいメリットも少なそうだが、個人的には

という理由でスペースを入れている。