可読性

**デフォルトの名無しさん** · 2017/10/09(月) 12:21:58.39

ローカル変数には抽象的で短い名前をつけろ

× var foo_bar_baz_collection = FooBarBazCollection
○ var collection = FooBarBazCollection

ローカル変数に長い名前をつけるやつは
関数自体が長い可能性が高い。
長い関数を作るから、長いローカル変数名にしないと
何の変数か覚えられない

行き当たりばったりで名前を略するな。
略して良いのは、プロジェクトや業界で決まってる単語だけ

ただし変数の有効範囲が一行程度であれば略しても良い

○ values.map(v => v * v) //この行を見るだけでvがvaluesの要素であることがわかる
×
var ret = []
for(v in values) {
ret.push(v) // この行を見てもvがvaluesの要素であることがわからない
}

**デフォルトの名無しさん** · 2017/10/09(月) 12:35:50.57

うぇあ

**デフォルトの名無しさん** · 2017/10/09(月) 13:06:40.88

例に挙げた「collection」が特に抽象的でもない件

**デフォルトの名無しさん** · 2017/10/09(月) 16:40:26.04

valuesがすでに分かりにくいと思うんだよね
商品の個数なのか請求の金額なのかユーザの数なのかはっきりしようよ

retもresultなのかrestなのかretailなのかrestrictなのかはっきりしようよ

抽象的な値を扱うユーティリティ関数なら変数名なんて適当でいいけど
業務ロジック関数の一部を切り出してるならNGと言っていいでしょう

**デフォルトの名無しさん** · 2017/10/09(月) 16:53:10.14

この手の奴はそんなこと言ってもアレコレ言い訳するだけ

**デフォルトの名無しさん** · 2017/10/09(月) 17:22:36.74

やたら人に難癖つける割にダメダメっていういつものパターンですね

**デフォルトの名無しさん** · 2017/10/09(月) 17:59:54.27

どうせ「リーダブルコード読め」の一言で済むようなことしか言わないくせにいちいちスレ立てんなよ

**デフォルトの名無しさん** · 2017/10/09(月) 22:39:30.82

>>4
> valuesがすでに分かりにくいと思うんだよね
ローカル変数ならそれで十分やで？
重要なのはスコープだよ

関数の引数やオブジェクトのプロパティとか
スコープが広い場合には良くないけど、
（関数やオブジェクト名から推測できる場合を除く）

**デフォルトの名無しさん** · 2017/10/09(月) 22:44:35.37

> retもresultなのかrestなのかretailなのかrestrictなのかはっきりしようよ

res ult
res t
ret ail
res trict

頭三文字がretなのはretailだけやで？ｗ
そして

> 行き当たりばったりで名前を略するな。

って話。

**デフォルトの名無しさん** · 2017/10/10(火) 00:39:46.62

>>9
頭文字3文字をとってるの？

**デフォルトの名無しさん** · 2017/10/10(火) 00:42:54.68

それがわかんなかったからさ
なんかの単語を省略してるのかなって思ったの
だからはっきりさせるために省略するのやめたがいんじゃないかなって思いました

ローカル変数で十分かどうかは関数によるかなと
明細をまとめてヘッダを作りますってとき
オブジェクトが複数存在することになるから明示したほうがいんじゃないかな
一方で単に値を変換するだけの関数ならそういう配慮いらないよね
だから関数次第かなと思いました

**デフォルトの名無しさん** · 2017/10/10(火) 00:48:34.60

ドメインオブジェクトならvaluesじゃなくてちゃんと名前を付けたがいいかな
値オブジェクトならvaluesでいいかな
関数がどういう位置づけなのかで変わってくるかなと思いましたよ私は
フリーザならそう言うと思うからフリーザの立場になって考えたほうがいいと思う

**デフォルトの名無しさん** · 2017/10/10(火) 01:01:14.06

>>11
関数次第だと言うが、そもそも長い関数が悪なので
それを排除すると短い関数しか残らない

**デフォルトの名無しさん** · 2017/10/10(火) 06:25:38.70

>>13
長い関数を短い関数に置き換えても複数のオブジェクトが関わるロジックが
なくなるわけじゃないんじゃないかと
そもそも長い関数は悪なのか？僕はね正義だと思いますよ

**デフォルトの名無しさん** · 2017/10/10(火) 06:28:44.82

>>14
いいや、単純に無くしてほしい
関数内の依存関係を把握するだけで疲れる

**デフォルトの名無しさん** · 2017/10/10(火) 06:28:57.93

あっち見たりこっち見たりするより
この関数さえ見れば大丈夫なのさふふん
みたいなことが良いこともあるんじゃないかと

過度な抽象化は可読性を下げると思います！

**デフォルトの名無しさん** · 2017/10/10(火) 10:11:21.74

Fortranとかの七画面スクロール分くらいあるコード死ね
どこに何があるのか把握するだけで一苦労
まずdoループでコード膨らませ過ぎなんじゃ
全部callで画面半分くらいのコードの方がよっぽど読みやすい

**デフォルトの名無しさん** · 2017/10/10(火) 11:52:56.46

>>16
一画面に収まって、かつテストが容易であればね

**デフォルトの名無しさん** · 2017/10/10(火) 19:35:55.51

>>16
関数ごとにテスト用意するつもりか？
いつの時代の原始人だよ
モダンなデベロップメントではユースケースに基づいたモンキーテストが基本