リーダブルコーディング技術スレ

**デフォルトの名無しさん** · 2013/10/11(金) 01:06:21.56

リーダブルコードとは

・読みやすさ、理解しやすさを追及したコードのことです
・読みやすいということはメンテナンス性も高いということです。
・理解しやすいコードはコードレビューも楽になります。
・理解しやすいコードはバグも少なくなります。
・短いほうが優れていることが多いですが、必ずしも短いほうがいいとは限りません。

俺ルール
・書き方の勝負であり、言語の勝負をしないでください。
・標準、非標準に限らずライブラリを使いましょう。
・なければ自分で関数を作りましょう。関数はなるべく汎用的に。

こういうコードを読みやすくするにはどうすればいいでしょうか？
というようなことを語るスレ。需要ありますかね？

**デフォルトの名無しさん** · 2013/10/26(土) 16:17:35.98

int getSpamSpamSpam(){return spam;}
int getHam() {return ham;}
int getEggEggEgg() {return egg;}

int getSpamSpamSpam() {return spam;}
int getHam()　　　　　　　　{return ham;}
int getEggEggEgg() 　　　　{return egg;}

こんな感じか？

**デフォルトの名無しさん** · 2013/10/26(土) 16:25:30.69

ふつうの等幅フォントのエディタで書いてコピペしてくれた方が、
navi2chでは見やすいんだが

**デフォルトの名無しさん** · 2013/10/26(土) 21:25:49.66

名前と括弧の間にスペースを入れて整形するのは変かな？

**デフォルトの名無しさん** · 2013/10/26(土) 22:35:48.73

変

**デフォルトの名無しさん** · 2013/10/26(土) 23:00:18.20

変かどうかっていうのは、オープンソース、
それも有名で多くの人が参加しているようなものの
コードをみればいいだけ。

こういうのは考えるのではなく、調べて答えを見つけようぜ。

**デフォルトの名無しさん** · 2013/10/26(土) 23:03:48.33

変
イテレータならものによっては改行とスペース入れてそろえる

**デフォルトの名無しさん** · 2013/12/03(火) 11:00:09.00

>>182
もっと名前の長い関数を追加することになったら面倒だろ

**デフォルトの名無しさん** · 2013/12/04(水) 01:09:35.65

関数の中身を見比べる必要がある時点でおかしいだろと思った

**デフォルトの名無しさん** · 2013/12/05(木) 07:45:11.65

達人プログラマでも同じようなインデントしてたし
>>182はそこまで変ではないのでは？

**デフォルトの名無しさん** · 2013/12/06(金) 01:25:03.50

見た目云々より、エディタの矩形選択とかを活かせるメリットの方が大きい気が。

**デフォルトの名無しさん** · 2013/12/29(日) 23:04:49.03

クラスの中のある関数をつかうために
あらかじめいくつかの要素をsetしておかないといけないという設計はよくない？
setしないで関数を呼び出したときには例外を出す感じ

コンストラクタにいれてしまったほうがいいんだろうか？

**デフォルトの名無しさん** · 2013/12/29(日) 23:06:02.09

>>192
うん。
何か気に入らないの？

**デフォルトの名無しさん** · 2013/12/29(日) 23:59:47.76

>>193
コンストラクタの引数に不正な値をいれたときの処理が気になる
コンストラクタの中で例外だすのってありだっけ？
そうするとインスタンス生成してから使うところをtryで囲まないといけないし

**デフォルトの名無しさん** · 2013/12/30(月) 00:03:01.47

>>194
ありだよ。

「tryで囲まないといけない」ってのも疑わしいが、それがほんとだとしても
「setしないで関数を呼び出したときには例外を出す」ってしたときと何が違うんだ？

**デフォルトの名無しさん** · 2013/12/30(月) 00:20:47.15

try {
____a = A()
____a.set(something)
____a.do_something()
}
か
a = A()
try {
____a.set(something)
}
a.do_something()
の違いだと思ってる
コンストラクタで例外がでるとそのクラスのインスタンスを使うところ
すべてtryで囲まないといけなくない？

**デフォルトの名無しさん** · 2013/12/30(月) 00:21:24.74

a = Noen
try{
____a = A()
}
a.do_something()
にしろってこと？

**デフォルトの名無しさん** · 2013/12/30(月) 01:20:49.83

>>196-197
それでいいんじゃね？

ごく狭い範囲をtryで囲むみたいなレアケースの見た目（いずれにしても残念）を
なんでそんなに気にしてるのか知らんけど。

**デフォルトの名無しさん** · 2013/12/30(月) 02:04:19.44

FactoryMethodパターンもいいかも。

これだったら、値を解析して正しい値だったらクラスを生成して返し、
不正だったらnullか、ヌルオブジェクトパターンでダミーのオブジェクトを返してやるとか色々出来るから。

A create(int youso)
{
if(yousoが正常) return new A(youso);
else return null;
}

class A
{
int _a;
A(int youso) { _a = youso; }
}

**デフォルトの名無しさん** · 2013/12/30(月) 09:03:57.73

>>198
コンストラクタに例外がある場合の書き方がよくわからなかった

>>199
こういう方法もあるのか
参考になります

**デフォルトの名無しさん** · 2013/12/30(月) 11:04:11.99

デザパタの目的はいくつかあるだろうが、
その中で「カタログ化」だの「パターンに名前をつけて共有」だの、
さもそれこそがおいしいという論調には疑問だね。

>>199を見ろよ。何がFactoryMethodパターンだ。
ただのファクトリメソッドじゃねーか。
「インスタンス化をサブクラスに任せる」っていう点を押さえて理解できてない。

**デフォルトの名無しさん** · 2014/04/10(木) 09:43:21.89

>>191
これ

**拳聖ピストン矢口** · 2014/11/13(木) 23:50:19.89

【注目】チョー気持ちいい!
やっぱセクロスするならアイドルっしょ超有名アイドルグループ所属の美少女が衝撃のAVデビュー
アイドルは裏切らないっ！！

https://www.youtube.com/watch?v=XmP1TRsAe88

**デフォルトの名無しさん** · 2014/11/15(土) 06:53:16.50

>>190
変更コストがつらくなってこない？
読みやすさでは>>182も好きなんだけど

**デフォルトの名無しさん** · 2014/11/15(土) 14:58:16.01

>>204
変更コストって言っても
getterでかつ今までの関数名より長いときにしか起こらないし，そこまで気にしなくていいのでは？
1分もかからないっしょ

**デフォルトの名無しさん** · 2014/11/15(土) 16:17:34.44

変更コストよりも
変更したい箇所以外に、並列されてるだけで関係ない行まで修正が発生するのは気持ち悪いと感じる
1行の修正のはずなのにdiffとると何行も出たり　まあオプションで消せるけど

**デフォルトの名無しさん** · 2014/11/16(日) 07:07:37.48

それでタイポして余計なバグが増えて…
ってなったから>>182みたいに揃えるのは止めたなぁ
見栄えだけなら揃えるのが好きだけど

**デフォルトの名無しさん** · 2014/11/16(日) 08:15:35.42

見栄え→読みやすさ

**デフォルトの名無しさん** · 2014/11/16(日) 08:30:50.35

returnの位置を揃えるのとタイポは本質的には関係ないじゃね？

**デフォルトの名無しさん** · 2014/11/17(月) 10:22:10.98

alignみたいなやつで気軽にガンガン揃えられるような環境ができればいいのだろうか

**デフォルトの名無しさん** · 2014/11/19(水) 00:13:58.01

自分は次の３つを結構その時の気分で描いてしまうのですが、どれかに統一したほうがよいとか、ありますか？
こういうのに対するコーディング規約とかも、会社によってはあるんでしょうか？
（ちなみに3は否定を使わない事でif文が素直に読めるかな？という理由で条件を逆にしているだけです）

例1
hash = INVALID_HASH;
if (! data.empty()) {
　hash = ComputeHash(data);
}

例2
if (! data.empty()) {
　hash = ComputeHash(data);
} else {
　hash = INVALID_HASH;
}

例3
if (data.empty()) {
　hash = INVALID_HASH;
} else {
　hash = ComputeHash(data);
}

**デフォルトの名無しさん** · 2014/11/19(水) 00:41:55.06

>>211
hash = data.empty() ? INVALID_HASH : ComputeHash(data);

**デフォルトの名無しさん** · 2014/11/19(水) 05:42:14.41

hash = INVALID_HASH;
hash = ComputeHash(data) if (! data.empty());

**デフォルトの名無しさん** · 2014/11/19(水) 12:53:45.74

>>212
なるほど、代入が１命令で済むなら参考演算子の方が見やすいですよね。
ちなみに複数行にわたる時はどうします？

>> 213
説明不足でした、C言語を想定していました。
ちなみにこの書き方だと、同じ変数に対する代入が二つ連続しているだけのように（ぱっと見）見えませんか？
１行目の代入って無駄じゃね？　と一瞬思わせてからの２行目、みたいな。

**デフォルトの名無しさん** · 2014/11/19(水) 13:24:54.27

俺は>>212じゃないけど、

> なるほど、代入が１命令で済むなら参考演算子の方が見やすいですよね。
代入が1命令というより、代入した後は変数の値を変更しないためだな。
変数は代入文とともに宣言し、その後は変更してはならない。
関数型言語の考え方よ。

なので>>213はだめだね。値を書き換えてるから。

**デフォルトの名無しさん** · 2014/11/19(水) 13:29:08.73

>>214
> ちなみに複数行にわたる時はどうします？

三項演算子でも見やすく書ける。

場合によってはハッシュを使う。
Perlで書くけど、

my $value = {
　key1 => 'value1',
　key2 => 'value2',
　key3 => 'value3',
}->{$key} || 'other';

**デフォルトの名無しさん** · 2014/11/19(水) 20:19:45.26

>>214
>ちなみに複数行にわたる時はどうします？

hash = data.empty() ? (
　　　　INVALID_HASH
　　) : (
　　　　ComputeHash(data)
　　) ;

理屈は >>215、いわゆる参照透明性のことで、
関数型言語や Ruby のような関数型プログラミングに適した言語ならではのコード
・Rubyによる関数型プログラミング
　http://www.h6.dion.ne.jp/~machan/misc/FPwithRuby.html

なお Ruby には C と同様な条件演算子(三項演算子)もあるけど、
複数行にわたる場合には if 式を使うのが普通

hash = if data.empty()
　　　　INVALID_HASH
　　else
　　　　ComputeHash(data)
　　end

**214** · 2014/11/20(木) 00:50:43.10

最初の話しとはズレるんですが、宣言と同時に初期化し、それ以降の代入を極力避ける
というスタイルをC/C++で言い換えると、積極的に const をつける　という事になりますかね。
変数をなるべく const 宣言するというのは、キーワードconstが目印になって宣言箇所がすぐにわかるので
個人的にも好きですね。ただ関数の非ポインタ引数にconstをつけるのは煩わしく思いますが。

**デフォルトの名無しさん** · 2014/11/20(木) 00:55:42.04

それより条件式の比較演算子の省略と条件式内での関数呼び出しをやめてほしい

**デフォルトの名無しさん** · 2014/11/20(木) 11:12:42.88

>>219
それは十分シンプルで十分意味がわかるならば問題ないよ。

いるんだよね。ルールを守ることが目的になってる奴って。

× 書き方を統一しようとする
○ わかりやすいように書く

わかりやすいならば、どんな書き方だっていいんだよ。
どうせ書き方なんて些細な事なんだし。

**デフォルトの名無しさん** · 2014/11/20(木) 11:40:07.19

まあ比較演算子の省略はわかればいいんだけど
if文の条件式で関数呼ばれると単にデバッグが面倒なんだよね
これは別の問題か

**デフォルトの名無しさん** · 2014/11/20(木) 17:57:21.94

えっ

**デフォルトの名無しさん** · 2014/11/20(木) 18:25:29.28

if (func()) { }

ではなく

result = func();
if (result) { }

こういうこと？

**デフォルトの名無しさん** · 2014/11/20(木) 18:35:58.57

比較演算子を省略しないとこうか
result = func();
if (result == true) { }

真偽値だったら省略したくなるな～俺は

**デフォルトの名無しさん** · 2014/11/21(金) 10:27:03.29

そうそう
C言語って既定の真偽値型ないし

**デフォルトの名無しさん** · 2014/11/21(金) 10:53:54.88

ごめんやっぱリーダーブル関係ないね

**デフォルトの名無しさん** · 2014/11/21(金) 13:24:31.65

Cだったら
if (result == true) はダメでしょ。resultが非0かつ非1だったときに困る。
if (result != false) にしないと。
結局真偽値判定は比較演算子使わない方がいいんでない？

**デフォルトの名無しさん** · 2014/11/21(金) 13:47:31.12

真偽値を直接返す関数を作らなければいいのかな

**デフォルトの名無しさん** · 2014/11/21(金) 14:12:52.15

変数名をresultではなく、 doneやcompleteのように状態を表す言葉にすればいい。
if (done) { }

**デフォルトの名無しさん** · 2014/11/21(金) 14:14:08.05

if (expr == TRUE) とか書くのは馬鹿げている、とcomp.lang.c FAQの回答にもある。
http://c-faq.com/bool/bool2.html 単に if (expr) と書くべき。

**デフォルトの名無しさん** · 2014/11/22(土) 03:29:01.87

真偽値の場合、doneかisDoneにするかで迷う時がある。

**デフォルトの名無しさん** · 2014/11/22(土) 04:07:44.39

結局どーんすんの

**デフォルトの名無しさん** · 2014/11/22(土) 05:06:36.83

たまにいずどーんにすんの

**デフォルトの名無しさん** · 2014/11/22(土) 11:35:45.69

いやexprは関係演算子以外から導くべきではない、って話だろ

**デフォルトの名無しさん** · 2014/11/22(土) 16:46:09.25

if(variable == undefined)

**デフォルトの名無しさん** · 2014/11/22(土) 19:28:06.50

職場のスパゲティソースのメトリクス値がやばすぎるんで

今度大幅に直そうという話はあがったものの
全く手がついてないんだけど

どういうふうに課員を指導したらいいんだろう

**デフォルトの名無しさん** · 2014/11/22(土) 22:08:19.55

同値変形のやり方を練習させろよ

**デフォルトの名無しさん** · 2014/11/22(土) 22:09:52.26

それは、どうちて？

**デフォルトの名無しさん** · 2014/11/23(日) 08:18:15.22

>>220
こーいう人ってなんなん？

分かりやすいだけがルールじゃないし、
分かりやすい定義が曖昧だから、ルール作って
こーいう意識もってやりましょうってのがルールなのになんで勝手なことするの

**デフォルトの名無しさん** · 2014/11/23(日) 08:46:26.24

そういう人が言う「分かりやすいコード」って
基本的に誤解しやすいコードが多い

**デフォルトの名無しさん** · 2014/11/23(日) 08:59:26.38

>>200がプロだって前提で言うと、
>>200みたいな意見は研究所出身の人に多いね。

で、そういう人の書いたコードは、実際にモノに組み込んで
テストすると大量のバグが露見する(机上、単体テストはOKて言ってたにもかかわらず！)

**デフォルトの名無しさん** · 2014/11/23(日) 09:00:06.86

失礼、>>200ではなく>>220でした。

**デフォルトの名無しさん** · 2014/11/23(日) 09:16:30.23

>>242
それはルールを守らずに，独自のわかりやすい方法で書いたからってこと？

**デフォルトの名無しさん** · 2014/11/23(日) 09:34:54.26

一貫性の欠いたフレームワークなんて作られた日には使えたもんじゃないだろ

**デフォルトの名無しさん** · 2014/11/23(日) 11:55:45.10

独自のわかりやすいコードっていうのを見てみたいわｗ

わかりやすいコードっていうのは、独自じゃない。
多くが○○スタイルみたいな言い方で呼ばれてる。
もちろんいろんなスタイルがあって、わかりやすいスタイルというのは
一つではないが、わかりやすいという点では共通してる。

わかりやすいのに、バグがでまくるとか矛盾してるってｗ

**デフォルトの名無しさん** · 2014/11/23(日) 12:50:11.85

C言語で
#ifdef DEBUG
printf(var);
#endif
が1つの関数に頻出するコードは非常に読みにくい

今やらされてる組織内独自のフレームワークのコード

**デフォルトの名無しさん** · 2014/11/23(日) 12:59:40.43

>>246
プリプロの記法はもうちょっとなんとかならないものか？#if/#ifdef/#endif を一行で書ければいいのだが‥

**デフォルトの名無しさん** · 2014/11/23(日) 13:20:52.44

>>245
本人はわかりやすいつもりで書いてるコードが該当するんじゃね？
省略できるものは全部省略しちゃうとか。

**デフォルトの名無しさん** · 2014/11/23(日) 15:02:18.53

こうだろ
DBGP(var);

**デフォルトの名無しさん** · 2014/11/23(日) 21:25:37.37

>>248
> 本人はわかりやすいつもりで書いてるコードが該当するんじゃね？
> 省略できるものは全部省略しちゃうとか。

だからそれがどんなのかってこと。
例えば、単語を省略して書くのは
わかりにくいとされている。

**デフォルトの名無しさん** · 2014/11/23(日) 21:27:09.08

>>246
それ、明らかにわかりにくいコードだよね。

わかりやすいコードとして考えられたのではなく、
単にやっつけ仕事でifdef DEBUGを入れたのだろう。

一般的な仕組み、例えばsyslog当たりを使えば
分かりやすくなるよね。

**片山博文MZ次期CEO** ◆T6xkBnTXz7B0 · 2014/11/23(日) 21:27:34.82

#ifdef NDEBUG
#define DEBUG_ONLY(x)
#define RELEASE_ONLY(x) x
#else
#define DEBUG_ONLY(x) x
#define RELEASE_ONLY(x)
#endif

**241** · 2014/11/24(月) 00:06:43.37

な～んかID:c84onc2Pの癇に障ったみたいなので一応補足すると、
別に>>220みたいな意見を持つ人全員がバグ量産機だなんて言うつもりはないよ。

ただ、プロとして仕事する以上、コーディング規約に沿ったものでなければ
納品できない開発なんてざらにあるんだよね(有名所だとIEC61508とか)。

釈迦に説法かもしれんが、分かり易いとテストし易いは、似てるようで別物。
技術力が充分でないのに「分かり易ければOK」ていう人は往々にして
テスト漏れ仕込むってことを愚痴りたかっただけ。>>241は完全に個人的な経験からくる偏見だな。ごめんね。

**デフォルトの名無しさん** · 2014/11/24(月) 00:10:37.50

プロとか言い訳すんなやｗ

「コーディング規約に沿ったものでなければ納品できない」
というのが、理由であって

わかりやすくするためではないだろ。

クライアントが望むなら、けばけばしいデザインのサイトだって作るさ。
だがそれは、クライアントの指示でだめなことをしているのであって
それが正しいと思ってはいけない。

今ここに、クソなクライアントはいないんだぜ？

**デフォルトの名無しさん** · 2014/11/24(月) 00:14:44.32

いや、言い訳じゃなくて、契約の問題ですし。。。常識でしょ？

**デフォルトの名無しさん** · 2014/11/24(月) 00:19:33.68

スレタイ読んでね。リーダブルコーディング技術スレ。

リーダブルなコードのための話であって、

契約で～とかいうのが理由ならそれは無関係だろ。

**デフォルトの名無しさん** · 2014/11/24(月) 00:22:07.34

プロか否か、常識か否か、
これを早々に持ち出す姿勢ｗ

**デフォルトの名無しさん** · 2014/11/24(月) 00:25:05.80

>>249
そう書いてあればまだ読みやすいのにひどいコードだよ全く
あくまでメンテナンス性最悪なコードの例として出したんだけどね

>>253
横からだけど一言多いなんじゃないかな

**デフォルトの名無しさん** · 2014/11/24(月) 00:25:55.45

プロとか常識とか言い出す奴は
信用してないわｗ

だってそれ、単なる虎の威を借る狐だもの。
それに、虎ですらないかもしれないしな

俺の信じる、虎さまはこうおっしゃってる。
だから信じなさい。みたいなｗ

俺が定義するプロはこういうものなんだ。
お前はプロじゃないのか！みたいで
どっかの宗教と同じ。お前は（俺らの）神を信じないのか！

**デフォルトの名無しさん** · 2014/11/24(月) 00:27:15.22

プロとか常識とかクライアントが決めたこことか無視しようぜ

わかりやすいコードとはなにか？
これだけで考えよう。

**デフォルトの名無しさん** · 2014/11/24(月) 00:27:26.67

う～ん、何か余計に癇に障ったみたいだね。
不覚にもスレ違いな話題に誘導されちゃったから、しばらく黙ってるは。

以下↓本来のリーダブルコーディング技術スレ

**デフォルトの名無しさん** · 2014/11/24(月) 00:30:38.62

まあ、俺は最初から、わかりやすいコードの
話しかしてないんけどねｗ

○な書き方、△な書き方、どっちがわかりやすい？
の答えに、どちらでもわかりやすい。という答えがあるのは事実

だから複数のコーディング規約が存在するわけで。

書き方を（自分の好きな書き方に）統一すると、気持ちいかも知れないが
わかりやすさの点から見れば、どちらでもいいことが多い。

**デフォルトの名無しさん** · 2014/11/24(月) 00:34:18.09

>>262
>>254 >>259

**デフォルトの名無しさん** · 2014/11/24(月) 00:35:36.40

>>263
全部俺が言ったことだなｗ

**デフォルトの名無しさん** · 2014/11/24(月) 00:36:13.26

あ、まとめてくれてありがとよって
いうところかｗ

**デフォルトの名無しさん** · 2014/11/24(月) 00:50:24.64

>>246
エディタの置換コマンドで
一行に置換してしまえばいいんじゃないか？

**デフォルトの名無しさん** · 2014/11/24(月) 00:59:19.90

>>266
読むぶんには読めるけど書き換えはさせてもらえない
なのにコード読まないと処理が理解できないというコード

リーダブルと真逆なものを上げることで参考になればいいなと思って

**デフォルトの名無しさん** · 2014/11/24(月) 01:04:11.30

> 読むぶんには読めるけど書き換えはさせてもらえない
可愛そうだよね。まあ、社内規則だからｗ

で、ここはリーダブルなのかはどういうことかって話すスレだから
社内規則で変えられないとかはどうでもよくて。

じゃあリーダブルなのはどういうコードかってことで、
意見を集めましょう。

ってもうみんな書いたか？俺はsyslogって書いた。

デバッグ出力をするために再コンパイルが必要っていうのも
変な話なんだよね。そもそもオプションで指定すればいいと。
デバッグ出力機能を持っている。という所まで仕様。
で、こういう仕様を考える人、そこまで頭が回る人が、いないんだろうね。

**デフォルトの名無しさん** · 2014/11/24(月) 01:05:10.00

只のデバッグプリントなら読み飛ばせばいいだけじゃん

リーダブルの真逆てコードの意図が伝わってこないものを言うんじゃない？

**デフォルトの名無しさん** · 2014/11/24(月) 01:06:14.43

どうでもいいけど、syslogでデバッグって相当頭悪いか、ぬるい開発だな

**デフォルトの名無しさん** · 2014/11/24(月) 01:10:43.53

おいおい、syslogでやるのはデバッグプリントであって
デバッグそのものじゃないぞｗ

syslogにあるだろ。プライオリティdebugのことだよ。

http://www.atmarkit.co.jp/ait/articles/0209/07/news002_2.html
> プライオリティ（priority）
>
> priorityは、プログラムが出力するメッセージのうち、ログのレベルの重要度を設定します。
>
> priority 内容
> debug デバッグ情報
> info 情報
> notice 通知
> warn 警告
> err 一般的なエラー
> crit 致命的なエラー
> alert 緊急に対処すべきエラー
> emerg システムが落ちるような状態
> 下になるほど重要度が高い

なんでこんな基礎的を説明せにゃならんのだｗ

**デフォルトの名無しさん** · 2014/11/24(月) 01:11:55.52

既に世の中にあるものを使わずに（知らずに）
少ない知識でもやれるぜって考えで
オレオレで実装するのも、リーダブルにならない原因の一つだよね。

**デフォルトの名無しさん** · 2014/11/24(月) 06:48:20.80

なぜ、人はアンリーダブルを求めるのでしょうか？
人は生きて、死ぬだけの存在でありながら、
存在するということに意味を持たせ、生と死をより複雑なものにしようとしました。

本来、人は無駄を好む存在です。
オートメーション、自動化、リーダブルなどというものは、
将来、オートメーションにより追いやられた人々により破壊されることが目に見えているのですから、
破壊されるために効率化を豪語し、効率化に勤しむ人々がいることに、
私は含み笑いを抑えることができません。

**デフォルトの名無しさん** · 2014/11/24(月) 07:00:20.21

リーダプルは、時間的にどの程度のスパンで考えるのかな？

**デフォルトの名無しさん** · 2014/11/24(月) 07:09:48.66

読みやすさは主観であり、人により異なる。
全員に対して読みやすさを一定量担保するために、コーディング規約を作る。

デバッグプリント関係は、『CODE COMPLETE』第八章防御的プログラミングがお勧め。

**デフォルトの名無しさん** · 2014/11/24(月) 07:30:10.66

> 読みやすさは主観であり、人により異なる。

つまり、人によっては、Aという書き方が読みやすく、
別の人は、Bと言う書き方、Cと言う書き方が一番読みやすいということ

> 全員に対して読みやすさを一定量担保するために、コーディング規約を作る。

たとえば規約でBという書き方に統一する。
さて、統一することによって、Aという書き方は読みにくということになるのか？
Bという書き方は読みにくいということになるのか？

もちろん違う。なぜなら、
> 読みやすさは主観であり、人により異なる。
と書いてあるように、人によって、AやCが読みやすいということに変わりはないからだ。

つまりなりが良いたいかというと、
AでもBでもCでも読みやすいことには変わりないということ。

統一するのは、読みにくい書き方を無くすのが目的であり、
読みやすい書き方は複数あるということは真実だし、
読みやすい書き方ならどれでもいいことにかわりはないのである。

だからこそAとCは自分のに取っては一番ではないが
それでも読みやすいならばどれでもいいから、その規約に従うのである。

**デフォルトの名無しさん** · 2014/11/24(月) 07:35:54.08

>>220
＞× 書き方を統一しようとする
＞○ わかりやすいように書く

世間に受け入れられているコーディング規約に従うのが一番わかりやすいんだから
それ対立軸じゃなくて両方○になるか両方×になるかだろ

**デフォルトの名無しさん** · 2014/11/24(月) 07:42:27.18

> 世間に受け入れられているコーディング規約

が複数あることを忘れてない？

わかりやすい書き方は一つじゃないんだよ。

**デフォルトの名無しさん** · 2014/11/24(月) 07:55:36.62

＞が複数あることを忘れてない？

忘れてない

＞わかりやすい書き方は一つじゃないんだよ。

もちろん

で？

**デフォルトの名無しさん** · 2014/11/24(月) 07:55:49.98

>>271
当たり前なことをわざわざ引用付きで語んなよｗ
お前がぬるい開発しかしてないことはよく分かったから

**デフォルトの名無しさん** · 2014/11/24(月) 08:01:29.70

>>280
お前、「お前は語るな」と「俺はそう思ってる」の
2つのことしか言ってないぞ。

何か言い返せよｗ