アカウント名:
パスワード:
複雑なコードが悪いコードであるとは限らないが、悪いコードは複雑なコードである、みたいな?
単純でも悪いコードはあるだろ。
year % 4 == 0
で閏年を判定するとかさ。
普通比較するのはロジックが当たっている前提でしょ。
では、それを前提に反例を一つ示してみよう。例えば、ソートを実装するのに、
def sort(array) <<クイックソートを実装>>end
というコードがあったとしよう。<<クイックソートを実装>>の部分では、sort(array)を再帰的に呼び出す。これに対して、次のようなコードを考える。
def sort(array) if array.size < m <<バブルソートを実装>> else <<クイックソートを実装>> endend
定数mは、実行速度が最適になるよう定める。このコードでも同様に<<クイックソートを実装>>の部分では、sort(array)を再帰的に呼び出す。
この二つのコードに関して言えば、どちらも正しい。後
まさにこれは> 複雑なコードが悪いコードであるとは限らないが、悪いコードは複雑なコードである、みたいな?という例では?
複雑なコードが悪いコードであるとは限らない。の方の。
なにがやりたかったのか分からん。
そうだね。なおかつ、「悪いコードは複雑である」とは限らないことの実例にもなってるだろ?
複雑なコードは悪いコードである。と悪いコードは複雑なコードである。とでは意味が違うってわかってるのかな…。
「悪いコードは複雑である」とは限らないことの実例にもなってるだろ?
君は
複雑なコードが悪いコードであるとは限らないが、悪いコードは複雑なコードである
みたいな言い回しについて、ちゃんと理解出来てないんじゃないか?
稀にいるよねw 言い回しとか慣用句みたいなのを理解できないで、言葉通りに読もうとする奴って。
この手の言い回し、そこに込められた「行間」を常識的に補足すれば
複雑なコードが悪いコードであるとは限らないが、(俗に)悪いコード(として槍玉に挙げられる類いのコード)は(大概が)複雑なコードである
みたいなもんだよね。
前段で既にその存在を許されている「複雑だけれど正しいコード」を今更いくら例示しても、そもそもそれは後段で言及されている「コード」とは、概念としてリンクしていないわけで。
ま、そもそも初っ端に「悪いコード=間違ったコード」という勘違いっつうか、赤っ恥を晒したしたことへの失地回復を図って、こうしてネチネチ粘着してるんだろうけど、ドツボっていうかさ、また更に理解力のないことを晒してるよね。
そこに込められた「行間」を常識的に補足すれば
論理に行き詰まると常識を持ち出すやつが多いね。困ったもんだ。
そこまで行間を読んじゃうのは、妄想に近いよ(笑)。もしそうなら、「複雑なコードが悪いコードであるとは限らないし、悪いコードが複雑なコードであるとは限らない」だよね。前半で例外を強調しているなら、後半の断定は、例外を含まないと読むことも十分ありうるね。
「複雑だけれど正しいコード」を今更いくら例示しても
正しくて単純だけど悪いコードと、正しくて複雑だけど良いコードを例示してるのが読めない? そりゃまた困ったもんだ。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
UNIXはただ死んだだけでなく、本当にひどい臭いを放ち始めている -- あるソフトウェアエンジニア
必要条件なんじゃないの? (スコア:0)
複雑なコードが悪いコードであるとは限らないが、悪いコードは複雑なコードである、みたいな?
Re: (スコア:1)
単純でも悪いコードはあるだろ。
で閏年を判定するとかさ。
Re: (スコア:0)
普通比較するのはロジックが当たっている前提でしょ。
Re: (スコア:0)
では、それを前提に反例を一つ示してみよう。例えば、ソートを実装するのに、
というコードがあったとしよう。<<クイックソートを実装>>の部分では、sort(array)を再帰的に呼び出す。
これに対して、次のようなコードを考える。
定数mは、実行速度が最適になるよう定める。このコードでも同様に<<クイックソートを実装>>の部分では、sort(array)を再帰的に呼び出す。
この二つのコードに関して言えば、どちらも正しい。後
Re: (スコア:0)
まさにこれは
> 複雑なコードが悪いコードであるとは限らないが、悪いコードは複雑なコードである、みたいな?
という例では?
複雑なコードが悪いコードであるとは限らない。の方の。
なにがやりたかったのか分からん。
Re: (スコア:0)
複雑なコードが悪いコードであるとは限らない。の方の。
そうだね。
なおかつ、「悪いコードは複雑である」とは限らないことの実例にもなってるだろ?
Re: (スコア:0)
複雑なコードは悪いコードである。
と
悪いコードは複雑なコードである。
とでは意味が違うってわかってるのかな…。
Re: (スコア:0)
「悪いコードは複雑である」とは限らないことの実例にもなってるだろ?
Re: (スコア:0)
君は
みたいな言い回しについて、ちゃんと理解出来てないんじゃないか?
Re:必要条件なんじゃないの? (スコア:0)
稀にいるよねw 言い回しとか慣用句みたいなのを理解できないで、言葉通りに読もうとする奴って。
この手の言い回し、そこに込められた「行間」を常識的に補足すれば
みたいなもんだよね。
前段で既にその存在を許されている「複雑だけれど正しいコード」を今更いくら例示しても、
そもそもそれは後段で言及されている「コード」とは、概念としてリンクしていないわけで。
ま、そもそも初っ端に「悪いコード=間違ったコード」という勘違いっつうか、
赤っ恥を晒したしたことへの失地回復を図って、こうしてネチネチ粘着してるんだろうけど、
ドツボっていうかさ、また更に理解力のないことを晒してるよね。
Re:必要条件なんじゃないの? (スコア:1)
そこに込められた「行間」を常識的に補足すれば
論理に行き詰まると常識を持ち出すやつが多いね。困ったもんだ。
複雑なコードが悪いコードであるとは限らないが、
(俗に)悪いコード(として槍玉に挙げられる類いのコード)は
(大概が)複雑なコードである
そこまで行間を読んじゃうのは、妄想に近いよ(笑)。
もしそうなら、「複雑なコードが悪いコードであるとは限らないし、悪いコードが複雑なコードであるとは限らない」だよね。前半で例外を強調しているなら、後半の断定は、例外を含まないと読むことも十分ありうるね。
「複雑だけれど正しいコード」を今更いくら例示しても
正しくて単純だけど悪いコードと、正しくて複雑だけど良いコードを例示してるのが読めない? そりゃまた困ったもんだ。