アカウント名:
パスワード:
ライティングソリッドコード [amazon.co.jp](カタカナだと何がなんやら。必殺技か?)に書いてあったと記憶してますが、if (1==n) {} で解決
むしろ両辺が変数の場合にしくじったら、(頭のなかでミスの条件からはずしているので)見つけづらくなる。
読みづらくなるデメリットに比べて、メリットが少なすぎるかと。いまどきのコンパイラなら警告出してくれるだろうから、警告のレベルを素直に上げたほうがよっぽどいいと思うけどなぁ。
> むしろ両辺が変数の場合にしくじったら、(頭のなかでミスの条件からはずしているので)見つけづらくなる。
なぜ頭の中で条件から外す?両辺が変数の場合はまず疑いましょう。
> 読みづらくなるデメリットに比べて、メリットが少なすぎるかと。
読みづらいのは慣れの問題ではありませんか?逆に言うと慣れればメリットしかない。
ちなみにコンパイルという工程が存在しない言語(PHP とか)では、右辺定数はかなり重要。C 以外でも利用できるから、慣らしておいた方が良い。
もちろん Lint も使いつつ、コンパイラの警告は最大限に利用してその上で右辺に定数を置く。
プログラマが想定してない動きをさせない努力は、慣れ不慣れとかいう理由で怠ってはいけない。
「ifの条件式で==を=に間違えることはない。バグを追っかけてるときにifの条件式中に=が現れていないことを確認する必要は全くない」。これが頭の中で条件から外した状態。
「ifの条件式で==を=に間違えることはない、ただし、==の両側が変数のときをのぞく。バグを追っかけてるときにifの条件式中に=が現れていないことを確認する必要がある、ただし、一方がr-valueだったら気にしなくてよい」。これは、気苦労が増えるだけ。
「ifの条件式で==を=に間違える可能性がある。バグを追っかけてるときにifの条件式中に=が現れていないことを確認すべし」。これが、よっぽど気楽。
lintなりのパーサを利用できない環境だったらどうするの?
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
最初のバージョンは常に打ち捨てられる。
あれ! if ( n = 1 ) { じゃないの? (スコア:1)
気が付かないで代入する件だとばっかり思っていました。
Re: (スコア:1)
ライティングソリッドコード [amazon.co.jp](カタカナだと何がなんやら。必殺技か?)に書いてあったと記憶してますが、
if (1==n) {} で解決
Re: (スコア:0)
むしろ両辺が変数の場合にしくじったら、(頭のなかでミスの条件からはずしているので)見つけづらくなる。
読みづらくなるデメリットに比べて、メリットが少なすぎるかと。
いまどきのコンパイラなら警告出してくれるだろうから、警告のレベルを素直に上げたほうがよっぽどいいと思うけどなぁ。
Re: (スコア:1)
> むしろ両辺が変数の場合にしくじったら、(頭のなかでミスの条件からはずしているので)見つけづらくなる。
なぜ頭の中で条件から外す?
両辺が変数の場合はまず疑いましょう。
> 読みづらくなるデメリットに比べて、メリットが少なすぎるかと。
読みづらいのは慣れの問題ではありませんか?
逆に言うと慣れればメリットしかない。
ちなみにコンパイルという工程が存在しない言語(PHP とか)では、
右辺定数はかなり重要。
C 以外でも利用できるから、慣らしておいた方が良い。
もちろん Lint も使いつつ、コンパイラの警告は最大限に利用して
その上で右辺に定数を置く。
プログラマが想定してない動きをさせない努力は、
慣れ不慣れとかいう理由で怠ってはいけない。
Re:あれ! if ( n = 1 ) { じゃないの? (スコア:0)
「ifの条件式で==を=に間違えることはない。バグを追っかけてるときにifの条件式中に=が現れていないことを確認する必要は全くない」。これが頭の中で条件から外した状態。
「ifの条件式で==を=に間違えることはない、ただし、==の両側が変数のときをのぞく。バグを追っかけてるときにifの条件式中に=が現れていないことを確認する必要がある、ただし、一方がr-valueだったら気にしなくてよい」。これは、気苦労が増えるだけ。
「ifの条件式で==を=に間違える可能性がある。バグを追っかけてるときにifの条件式中に=が現れていないことを確認すべし」。これが、よっぽど気楽。
Re: (スコア:0)
lintなりのパーサを利用できない環境だったらどうするの?