仕様をシンプルにすることの重要性
システムの仕様を決めるときはできるだけシンプルにするとメンテナンスが楽になります。
細かいところまで気にすれば気にするほど良い、というものではありません。
複雑な仕様はコード量を多くし、かつ、理解を妨げます。
コードを書く時にファイルを分けない方が良い場合
一つのファイルが大きくならないようにすることは可読性の向上に貢献しますが、逆にファイルを分けすぎると良くない場合があります。
これまでに、システムがどのように動くのかを知りたい時に、関数から関数の呼び出しごとに新しいファイ ...
コードの垂直方法の分離
コードは上から下へと読みますが、その時に処理のまとまりが直感的にわかると良いです。
例えば一つの関数の中でも、処理段階によっていくつかに分かれると思います。
そのようなまとまりを表現する際には、空行を挟むと良い ...
新聞のようにコードを書く
新聞のようにコードを書くことで秩序のある書式を保つことができるという論があります。
以下がポイントです。
クラス名や関数名をみればそのファイルが何をするコードが書かれているかがわかる(見出し)ファイルの上部に ...
コードにコメントをつけることがダメなケース 更新が追いついていない
例えば以下のようなコメントがあったとします。
//ここでのurlは、テスト環境では 本番環境では です。補足のため非常に親切なように見えますが、このような情報をコードに埋め込んでしまうと、いざurlが変わったときにコメン ...
きれいなコードはいつ書くのか
重複がなく、命名も明確でわかりやすい コードを書くことは非常に重要ですが、どのタイミングでそのコードをかけばいいのでしょうか。
できれば、はじめから書けると良いですが、まだシステム全体が把握できていない初期の段階ではこれら ...
try/catchブロックをシンプルにする
try/catchブロック内の処理は、それぞれ関数として抽出すると良いとされています。
try{// ここに細かい処理を書かかない。関数に抽出してそれを呼び出す calcPrice()}catch(e){// 上記と同様 rep ...
オブジェクトの変更と応答を同じ関数でやらないようにする
以下のような関数があるとします。
const set = (obj, property, value) => {//objにpropertyがあればvalueをセットしてtrueを返す。なければfalseを返す}この ...
関数の引数が増えそうなときは引数オブジェクを渡すことを考えてみる
関数の引数がどうしても3つや4つになる場合は、ひとつのオブジェクトして渡すことを考えてみます。
const myFunc = (hoge, foo, bar) => {//do something}const data = ...
関数の引数が2つ以上だと起きる可能性があるバグ
関数の引数が2つ以上だと順序を気にしないといけない、というデメリットがあります。
以下の関数は name と file という二つの引数をとります。
const getHtml = (name, file) => ...