アカウント名:
パスワード:
もうやらないですねぇエラー出したくなったときとかめんどいし年のせいか明確さ優先でそんなことにほんのささやかでも頭使う余裕が無い書き捨てなら使わんでも無いですが、人が見る可能性なあるコードならやりませんねif文中での代入やらforで二つ初期化、演算とかもやりませんねぇ
ショートサーキットで問題がになるのは条件式に副作用がある場合で、それを前提にしたコードは書くべきではないとは思いますが、if条件式中で&&や||を使わずにどうするの?って逆に疑問に思ってしまいますねぇ。「if (cond1 && cond2) {…」は、「if (cond1) { if (cond2) {…」 って書いたりのでしょうか?# ショートサーキットは怖いとかいって 「if (cond1 & cond2) {」って書くと、非常に危険。
> if文中での代入
これはC++では多用してますね。変数宣言とセットで。CでもC99からはいけるんでしたっけ。
if (FILE *fp = fopen(path, "rb")) { /* ファイルの内容を読み込む */ fclose(fp);}
みたいな感じ。ifの外では変数スコープが外れるので、そこで間違えてfcloseする心配はありません。
if条件式中で変数宣言すると比較ができないので、主にポインタで使いますが、「boolにキャストすると正常時にtrueになる」ような値でもできますので、そういう使い方ができるようにメソッド設計でも考慮してます。
あと、perlだとif文代わりのショートサーキットについては、and / or 演算子がありますね。
open(my FH, "<", $path) or die "cannot open $path: $!";
って感じで。
条件式に副作用が無ければショートサーキットがあっても無くても処理結果は変わらないので、「ショートサーキットを利用しない」って言うのは「副作用のある条件式を(複数)使わない」ってことです流石に&&使わないとか、&使うとかって話じゃ無いですね…かさばりますし
if文での代入はミスが出やすいのでやりたくないというところ()忘れるとかですねif (result = func() != FAIL)とかんーでも単に単純にしたいって方が大きいかも
宣言込みでスコープ縛れるのはかなり魅力的なんですけどね…若い子が見た目真似して先に書いたようなドジを踏むのが怖くてためらいます
perlでよくやるやつはif文が無いからかそこまで気にならないですね専用単語立てて欲しい気はしますがthen/elseとかだとモロかぶりでまずいか…
メソッド設計はそういうの良いですよね
コメントありがとうございます。
秘教秘儀に傾きかねない宗教論争ではなくて費用便益という実利に尽きるんでしょう。
>若い子が見た目真似して>perlでよくやるやつはif文が無いから>メソッド設計は
という補足説明を読んでいると一層そう思います。代償がなくて楽になるならそれに越したことは無いわけだが代償はある。
判定処理に副作用が無い場合でも、ショートサーキットには「より頻度の高い(もしくは処理の軽い)条件判断を左に持ってくることで、判断処理の平均計算量負荷を下げることができる」という利点がありますよ。
あとは、左辺が成立していることが右辺判定の実行可能条件になってる場合。「if (p && p->value > 0) {」とかですね。(元コメの「if (cond1 && cond2) { → if (cond1) { if (cond2) { 」で想定したのはこれです。
if (p) { if (p->value > 0) {…
って感じのコードは結構見かけると思います)
あとは、左辺が成立していることが右辺判定の実行可能条件になってる場合。「if (p && p->value > 0) {」とかですね。> (元コメの「if (cond1 && cond2) { → if (cond1) { if (cond2) { 」で想定したのはこれです。これは理解が及んでおりませんでした私もこういうのは使います気にならないのはイディオムとして捕らえてるのかなぁ
まだかろうじて「あるある」の領域だろうけどしらみつぶしに横展開するコード再調査の様相も呈してきた。そこまでの再検証は範囲外。
気力が充実してきたら必要に応じてお仕事リソースでどうぞー。
コメントありがとうございます
>判断処理の平均計算量負荷を下げることができる
レビュアー他人間の負荷に言及しているのか?とも思いましたがこれもプログラム実行時の話ですよね。
全体の比率から小さいにしても利点があって損得勘定に効いてくるかもですね。
>で想定したのはこれです。
Pascal 他の古典的(?)処理系・翻訳系でネストが深くてげんなりするタイプの見た目をすっきりさせる効果は否定しません。それでいいのか?という判断留保もつきまといますけど。
VB.NETだとAndThen/OrElseというショートサーキット評価用の演算子が追加されていますね。
.NET から COMコンポーネントやら DLL やらを呼び出したときの副作用に対して見通しがよくなるまたは最悪でも同程度というのでしたらいいのですが。「あります」「サポートしています」だけでは訴求力がちと弱い印象。
>条件式に副作用がある場合
熟慮すべき判断条件の要諦ですね。上記一言に尽くされている。反対解釈で判断のコストや判断間違いのリスクが負担できるならためらわないでよい、といったところ。別途議論はつくされてましょうけど。
>「if (cond1) { if (cond2) {…」 って書いたりのでしょうか?
こう書かないで済むなら避けたいですねえ。。。
>perlだとif文代わりのショートサーキットについては、and / or 演算子
手癖というか手垢にまみれた常套句として尊重しています。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
私はプログラマです。1040 formに私の職業としてそう書いています -- Ken Thompson
ショートサーキット利用はねぇ (スコア:2)
もうやらないですねぇ
エラー出したくなったときとかめんどいし
年のせいか明確さ優先でそんなことにほんのささやかでも頭使う余裕が無い
書き捨てなら使わんでも無いですが、
人が見る可能性なあるコードならやりませんね
if文中での代入やらforで二つ初期化、演算とかもやりませんねぇ
Re:ショートサーキット利用はねぇ (スコア:1)
ショートサーキットで問題がになるのは条件式に副作用がある場合で、それを前提にしたコードは書くべきではないとは思いますが、
if条件式中で&&や||を使わずにどうするの?って逆に疑問に思ってしまいますねぇ。
「if (cond1 && cond2) {…」は、「if (cond1) { if (cond2) {…」 って書いたりのでしょうか?
# ショートサーキットは怖いとかいって 「if (cond1 & cond2) {」って書くと、非常に危険。
> if文中での代入
これはC++では多用してますね。変数宣言とセットで。CでもC99からはいけるんでしたっけ。
みたいな感じ。ifの外では変数スコープが外れるので、そこで間違えてfcloseする心配はありません。
if条件式中で変数宣言すると比較ができないので、主にポインタで使いますが、「boolにキャストすると正常時にtrueになる」ような値でもできますので、そういう使い方ができるようにメソッド設計でも考慮してます。
あと、perlだとif文代わりのショートサーキットについては、and / or 演算子がありますね。
って感じで。
Re:ショートサーキット利用はねぇ (スコア:2)
条件式に副作用が無ければショートサーキットがあっても無くても処理結果は変わらないので、
「ショートサーキットを利用しない」って言うのは「副作用のある条件式を(複数)使わない」ってことです
流石に&&使わないとか、&使うとかって話じゃ無いですね…かさばりますし
if文での代入はミスが出やすいのでやりたくないというところ
()忘れるとかですね
if (result = func() != FAIL)
とか
んーでも単に単純にしたいって方が大きいかも
宣言込みでスコープ縛れるのはかなり魅力的なんですけどね…
若い子が見た目真似して先に書いたようなドジを踏むのが怖くてためらいます
perlでよくやるやつはif文が無いからかそこまで気にならないですね
専用単語立てて欲しい気はしますが
then/elseとかだとモロかぶりでまずいか…
メソッド設計はそういうの良いですよね
Re:ショートサーキット利用はねぇ (スコア:1)
コメントありがとうございます。
秘教秘儀に傾きかねない宗教論争ではなくて
費用便益という実利に尽きるんでしょう。
>若い子が見た目真似して
>perlでよくやるやつはif文が無いから
>メソッド設計は
という補足説明を読んでいると一層そう思います。
代償がなくて楽になるならそれに越したことは無いわけだが代償はある。
Re:ショートサーキット利用はねぇ (スコア:1)
判定処理に副作用が無い場合でも、ショートサーキットには「より頻度の高い(もしくは処理の軽い)条件判断を左に持ってくることで、判断処理の平均計算量負荷を下げることができる」という利点がありますよ。
あとは、左辺が成立していることが右辺判定の実行可能条件になってる場合。「if (p && p->value > 0) {」とかですね。
(元コメの「if (cond1 && cond2) { → if (cond1) { if (cond2) { 」で想定したのはこれです。
って感じのコードは結構見かけると思います)
Re:ショートサーキット利用はねぇ (スコア:2)
あとは、左辺が成立していることが右辺判定の実行可能条件になってる場合。「if (p && p->value > 0) {」とかですね。
> (元コメの「if (cond1 && cond2) { → if (cond1) { if (cond2) { 」で想定したのはこれです。
これは理解が及んでおりませんでした
私もこういうのは使います
気にならないのはイディオムとして捕らえてるのかなぁ
Re:ショートサーキット利用はねぇ (スコア:1)
コメントありがとうございます。
まだかろうじて「あるある」の領域だろうけど
しらみつぶしに横展開するコード再調査の様相も呈してきた。
そこまでの再検証は範囲外。
気力が充実してきたら必要に応じてお仕事リソースでどうぞー。
Re:ショートサーキット利用はねぇ (スコア:1)
コメントありがとうございます
>判断処理の平均計算量負荷を下げることができる
レビュアー他人間の負荷に言及しているのか?とも思いましたが
これもプログラム実行時の話ですよね。
全体の比率から小さいにしても利点があって損得勘定に効いてくるかもですね。
>で想定したのはこれです。
Pascal 他の古典的(?)処理系・翻訳系でネストが深くてげんなりするタイプ
の見た目をすっきりさせる効果は否定しません。
それでいいのか?という判断留保もつきまといますけど。
Re: (スコア:0)
VB.NETだとAndThen/OrElseというショートサーキット評価用の演算子が追加されていますね。
Re:ショートサーキット利用はねぇ (スコア:1)
コメントありがとうございます。
.NET から COMコンポーネントやら DLL やらを呼び出したときの副作用に対して
見通しがよくなるまたは最悪でも同程度というのでしたらいいのですが。
「あります」「サポートしています」だけでは訴求力がちと弱い印象。
Re:ショートサーキット利用はねぇ (スコア:1)
コメントありがとうございます。
>条件式に副作用がある場合
熟慮すべき判断条件の要諦ですね。上記一言に尽くされている。
反対解釈で判断のコストや判断間違いのリスクが負担できるなら
ためらわないでよい、といったところ。
別途議論はつくされてましょうけど。
>「if (cond1) { if (cond2) {…」 って書いたりのでしょうか?
こう書かないで済むなら避けたいですねえ。。。
>perlだとif文代わりのショートサーキットについては、and / or 演算子
手癖というか手垢にまみれた常套句として尊重しています。