もう一つは「驚き最小の原則」と関係している https://en.wikipedia.org/wiki/Principle_of_least_astonishment [wikipedia.org] > In programming, a good example of this principle is the common ParseInteger(string, radix) function which exists in most languages and is used to convert a string to an integer value. The ra
70行程度の行数じゃないと耐えられないのか (スコア:2)
さすがにこれは甘えでしかない。
そんなもんで収まるのはしょーもないプログラムぐらいのもの。
Re: (スコア:1)
複雑だからこそ、一つの関数の処理が単機能に収まるように分割しないとダメです。
単体テストも書きやすいし、スタックトレース出して追いかけやすい。
長々書いてどうにかなるのはしょーもないプログラム。
# 複雑なコードはどうにもならないorz
# PHP3時代からいい感じに醸されたコード・・・うっ頭が(ry
Re: (スコア:0)
宣言的に、単機能な関数の組み合わせで書かれ、再帰を多用するプログラムは、正しく動く限りでは理解しやすい(したつもりになりやすい)が、
他人の書いたこの手のコードのバグ取りは死ぬる
他人の書いた単機能な関数に適切な名前がついていることはまれなので、関数の中身がある程度は展開されているほうが理解しやすく、
なによりコードをみてフローをなるべく簡単に理解できることが望ましい
つまりオブジェクト指向プログラミングは望ましくはない(とjane streetの連中などは言っている)
Re: (スコア:0)
コードの読みやすさは文章の読みやすさと同じで複数の要素の組み合わせ、こうであれば読み易いと一概に言えるものじゃない。敢えて挙げれば処理対象とコードの乖離が少ないものが読み易い。これを満たし更に拡張に開いたコードを見ると感動する。
再帰もそれが自然なら構わないけどぐっちゃぐちゃな再帰のバグ取りに苦労したことあるんで言ってることはわかる、特にブロック外部の状態を変えるものやin-outを兼ねた引数が多いもの。たぶん再帰以前の問題。
関数の長さはやや理解し易さに影響するけど元米の書いた「単体テストも書きやすいし、スタックトレース出して追いかけやすい」、と修正のし易さに影響するんで画面内に収まる程度にしといて欲しい。
オブジェクト指向プログラミングが読み易いかどうかは書き手次第。クラスの責務が不明確なもの、抽象化のし過ぎで処理がどう飛ぶのかわからないもの、この２つは読みにくいから嫌い。
Re: (スコア:0)
プログラムの読みにくさには二種類あって、一つは書いてあることが理解できないこと、もう一つは理解したことがプログラマの意図とは違うものになること
前者は古くはスパゲッティ、今なら元コメの指摘するような抽象化のし過ぎなど
もう一つは「驚き最小の原則」と関係している
https://en.wikipedia.org/wiki/Principle_of_least_astonishment [wikipedia.org]
> In programming, a good example of this principle is the common ParseInteger(string, radix) function which exists in most languages and is used to convert a string to an integer value. The ra
Re:70行程度の行数じゃないと耐えられないのか (スコア:0)
しかし本当の問題はそこにはない
CやPythonでは文字列から整数に変換する関数に基数に0を指定すると文字列をコードリテラルとして解釈する
しかし考えてみると基数が0ということは無意味だし、無意味な引数を与えることと、文字列をコードリテラルとして解釈することの間には論理的なつながりは何もない
コードリテラルとして解釈するのだから、言語間での移植性もない
基数を10や16と指定することは意味があるし、常識的な解釈があり、どの言語でもほぼ同じ結果を得ることができるだろう
この二つが同一の関数で混同して実装されているのは問題だ
常識的な解釈に従って文字列を整数に変換する関数と、言語に依存した解釈で文字列を整数に変換する関数、この二つに分けてしまえばよい
しかしこれが最大の問題ではない
最大の問題は、この混同にプログラマが誰も驚いていないことだ