アカウント名:
パスワード:
TypeScriptはよく知らないんですが例えば（ちょっともう無茶苦茶な文法になってると思うけども）
#------------------------------class Foo { function boo() { } # function qoo() { } # 不要なので消したら・・・}
function fn(foo: Foo) { foo.qoo(); # ここのせいでコンパイルができない・・昨日まではコンパイルできたのに！}#------------------------------
となるって事ですよね？コンパイルできない以上はテストも実行できないわけだけど、物凄く不便じゃない？
# こういう時の自分は、重大な勘違いをしているｗ
不要だから消したFoo.qoo()が実行できる利点がよくわからない...
いや、コンパイル出来ない = 文法エラー = 実行前にエラーとなる箇所がわかる訳で…それが静的型付け言語の利点ですよね
「コンパイルできない以上はテストも実行できない」と言いますが、そもそもコンパイルを通らないコードの時点でテストする価値は無いです
ただ、例のようなプログラムは動的型付けの言語でも、コンパイル形式ならコンパイルの時点でエラーになる処理系は多い。なぜなら、qooという名前の変数（もしくは関数）は存在していないから。
まあ、静的型付けの言語の方がコンパイル時にエラーを出していくれることが多いから、助けられている気分にはなるけど、実際に問題になるのは、予期していない値が発生した場合。正の整数を期待していたのに負の整数が来ちゃった場合とか。
それを補完するのがテストでしょ。
スレ主は動的言語の使いすぎで大分本末転倒してるけど。
IDEのサポートを評価って書いてあるし大丈夫じゃねそもそもいきなり消したりしないでobsoleteにでもすべきでは
qooが不要ならfnも不要だから一緒に消せばいいじゃん。消すべきところが分かって便利でしょ。
テストが出来たとして、
・テストが通った→という事は、テスト中にfnが実行されていない→カバレッジが100%ではない→テストがクソ
で、そんな状況は考慮に値しないわけで、
・テスト中にfnが実行されて、Foo.qooが消された事によるエラーが報告される
正しくはこうなる。それがコンパイル時に事前に分かるようになるだけ。
テストを実行するまでもなく、ビルド（IDEのプリコンパイル）時点でエラーが分かるって見方をすると物凄く便利です。
何という動的言語脳……。コンパイル通らないからエラーがあるってわかるんでしょ。テストの目的は何？エラーを探すことでしょ。
つまり、テストを通すまでもなくエラーが発見できるわけだけど、何が不満？
流石にこれは笑った。本末転倒過ぎる。テストを通すのが目的なんでしょう。
本気でこれを不便だと思っているのか、例が不適切で意図が上手く伝わってないのか、物凄く気になる。fnは既に機能不全を起こしているのだから、当然テストは失敗して欲しいわけだが・・・
死ね
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
私はプログラマです。1040 formに私の職業としてそう書いています -- Ken Thompson
静的型の利点がよくわからない (スコア:0)
TypeScriptはよく知らないんですが例えば
（ちょっともう無茶苦茶な文法になってると思うけども）
#------------------------------
class Foo {
function boo() { }
# function qoo() { } # 不要なので消したら・・・
}
function fn(foo: Foo) {
foo.qoo(); # ここのせいでコンパイルができない・・昨日まではコンパイルできたのに！
}
#------------------------------
となるって事ですよね？
コンパイルできない以上はテストも実行できないわけだけど、物凄く不便じゃない？
# こういう時の自分は、重大な勘違いをしているｗ
Re:静的型の利点がよくわからない (スコア:1)
不要だから消したFoo.qoo()が実行できる利点がよくわからない...
Re:静的型の利点がよくわからない (スコア:1)
いや、コンパイル出来ない = 文法エラー = 実行前にエラーとなる箇所がわかる訳で…それが静的型付け言語の利点ですよね
「コンパイルできない以上はテストも実行できない」と言いますが、そもそもコンパイルを通らないコードの時点でテストする価値は無いです
Re: (スコア:0)
ただ、例のようなプログラムは動的型付けの言語でも、コンパイル形式ならコンパイルの時点でエラーになる処理系は多い。なぜなら、qooという名前の変数（もしくは関数）は存在していないから。
まあ、静的型付けの言語の方がコンパイル時にエラーを出していくれることが多いから、助けられている気分にはなるけど、実際に問題になるのは、予期していない値が発生した場合。正の整数を期待していたのに負の整数が来ちゃった場合とか。
Re: (スコア:0)
それを補完するのがテストでしょ。
スレ主は動的言語の使いすぎで大分本末転倒してるけど。
Re: (スコア:0)
IDEのサポートを評価って書いてあるし大丈夫じゃね
そもそもいきなり消したりしないでobsoleteにでもすべきでは
Re: (スコア:0)
コンパイルが、整合性確認テストだと思えばいいんでは？
IDE のサポートって意味では Visual Studio とかだと、まさに書いてる途中の未完成なコードでもバックグラウンドで単体テスト走らせてくれますよ。
まさに「書いてる途中」でも、その直前のところまでで、キー入力が少し中断されるたびに単体テストが走って、リアルタイムにどの行でエラーが出てるか教えてくれます。
なので、今時はコンパイル言語だからコンパイルできないとテストもできないなんて事もないです。
Re: (スコア:0)
qooが不要ならfnも不要だから一緒に消せばいいじゃん。
消すべきところが分かって便利でしょ。
Re: (スコア:0)
テストが出来たとして、
・テストが通った→という事は、テスト中にfnが実行されていない→カバレッジが100%ではない→テストがクソ
で、そんな状況は考慮に値しないわけで、
・テスト中にfnが実行されて、Foo.qooが消された事によるエラーが報告される
正しくはこうなる。それがコンパイル時に事前に分かるようになるだけ。
Re: (スコア:0)
テストを実行するまでもなく、ビルド（IDEのプリコンパイル）時点でエラーが分かるって見方をすると物凄く便利です。
Re: (スコア:0)
何という動的言語脳……。
コンパイル通らないからエラーがあるってわかるんでしょ。
テストの目的は何？
エラーを探すことでしょ。
つまり、テストを通すまでもなくエラーが発見できるわけだけど、何が不満？
Re: (スコア:0)
流石にこれは笑った。
本末転倒過ぎる。
テストを通すのが目的なんでしょう。
Re: (スコア:0)
本気でこれを不便だと思っているのか、例が不適切で意図が上手く伝わってないのか、物凄く気になる。
fnは既に機能不全を起こしているのだから、当然テストは失敗して欲しいわけだが・・・
Re: (スコア:0)
死ね