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

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

リーダブルコードとは

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

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

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

[2 デフォルトの名無しさん 2013/10/11(金) 01:12:14.22]

コスト感も癖にテストテスト叫ぶガキはまずリーダブルなコード書けてから言えといいたい

[3 デフォルトの名無しさん 2013/10/11(金) 01:19:10.70]

最近、メインのコードから汎用的なコードを関数化していって
汎用的なコードはまあテストするが、
そうするとメインのコードが凄くシンプルになって、
それをテストするって意味あるのか？って思えてきた。

むしろテストしにくいコードをテストしなくて済むように
複雑なものを極力追いだすというか。そんな感じ。

[4 デフォルトの名無しさん 2013/10/11(金) 01:23:06.16]

テストコード自体にもリーダブルさは必要だからなぁ。
リーダブルなコードを書けない人間がテストコードを書いても
ごみの集まりにしかならない。
テストのメンテナンスが大変になるだけ。

[5 デフォルトの名無しさん 2013/10/11(金) 06:39:08.19]

>>1
汎用的なコードの羅列は読みにくい。コードはできるだけ個別的に書くべき。
ライブラリの使用も極力避けるべき。

[6 デフォルトの名無しさん 2013/10/11(金) 07:49:34.67]

>>2
リーダブルなレス頼む

[7 デフォルトの名無しさん 2013/10/11(金) 09:03:24.36]

>>5
荒らしは無視ですね。

[8 デフォルトの名無しさん 2013/10/11(金) 09:06:22.36]

テストが面倒だから、テストしやすいコードを書くと簡潔になるな。
同じテストを繰り返したくないから、DRYの原則を守るようになってたり。

[9 デフォルトの名無しさん 2013/10/11(金) 10:02:12.71]

>>7
pure Prolog は書き手が書いたことだけが真であって、
読み手との間で誤解の生じる余地がありません。
組込述語(ライブラリ)が無いのですから、個別的であり、
書き手と読み手の間の抽象能力の差から生じる不理解が
生じません。

[10 デフォルトの名無しさん 2013/10/11(金) 18:11:45.56]

このスレッドは天才チンパンジー「アイちゃん」が
言語訓練のために立てたものです。

アイと研究員とのやり取りに利用するスレッドなので、
関係者以外は書きこまないで下さい。

　　　　　　　　　　　　　　　　　　京都大学霊長類研究所

[11 デフォルトの名無しさん 2013/10/11(金) 22:46:36.79]

>>9
問題はそれがリーダブルかどうかです。

試しにライブラリも関数も使わずにMySQLに接続して
select文を発行するコードを書いてみてくれませんか？

リーダブルコードというのは
実用的でなければなりません。

[12 デフォルトの名無しさん 2013/10/12(土) 01:48:35.10]

例えばPerlでは要素が重複しないリストを返す関数はないわけ。

言語仕様だけで実装すればこんなふうになるけど、

my %count;
@array = grep( !$count{$_}++, @array ) ;

見ての通り明らかに、リーダブルではない。

List::MoreUtilsという有名なライブラリには
これをやってくれる関数がある

@array = uniq @array;

こっちの方が明らかにリーダブル。

実際の開発において、ライブラリを使わずに実装するなんてことは
腐った現場以外ありえない話なので、
リーダブルが目的の現実的な開発ではList::MoreUtilsのuniqを
使うという選択が一番正解なわけだよ。

[13 デフォルトの名無しさん 2013/10/12(土) 06:07:07.54]

>>11
pure Prologではなく普通のPrologですが、
http://nojiriko.asia/prolog/fukakusa_no_shoushou_1_1.html
のようなコードを念頭に置いています。
あなたが意識されているのは読みやすさではなく実用性ではありませんか。
さすがにPrologからMySQLへのインターフェイスはないと思いますが、あれば、

　　mysql :: かやうに(_かやうに),

のように質問することになるのでしょう。

[14 デフォルトの名無しさん 2013/10/12(土) 12:17:28.70]

>>13
だから実用性を考えないリーダブルに意味は無いんだって。
読んだってたかが知れてる量だとリーダブルにする意味は無いだろ。

何百、何千行にもなるような実用レベルのコードを
読みやすく構築するのがリーダブルの目標

実用レベルではMySQLを使うのは当たり前の話で
それをライブラリを使わないで書いてもリーダブルといったのはお前じゃんか。

こちとら何百、何千行もあるコードを数行に収めることを目標にしてるんだ。
だから当然ライブラリを使うし、ライブラリを作る他ないだろ。

リーダブルはあくまで実用性を念頭に置いて考えなさい。
サンプル程度の短いコードの話なんて要らないのよ。

[15 デフォルトの名無しさん 2013/10/12(土) 20:21:50.30]

>>13
横レスする

もしもそのリンク先コードがリーダブルであると主張するならば、
同サイトのPrologで書かれたクイックソートのコード：
　　http://nojiriko.asia/prolog/quick_sort.html
よりも、以下のコードのほうがリーダブルであることを認めねばならない

　　クイックソート [] = []
　　クイックソート (中心軸:残りのリスト) =
　　　　　　クイックソート
　　　　　　　　中心軸未満の部分リスト ++ 中心軸:(クイックソート 中心軸以上の部分リスト)
　　　　ここで
　　　　　　(中心軸未満の部分リスト, 中心軸以上の部分リスト) = リストを分割 (< 中心軸) 残りのリスト

　　リストを分割 関数_f = foldr 関数_g ([], [])
　　　　ここで
　　　　　　関数_g X (部分リスト_Y, 部分リスト_Z) =
　　　　　　　　もし 関数_F x ならば
　　　　　　　　　　(X:部分リスト_Y, 部分リスト_Z)
　　　　　　　　さもなくば
　　　　　　　　　　(部分リスト_Y, X:部分リスト_Z)

なお、ここでは以下を仮定した(関数型言語Haskellを元にする)架空の言語を想定している
・識別子として日本語文字(UTF-8等)が利用できる
・予約語「where」の代わりに「ここで」が利用できる
・構文「if ... then ... else ....」の代わりに「もし .... ならば .... さもなくば ....」が利用できる

[16 デフォルトの名無しさん 2013/10/12(土) 23:03:49.36]

クイックソートのコードがリーダブルかなんてどうでもよくね？

qsort()

これが一番リーダブルだ。

そう難しいロジックは関数に隠蔽してしまう。

[17 デフォルトの名無しさん 2013/10/13(日) 00:05:54.29]

>>16
関数抽象を言い出せば、あらゆるプログラムなんて、

program()

これが一番リーダブルだ、ってことになる

つまり>>16は、何も言明していないに等しい

[18 デフォルトの名無しさん 2013/10/13(日) 01:12:47.51]

なんのプログラムかわからんだろ
頭悪すぎ

[19 デフォルトの名無しさん 2013/10/13(日) 01:29:36.94]

まったくだｗ

もし>>17みたいなのがあったら、それは一つの関数で
何でもやってるリーダブルではないコードになってるだろうな。

リーダブルってのはバランス感覚が重要。
何を関数にして、何を関数にしないか。その見極めが重要。

優れた技術者は関数を汎用的なものにして
一度作ればメンテナンスを不要なレベルにする。
アプリのライフサイクルにおいて、修正が必要な箇所を極力減らす。
それがリーダブルなコードになる。

ソート関数なんてアプリの機能が変わったとしても、
一度作ればメンテナンする必要は殆ど無い。
だから関数にする。これがバランス感覚というもの。

>>17みたいなのは、結局program()の中をメンテナンスする
必要があるわけでなにも解決していない。

[20 デフォルトの名無しさん 2013/10/13(日) 01:46:35.37]

それが真実とすると、整数のソート関数を作った後、文字列のソートをしたくなる。
そんな時、テンプレートが使えると理想的。
結果、C++のような変態言語が実は理想なのか？ってなってしまう。

[21 デフォルトの名無しさん 2013/10/13(日) 01:57:31.48]

>>20
うん、各型ににおいて最速のコードを
生成するならC++が理想的だよ？

別にそこまでパフォーマンスが必要ないなら、
比較関数さえ入れ替え可能にしておけば
どんな型にでも対応できるけど。

[22 デフォルトの名無しさん 2013/10/13(日) 02:00:22.08]

void*はリーダブルコードなのか？とか新たな疑問がわいてくる。

[23 デフォルトの名無しさん 2013/10/13(日) 02:03:46.58]

void*でリーダブルかどうかなんて分かるわけがないだろ。
そもそも型であり、コードでないのだから
リーダブル”コード”の範疇外だ。

[24 デフォルトの名無しさん 2013/10/13(日) 02:05:36.89]

そういうレベルまで下りてくると、関数名を適切に付けましょうとか
その程度の話になってくる。

[25 デフォルトの名無しさん 2013/10/13(日) 02:06:59.70]

ちなみに俺はfunction_10000()まであと少しだが、十分リーダブル。

[26 デフォルトの名無しさん 2013/10/13(日) 02:13:43.33]

>>24
重要な事なんだがねぇ。

関数の名前、関数の引数。関数の使い方。
これらがリーダブルコードの大きなカギ。

いかにメンテナンスが必要なコードを
シンプルにかつ柔軟にかけるようにするかを
提供するライブラリの構築は極めて重要な作業。

[27 デフォルトの名無しさん 2013/10/13(日) 02:17:20.26]

コメントを適切につけましょう。
関数名を適切につけましょう。
当たり前の事をきちんとやりましょう。

以上でスレ終わり。

[28 デフォルトの名無しさん 2013/10/13(日) 02:18:16.83]

そういう勘所わかんねえガキがすぐ喚き立てるからな。はてなダイアリーwとかツイッターwでな。滅びろガキ共

[29 デフォルトの名無しさん 2013/10/13(日) 02:18:48.07]

>>28は>>26への共感

[30 デフォルトの名無しさん 2013/10/13(日) 02:18:53.68]

まず、コードってのは二種類に分かれる。

アプリの仕様の変化によって
メンテナンスが必要なコードと
そうでないコード。

メンテナンスが必要でないコードの例として
フレームワークやライブラリがある。

アプリってのは何千行、何万行ものコードから
なりたっている。そのうちメンテナンスが必要なコードを
極力減らすのがリーダブルコードの重要な点。

メンテナンスが必要ないコードは汎用的であり一度覚えればよく、
中身を見る必要はないか一度だけ見れば良い。
見る必要がないコードが多ければ、コードレビューも楽になる。

見なくて良いコードを増やして、
見なくてはいけないコードを減らしていくのが
大規模アプリをリーダブルにするコツ。

[31 デフォルトの名無しさん 2013/10/13(日) 06:56:46.33]

>>28
ひとつひとつのツイートをシングルクォートで囲み最後にピリオドを
付ければ、全部 Prolog プログラム。

[32 デフォルトの名無しさん 2013/10/13(日) 06:57:20.07]

ﾋﾟｺｰﾝ！

関数に分ければ読む必要ないからリーダブル！
program()

[33 デフォルトの名無しさん 2013/10/13(日) 07:04:09.04]

ソートが必要な場合、sort()に切り分ける。
関数名をわかりやすくsortにしておく。
ここ重要。
中身は知る必要なし。
一目で何をやってるかわかるリーダブルの完成。

[34 デフォルトの名無しさん 2013/10/13(日) 10:56:43.53]

引数なし戻り値なしの関数の占める割合を見ればわかる

[35 デフォルトの名無しさん 2013/10/13(日) 12:19:10.65]

>>34
お、それに気づいたか

引数なし戻り値なしの関数が
多いものは読みにくいコードであることが多い。

[36 デフォルトの名無しさん 2013/10/13(日) 20:37:38.01]

んなもんただのgotoだからな

[37 デフォルトの名無しさん 2013/10/13(日) 20:43:52.86]

>>15
Haskell風コードの方が当然リーダブルのように思うが、違うのか？

[38 デフォルトの名無しさん 2013/10/14(月) 06:27:13.58]

>>36
いや、gosubだ

[39 デフォルトの名無しさん 2013/10/14(月) 09:03:38.99]

インスタンス変数を直接触る関数は自分で書いてて分かりづらいなって思ったからやめた

[40 デフォルトの名無しさん 2013/10/15(火) 12:33:52.56]

思ったよりおもしろい

[41 デフォルトの名無しさん 2013/10/15(火) 23:12:00.01]

関数にすると処理があちこちに飛んで見難くなる。
だから関数を使うな。

というとんでもない意見があるが、
100%間違っているというわけでもない。


それは関数＝サブルーチンになっている場合。
コードが長いからという理由だけでその一部分を関数
（という名のサブルーチン）にした所でコードは読みやすくはならない。
なぜなら、関数の中まで読まないと何をやっているかわからないから。

ではなくて、関数というのは中を読まなくてもわかるようにするべき。
標準ライブラリの関数とか通常の開発で中を読むことはまずない。

中を読まなくていいということは、その分読む量が減るということ。
サブルーチンにした場合、その中を読まなくていいということはまずないので、
結局、あちこちに飛んで見難くなるだけ。
正しい関数の作り方を知らないからこうなる。

[42 デフォルトの名無しさん 2013/10/15(火) 23:52:26.09]

1箇所からしか呼ばれないものは関数化しない、という方針は、そんなに間違ってもいないが、
絶対でもないぞ。

極端な話、初見では少々読みづらいコードになったとしても、上位レイヤと下位レイヤに
分けて実装しないと、あとあと全体の構造がメンテ不能になったりすることもある。

[43 デフォルトの名無しさん 2013/10/16(水) 00:03:18.00]

>>42
レイヤ分けも「中を読まなくていいようにする」行為の一つだよ。

正しいレイヤ分けをしていれば、引数と戻り値のみがわかっていれば
そのレイヤで何を行うのかわかってるので、中のコードを読む必要がなくなる。

関数にするときは、中を読まなくていいように
なっているかどうかを意識しよう。

中を読まないといけない状態では
リーダブルにはならないことが多い。

[44 デフォルトの名無しさん 2013/10/16(水) 00:06:21.74]

標準ライブラリ関数のソースは読まないけど、ドキュメントは読まないと使えないよね
>>41のいう"正しい関数の作り方"をすれば、それすらも必要ないの？
それとも、コメント書いとけっていうことを、わざわざ長文にして書いたの？

[45 デフォルトの名無しさん 2013/10/16(水) 00:14:56.17]

>>44
ドキュメント≒コメントな。

同じようにコメントがあったとしても、
コードを毎回のように読まなくてはいけないものと
コードを（初回レビュー以外）読まなくても大丈夫なもの
二通り有るだろ？


コードを読まなくても大丈夫なものは、
標準ライブラリの関数などのように、
それ自体の役目が小さくサブルーチン（処理のまとまり）ではなく
しっかりと関数になっているもの。

サブルーチン（処理のまとまり）なんかだとコメントが有ったとしても
結局コードを読まないと、具体的なことは何もわからない。

どんな時だって、コメントがあれば問題解決するわけじゃないんだよ。

関数の中を毎度毎度読んでるようなら、
それは関数ではなくサブルーチンになっているということさ。
そういうのを減らせと言ってる。

[46 デフォルトの名無しさん 2013/10/16(水) 00:31:54.47]

>>45
>コードを毎回のように読まなくてはいけないものと
>コードを（初回レビュー以外）読まなくても大丈夫なもの
>二通り有るだろ？
コメントでカバーできないような関数にはするなっていうこと？

[47 デフォルトの名無しさん 2013/10/16(水) 00:42:34.63]

>>46
読まないといけないコードを減らして
読まなくても良いコードに置き換えろということ。

読まなくても良いコードの割合が増えれば
それだけコードレビューの時間も減る。


コメントでカバーとかそういう発想をそもそもしていない。
コメントがなくてもコードでわかるのであれば、コメントすら不要。
コメントを書きたくなる時点で、コードがリーダブルでないという証拠でしかない。

[48 デフォルトの名無しさん 2013/10/16(水) 01:35:36.55]

つまりは　なでしこで書かれたプログラムが
一番リーダブルなんじゃね？

[49 デフォルトの名無しさん 2013/10/16(水) 01:40:12.87]

噛み合ってないスレ

[50 デフォルトの名無しさん 2013/10/16(水) 02:44:30.45]

関数名と言うのは、巧いコードだと処理の概要を物語るコメントとしても機能する。
例えば void BubbleSort( int *p, int n ) という関数が何をするのかは容易に推測できる。
(ただしこんな名前でクィックソートしてるなら糞コードだが。)

一方、下手なコードだと関数名は単なる識別子としてしか機能しない。
内部で何をやっているかは関数内のコードやコメント、ドキュメントを追う必要がある。
例えば　void HogeMoge() という関数が何をするのかは中身を見なければまず分からない。

と書いてみる。

[51 デフォルトの名無しさん 2013/10/16(水) 06:06:16.25]

他人のコードを読む難しさは、”作者が暗黙にイメージしてる図”を推論することの難しさにある。
f(x+d) - f(x) / d
作者自身は「これは微分するためだ」という暗黙のイメージがあるので簡単に理解できる。
一方、他人はコードのみから「これは微分が目的か？」と推論する必要がある。
コードを推論だけで読むには、作者と同等かそれ以上のコードを書けるだけの基礎が必要となる。

これら推論を補助するには、ホワイトボードによる図説が有効である。
イメージ図が有ると無いとではコード理解の難易度が大幅に変わる。

[52 デフォルトの名無しさん 2013/10/16(水) 06:55:59.31]

>>51
それこそ、 >>26 が言っている関数名の付け方の問題で、
関数名を xxxを微分する() にすれば良い。微分という
概念なら共有できるのだとすれば。
問題はこのように概念化、言語化できない(し難い)アルゴリズムの
場合、関数名では解決できないケースがあること。

[53 52 2013/10/16(水) 07:00:14.97]

・・・
問題は、アルゴリズムと呼ばれているものの中には、
このような概念化、言語化できない(し難い)ものが
あり、この場合は関数名では解決できない。・・ですね。

[54 デフォルトの名無しさん 2013/10/16(水) 07:02:42.74]

「微分ってなに？」って奴に対してリーダブルにするにはどうすればいいかってことが問題になるな

[55 デフォルトの名無しさん 2013/10/16(水) 07:17:57.80]

ある位置の傾き

[56 デフォルトの名無しさん 2013/10/16(水) 08:07:51.68]

>>54
それはそれで「こういう処理を微分と呼びます」でいいんじゃないの
例え新たな用語であろうと、それに対しての厳密かつ具体的な処理が示されて「こういう処理をそう呼ぶんだな」と思えないなら
プログラマとしては、数学以外の分野でもかなり困ることになるぞ

[57 デフォルトの名無しさん 2013/10/16(水) 22:34:46.64]

>>54
それは勉強すればいいことなので微分のままでいいよ。
リーダブルというのは知識不足を補うためにあるんじゃない。

会社特有の知識とか、会社やめたら無駄になるようなものは
覚える必要はまずないから、それに関するドキュメントが必要。

でも世間一般の知識は、勉強しろの一言で終わり。
それが技術力ってものだからね。

技術者である以上、自分には技術がないのでわかりません。は恥だと思え。
俺にはわからんから高度な書き方をするな。みたいなことを言ってる奴は
技術力ねぇんだなと思えばいい。自分より技術の低いやつに合わせる必要ない。
足を引っ張ってる奴が悪い。

[58 デフォルトの名無しさん 2013/10/17(木) 00:18:54.98]

道具が使えるだけの奴は三流。
技術・知識も使いこなせて二流。
人も使いこなせてこそ一流。

[59 デフォルトの名無しさん 2013/10/17(木) 00:39:04.12]

ここまでオライリーの「リーダブルコード」への言及なし。

この本のいいとこ悪いとこの話題とか、
もっと深い議論があるスレを期待した俺がバカ。

[60 デフォルトの名無しさん 2013/10/17(木) 00:42:53.68]

>>59
お前がすればいいじゃん。
他人任せなのはやめろ。
自分から行動しろ。

[61 デフォルトの名無しさん 2013/10/17(木) 08:09:07.43]

>>57
それでは足を引っ張られる一方だろ。
自分が楽をするためには
どんな馬鹿にでも判るようなやり方を使って
どんな馬鹿をも楽に使えるような環境を整えるしかない。

[62 デフォルトの名無しさん 2013/10/18(金) 01:17:22.17]

>>61
馬鹿は切り捨てるか育てるしかない。
技術者は技術があるもののことだ。
素人を基準にしてどうする？

自分が楽をしたいんだろう？
馬鹿用のやり方で楽になるわけがないだろう。

[63 デフォルトの名無しさん 2013/10/18(金) 07:22:05.29]

>>62
人事権があるならやってる。

[64 デフォルトの名無しさん 2013/10/19(土) 10:53:36.95]

じゃあ、それは人事権がないのが問題ということで。

[65 デフォルトの名無しさん 2013/10/21(月) 18:36:53.86]

リーダブル関係ねえ

[66 デフォルトの名無しさん 2013/10/21(月) 22:02:52.00]

そうそう、リーダブルというのは
プロがプロのために読みやすいコードとはという話であって、
馬鹿でもわかるコードのことではない。

関数さえ理解できない馬鹿がいるんだしな。
だからそいうヤツのことを考えるのは
リーダブルとは無関係。

”リーダブルではないが”馬鹿用に仕方なく書いている。
という状態になるだけ。

[67 デフォルトの名無しさん 2013/10/21(月) 23:11:47.66]

馬鹿なんて言葉が出てくる時点でどうかと思うけどね。

[68 デフォルトの名無しさん 2013/10/21(月) 23:13:25.52]

馬鹿は切って捨てろというのは同意したいところだが、あまり理想が高すぎると誰もついて来なくなる。
そもそも原著からして「シンプルで実践的」を掲げてるわけで。

[69 デフォルトの名無しさん 2013/10/21(月) 23:25:30.25]

>>68
> 「シンプルで実践的」
って、馬鹿^H^Hプログラミング初心者に迎合しろって意味ではないだろ

[70 68 2013/10/21(月) 23:27:32.33]

思うにコードを読むのにごく一部の天才しか知らない・理解できないような知識を要したり、
ごく一部の馬鹿の為に特別なルールが設けられているなどの背景についての理解を要するのは
どちらもリーダブルではない罠。

一般的なPGの大多数が、予備知識を一切持たずにすんなり読めるコードこそリーダブルと言うべきではなかろうか。

[71 デフォルトの名無しさん 2013/10/22(火) 00:26:07.90]

> 思うにコードを読むのにごく一部の天才しか知らない・理解できないような知識を要したり

なんでそんなのを使うと思うんだ？

プログラミング言語が備えている機能を
普通に使ってるだけだぞ？

えとさ、例えばプロの技術者が、自分の使っている道具を
使いこなせてないとしたらどう思うよ？

[72 デフォルトの名無しさん 2013/10/22(火) 00:27:18.97]

> 予備知識を一切持たずにすんなり読めるコード
そんなものはない。

技術職なんだから技術がない人間が
読めるわけ無いだろ。

反対に言えば、技術職なんだから
素人が出来ないことをできるようになれよ。

[73 デフォルトの名無しさん 2013/10/22(火) 00:35:47.94]

「PGの大多数が」を省いて我田引水おいしいです

[74 デフォルトの名無しさん 2013/10/22(火) 00:42:08.45]

お前が言うPGの大多数って馬鹿のことだろう？
具体的に言えば、入社一年未満レベル。
違うのか？

本物のプログラマが普通に読めるレベルなら
プログラミング言語の機能はどれを使っても
読めるはずだが。

[75 デフォルトの名無しさん 2013/10/22(火) 00:50:13.69]

>71-72

最後に「一般的なPGの大多数が」と書いてるのに、何故そんな解釈するのさ。
言語が備えている機能を普通に使っているコードが読めないレベルが一般的で大多数だとでも?
だとしたら他を見下しすぎ。

あと「予備知識を持たずに」とは書いたけど、「勉強せずに」とは書いてないからね?
例えば余程難解な代物でも無い限り(この条件を見落とさな用に!)、コメントに「〜参照」とでも書いておくだけでも
予備知識を持たずに読めるコードになるでしょ。

[76 デフォルトの名無しさん 2013/10/22(火) 00:54:16.90]

>74
>本物のプログラマが普通に読めるレベルなら
>プログラミング言語の機能はどれを使っても
>読めるはずだが。

アセンブラでフルスクラッチできるレベルなんでしょうなぁ。
トグルスィッチでミスせず入力しきった真のPGも居ますが。

[77 デフォルトの名無しさん 2013/10/22(火) 00:54:37.35]

一般的なPGの大多数がどの程度のものを指しているのかしらないけど、
例えば、プロジェクトがオープンソースプロジェクトで
多くの人が参加しているとしよう。

その予備知識を一切持たずにすんなり読めるコードに
書き換えましょうと提案して通るレベルならいいよ。
まあ少数の初心者のために書きなおすことはないだろうね。

[78 デフォルトの名無しさん 2013/10/22(火) 00:56:14.61]

>>74
PGの大多数が入社一年未満レベル？
なに言ってんの？

[79 デフォルトの名無しさん 2013/10/22(火) 00:58:27.98]

ユニバーサルデザインの考え方だな。
より一般的な、説明が不要な方法で実装したほうが、
結局はみんなが幸せよ。

例えば売掛買掛とかいう概念にしがみついてんのは、
自分の立場を守ろうとする老害よ。
専門性に逃げ込むような輩は先細っていくよ。

[80 デフォルトの名無しさん 2013/10/22(火) 01:01:20.34]

おいおい、みんな結局同じことを言ってるぞ。

リーダブルコードというのは、
初心者プログラマでも読めるレベルで書くことじゃない。
プロがプロとして読みやすいコードを書くということだ。

言語の機能には時として使わないほうがいいとされる機能もあるが、
そういうものないのなら、すべて使って良い機能だ。

言語の機能を知らないのは、初心者が頑張って技術をつけろという話であって
初心者のレベルに下げようということではない。

だろ？

[81 デフォルトの名無しさん 2013/10/22(火) 01:02:49.59]

>>79
> より一般的な、説明が不要な方法で実装したほうが、

より一般的な、説明が不要な方法ってなんだよ？
俺らは技術者だぜ。

技術的な方法で実装するのは問題ない。
わからないのは技術が低いからなだけだろう？