アカウント名:
パスワード:
きっかけはこのおもしろい(オブラートに包んだ表現)ツイートではないかな
https://twitter.com/fnya/status/1192036095820615680 [twitter.com]
(条件式 ? true : false ) ? true ? true : false : false ? true : falseて書けばさらに3倍くらい可読性が上がるのでは?
殺意しか上がりません……!
なんかすごい煽られてる気がする。
true? trueなの? false? false? ねえtrueなのfalseなのどっち?
みたいな。
殺意なら(条件式 ? true : false ) ? true ? true : false : false ? false : trueにすればもう3倍くらい上がると思います。
そこまで行くと、逆になんか、こう……引いちゃう?
普通は、三項演算子を入れ子で使うの禁止というコーディングルールがあると思いますが。
私は、入れ子にしない限りは可読性は悪くなく、コンパイルで最適化されるので速度も落ちないので、(条件式) ? true : false は良いと思います。
三項演算子の三項目に別の三項演算子を突っ込むのはそれほど見づらくないのでよく書くな。return 第1条件 ? a : 第2条件 ? b : 第3条件 ? c : d;みたいな?
switch caseに二項演算子が使える言語だとそっちで書くことも考えるけど、caseの間に代入とかreturnとかが並んでるのはスマートじゃないと思ったり。
入れ子禁止ルールは見たことないけど、そういう職場のあるのね。
C言語で条件の部分が数値にしか見えない場合は可読性が多少上がるかもしれない。ブール型の扱いが厳密な言語なら可読性があるように書かないとコンパイルエラーになるから、そういう言語しか使ってなければおかしく見えるかもね。
C99を知らない人にはピンと来ないかもしれませんね
ブール型の扱いが厳密な言語なら可読性があるように書かないとコンパイルエラーになるから、そういう言語しか使ってなければおかしく見えるかもね。
具体的にreturn (条件);がコンパイルエラーになってreturn (条件) ? true : false;がコンパイルエラーにならない言語って何があるの?
そういうことではなくて、ブール型を厳密に扱う言語のブール型を返す関数で「return 1+2*3/4」は真を返すことにならず、コンパイルエラーになるってこと。
そういう言語ではreturn (1+2*3/4) ? true : false;もコンパイルエラーになるのでは?
そういう言語ではreturn (1+2*3/4) != 0というような真偽値を表す式であることが一目でわかる(==可読性が高い)ように書かないとコンパイルエラーになるということです。
なんだ、三項演算子は関係ないのかよw
三項演算子をわざわざ使えばおかしく感じられる言語の方に突っ込みを入れていれば、三項演算子に関係ない回答になるのはしようがないです。
三項演算子の可読性や是非以前に、可読性の低い日本語しか書けないようなエンジニアが駄目な実例ですな。かわりに英語が堪能ならいいけど、だったら英語の/.いけと。
むしろ冗長に書いた方が可読性上がることの証明だな。
三項演算子をわざわざ使えばおかしく感じられる言語なら、三項演算子をわざわざ使えばおかしいので、そうでない場合に、三項演算子をわざわざ使うのはどうなのか?という話題だと思うのですが。
それについては元コメに対して直接コメントしたらよいのではないでしょうか。わざわざ私のコメントにつけたら私のコメントに対する話だと考えてしまうので。
私のコメントはC言語で条件式が数値の場合ならまだありかもね。という話なので、1. return 1+2*3/4or2. return (1+2*3/4) != 0or3. return (1+2*3/4) ? true : falseということになります。これなら趣味の問題かなと。
いや解ってないですが。というか、そのコメント自体何の根拠もないわけで。もしかして、Anonymous Cowardは意識の集合体なので、誰が書いてようが考えていることは同じとかいうネタですかね。
IDEを使うかどうかが何か関係するのか、誰がコンパイルが通らない状態で放置したのか、どんな腐った環境の話をしてるのか等は私も分かりかねます。
何の話をしているのかがよくわかりません。コメントの付け先をお間違えではないでしょうか。
最近、
(cond) ? (a = 1) : (a = 2);
ってコードを見かけてちょっと頭を抱えた。
if (cond) { a = 1; } else { a = 2; }
か
a = (cond) ? 1 : 2;
か、どっちかにしろ、と。
三項演算子は「代入処理は一つ(代入先は同じ)」であることを明確にできるのが、ifに対するメリットだと思うが、この例だと台無しというか両方の悪いところ取りでもう。一番可読性いいのは、
a
Kotlinがそうですね。でも、3項演算子もやっぱりありますが。
rubyか何かでも使えなかったっけ?気持ち悪いから使わないけど。
式の中に制御構文ぶちこんでる時点でどれも同じ。
Excelの=if()が恥ずかしげに顔を出します
# もうすぐ冬ですね
return (条件)? true : false; なんて書くくらいなら return 条件; だよなあそりゃレビューで落とすでしょ感
それを可読性が落ちると言ってつっぱねたというのがすごい。? true : falseがついている方が読みにくいと超個人的には思うけどね。
俺も、ゴミつけたら読み難いとしか思えないが、読み易い読み難いってのは個人の感性というか感想だから仕方ないのだろう。とはいえ自分に都合がよいからといって、一般的でないことやって読み難いから止めろと言われても、つっぱねるってのは、エンジニアを仕事にするの向いてないというか、チームに存在するだけで迷惑な奴ってことだから仕事変えて趣味だけに留めるべきだろうな。
https://twitter.com/fnya/status/1192039284821250048 [twitter.com]別ツイートで、こんなことも言ってるから、つまみぐい的にプログラム書いてきて、そもそものプログラムへの理解が乏しいようだから、自分の能力不足を改善せずに目先の問題回避してきた結果、そうしないと困ってるのかもね。そのあたりも思考方向がエンジニア向きじゃなさそう。
TokusiN @toku51n 11月6日返信先: @fnyaさん
trueとの比較は危険なのでやってはいけない。もしどうしてもbool型との比較が必要なのであれば!=falseにしなければいけない。1件の返信 2件のリツイート 10 いいね
fnya@Web/Mobileアプリ構築中 @fnya 11月6日
危険というのは、PHPやJavaScriptでオブジェクトがtrue判定されることですか?1件の返信 0件のリツイート 0 いいね
TokusiN @toku51n 11月6日
いえ、trueと評価されるべきものがfalse判定されることがあります。1件の返信 0件のリツイート 3 いいね
fnya@Web/Mobileアプリ構築中 @fnya11月6日
?!1件の返信 0件のリツイート 0 いいね
?!じゃねえよ。頭が正常系でできてんのか?
頭が正常系でできてんのか?
これ重要な指摘かと。プログラマたるもの鼻から悪魔を出させるようなことはしたくないにちがいないのですが、だいたいの処理系の鼻には悪魔がたくさん住み着いているので。
if ( (a == b) == true )みたいなのはコード引き取ると良くある…
if (!Foo()) { ... }って書きたいけど、「!」の視認性が悪いから、
if (Foo() == false) { ... }としてるんだという意見に対して、
if (!!!Foo()) { ... }のように奇数個の「!」を気の済むまで書けばいいじゃんていう話好き
# そして間違って偶数個の!を書いてしまうまでがブック
if ( ( a b) != false ) じゃなかっただけありがたいと思うんだ。
return ok ? true : false;なら俺でも怒るがreturn b*b-4*a*c >= 0 ? true : false;なら怒らない
この手の三項演算子結果をboolにしたくなるケースの本質は型が分かりにくいという点にあるのではと最近は思っている自分ならばこうするかなint d = b*b-4*a*c;return d >= 0;
式の中で型が変化しまくる場合、型が変わるタイミングで変数に入れてから、新しい式を作っていけば見通しが良くなるのではと思っている。
この例は二次方程式の判別式だからd)iscriminantだとわかるが、プログラム固有の境界条件であれば名前を考える必要があり、定義中の関数名と似たようになるか、さぼってaとかxとかつけて可読性を落とすのが常の住処人間五十年、境界条件は「…なら真(、それ以外は偽)」と覚えるし、日本語でも英語でもそう読み書きするものだだからプログラムでもそうして悪い理由はない
>return b*b-4*a*c >= 0 ? true : false;
そこまでいくなら、判定内容がわかりやすい名前の関数にしたら?って思っちゃうな。
動的型付けだったり、型推論したりの場合はreturn f(x);よりreturn f(x) ? true : false;のことのほうがありがたい場合があるとくにf(x)を他人が定義していて、しかもtrueとfalse以外を帰す場合
とくにf(x)を他人が定義していて、しかもtrueとfalse以外を帰す場合
return (f(x)!=0);みたいに書けばいいと思う。
Cだと関係演算子の結果はintの値なので、return する関数の型がboolだったりすると暗黙的な型変換が行われることになるので気持ちが悪い。条件演算子を使うかで true か false を返すようした方が良いと思う。
C99で導入されたbool(_Bool)では、false/trueはintなので、結局三項演算子を使ってtrue/falseにしても、_Boolへの暗黙の型変換は行われてしいますよ。一方、C++で導入されたboolの場合は、比較演算子はbool型を返すので、三項演算子を使わなくても暗黙の型変換は行われない結局、C99でもC++でも、「cond ? true : false」したからといって型の取り扱いは何も変わらない。
それに、暗黙の型変換がいやだというなら、明示的に型キャストすればいいだけ。そこで三項演算子を使うのは「言語処理系が提供する型キャスト機能があるのに、同等のコードを手で書く」という車輪の再発明で、無駄にバグの元になりかねない。
C99では、_Bool型が新たに作られた。0と1しか値をとらない、intとは別の型stdbool.hで、bool は _Boolと定義されている。stdbool.hで、true/falseは、1/0と定義されている。int型の定数。
なので、「bool a = true;」とかやっても、intから_Boolへの暗黙の型変換が行われる、という話ですよ。
C99では、先に「比較演算子は、真なら1、偽なら0になる」という仕様があって、それにあわせて、後からtrueとfalseが定義されている(だから、true/falseは_Bool型ではなく、int型の定数になってる)。
だから、言語仕様上、比較演算子がtrueかfalseを返すのは明白。「a > b ? true : false」みたいに、「trueかfalseな値」を元に「trueかfalseに仕分ける」のは無駄でしかない。そうしないと「不安が残」るようでは、C言語への理解が浅いだけでしょう。
「a+b ? true : false」みたいなコードなら、「明示的にbool化する」という意図は分からないでもない。でも、このコードは車輪の再発明。「(bool)(a+b)」の方が意図が明確。
書き手の意図は汲み取れるから怒りはしないけど、その式が条件式(=真偽の値を返す)であると認識しているから三項演算の条件に使っているのに、真のときにtrue、偽の時にfalse と書くのはやはり冗長には感じるな。
尾も白いアイコンだと思った。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
UNIXはただ死んだだけでなく、本当にひどい臭いを放ち始めている -- あるソフトウェアエンジニア
発端? (スコア:3, 参考になる)
きっかけはこのおもしろい(オブラートに包んだ表現)ツイートではないかな
https://twitter.com/fnya/status/1192036095820615680 [twitter.com]
Re:発端? (スコア:5, おもしろおかしい)
>
>(条件式) ? true : false
>
>って書くよね?
>
>レビューで条件式だけで動作するとしつこく詰め寄られたけど、可読性が落ちると突っぱねた。
その理屈が成り立つなら
(条件式 ? true : false ) ? true ? true : false : false ? true : false
て書けばさらに3倍くらい可読性が上がるのでは?
Re:発端? (スコア:1)
(条件式 ? true : false ) ? true ? true : false : false ? true : false
て書けばさらに3倍くらい可読性が上がるのでは?
殺意しか上がりません……!
Re:発端? (スコア:1)
なんかすごい煽られてる気がする。
true? trueなの? false? false? ねえtrueなのfalseなのどっち?
みたいな。
Re: (スコア:0)
殺意なら
(条件式 ? true : false ) ? true ? true : false : false ? false : true
にすればもう3倍くらい上がると思います。
Re:発端? (スコア:1)
そこまで行くと、逆になんか、こう……引いちゃう?
Re:発端? (スコア:1)
普通は、三項演算子を入れ子で使うの禁止というコーディングルールがあると思いますが。
私は、入れ子にしない限りは可読性は悪くなく、コンパイルで最適化されるので速度も落ちないので、(条件式) ? true : false は良いと思います。
Re:発端? (スコア:1)
三項演算子の三項目に別の三項演算子を突っ込むのはそれほど見づらくないのでよく書くな。
return 第1条件 ? a :
第2条件 ? b :
第3条件 ? c : d;
みたいな?
switch caseに二項演算子が使える言語だとそっちで書くことも考えるけど、caseの間に代入とかreturnとかが並んでるのはスマートじゃないと思ったり。
入れ子禁止ルールは見たことないけど、そういう職場のあるのね。
Re:発端? (スコア:1)
C言語で条件の部分が数値にしか見えない場合は可読性が多少上がるかもしれない。
ブール型の扱いが厳密な言語なら可読性があるように書かないとコンパイルエラーになるから、そういう言語しか使ってなければおかしく見えるかもね。
Re:発端? (スコア:1)
C99を知らない人にはピンと来ないかもしれませんね
Re: (スコア:0)
具体的に
return (条件);
がコンパイルエラーになって
return (条件) ? true : false;
がコンパイルエラーにならない言語って何があるの?
Re:発端? (スコア:1)
そういうことではなくて、ブール型を厳密に扱う言語のブール型を返す関数で「return 1+2*3/4」は真を返すことにならず、コンパイルエラーになるってこと。
Re: (スコア:0)
そういう言語では
return (1+2*3/4) ? true : false;
もコンパイルエラーになるのでは?
Re:発端? (スコア:1)
そういう言語ではreturn (1+2*3/4) != 0というような真偽値を表す式であることが一目でわかる(==可読性が高い)ように書かないとコンパイルエラーになるということです。
Re: (スコア:0)
なんだ、三項演算子は関係ないのかよw
Re:発端? (スコア:1)
三項演算子をわざわざ使えばおかしく感じられる言語の方に突っ込みを入れていれば、三項演算子に関係ない回答になるのはしようがないです。
Re:発端? (スコア:1)
三項演算子の可読性や是非以前に、可読性の低い日本語しか書けないようなエンジニアが駄目な実例ですな。
かわりに英語が堪能ならいいけど、だったら英語の/.いけと。
Re: (スコア:0)
むしろ冗長に書いた方が可読性上がることの証明だな。
Re: (スコア:0)
三項演算子をわざわざ使えばおかしく感じられる言語なら、三項演算子をわざわざ使えばおかしいので、
そうでない場合に、三項演算子をわざわざ使うのはどうなのか?という話題だと思うのですが。
Re:発端? (スコア:1)
それについては元コメに対して直接コメントしたらよいのではないでしょうか。
わざわざ私のコメントにつけたら私のコメントに対する話だと考えてしまうので。
Re:発端? (スコア:1)
私のコメントはC言語で条件式が数値の場合ならまだありかもね。という話なので、
1. return 1+2*3/4
or
2. return (1+2*3/4) != 0
or
3. return (1+2*3/4) ? true : false
ということになります。これなら趣味の問題かなと。
Re:発端? (スコア:1)
いや解ってないですが。
というか、そのコメント自体何の根拠もないわけで。もしかして、Anonymous Cowardは意識の集合体なので、誰が書いてようが考えていることは同じとかいうネタですかね。
Re:発端? (スコア:1)
IDEを使うかどうかが何か関係するのか、誰がコンパイルが通らない状態で放置したのか、どんな腐った環境の話をしてるのか等は私も分かりかねます。
Re:発端? (スコア:1)
何の話をしているのかがよくわかりません。コメントの付け先をお間違えではないでしょうか。
Re: (スコア:0)
最近、
ってコードを見かけてちょっと頭を抱えた。
か
か、どっちかにしろ、と。
三項演算子は「代入処理は一つ(代入先は同じ)」であることを明確にできるのが、ifに対するメリットだと思うが、この例だと台無しというか両方の悪いところ取りでもう。
一番可読性いいのは、
Re: (スコア:0)
確かにif式って昔っからあるの以外は最近追加しましたみたいのは聞かないような
Re: (スコア:0)
Kotlinがそうですね。でも、3項演算子もやっぱりありますが。
Re: (スコア:0)
rubyか何かでも使えなかったっけ?
気持ち悪いから使わないけど。
式の中に制御構文ぶちこんでる時点でどれも同じ。
Re:発端? (スコア:1)
Excelの=if()が恥ずかしげに顔を出します
# もうすぐ冬ですね
-- う~ん、バッドノウハウ?
Re:発端? (スコア:1)
// オランダ人というと飛んだりさまよったりするほう
Re: (スコア:0)
return (条件)? true : false; なんて書くくらいなら return 条件; だよなあ
そりゃレビューで落とすでしょ感
Re: (スコア:0)
それを可読性が落ちると言ってつっぱねたというのがすごい。
? true : false
がついている方が読みにくいと超個人的には思うけどね。
Re: (スコア:0)
俺も、ゴミつけたら読み難いとしか思えないが、読み易い読み難いってのは個人の感性というか感想だから仕方ないのだろう。
とはいえ自分に都合がよいからといって、一般的でないことやって読み難いから止めろと言われても、つっぱねるってのは、エンジニアを仕事にするの向いてないというか、チームに存在するだけで迷惑な奴ってことだから仕事変えて趣味だけに留めるべきだろうな。
https://twitter.com/fnya/status/1192039284821250048 [twitter.com]
別ツイートで、こんなことも言ってるから、つまみぐい的にプログラム書いてきて、そもそものプログラムへの理解が乏しいようだから、自分の能力不足を改善せずに目先の問題回避してきた結果、そうしないと困ってるのかもね。
そのあたりも思考方向がエンジニア向きじゃなさそう。
Re:発端? (スコア:2, 参考になる)
TokusiN @toku51n 11月6日
返信先: @fnyaさん
trueとの比較は危険なのでやってはいけない。もしどうしてもbool型との比較が必要なのであれば!=falseにしなければいけない。
1件の返信 2件のリツイート 10 いいね
fnya@Web/Mobileアプリ構築中 @fnya 11月6日
危険というのは、PHPやJavaScriptでオブジェクトがtrue判定されることですか?
1件の返信 0件のリツイート 0 いいね
TokusiN @toku51n 11月6日
いえ、trueと評価されるべきものがfalse判定されることがあります。
1件の返信 0件のリツイート 3 いいね
fnya@Web/Mobileアプリ構築中 @fnya11月6日
?!
1件の返信 0件のリツイート 0 いいね
?!じゃねえよ。頭が正常系でできてんのか?
Re:発端? (スコア:1)
これ重要な指摘かと。
プログラマたるもの鼻から悪魔を出させるようなことはしたくないにちがいないのですが、だいたいの処理系の鼻には悪魔がたくさん住み着いているので。
Re: (スコア:0)
if ( (a == b) == true )
みたいなのはコード引き取ると良くある…
Re:発端? (スコア:1)
if (!Foo()) { ... }
って書きたいけど、「!」の視認性が悪いから、
if (Foo() == false) { ... }
としてるんだという意見に対して、
if (!!!Foo()) { ... }
のように奇数個の「!」を気の済むまで書けばいいじゃんていう話好き
# そして間違って偶数個の!を書いてしまうまでがブック
Re: (スコア:0)
if ( ( a b) != false ) じゃなかっただけありがたいと思うんだ。
Re: (スコア:0)
return ok ? true : false;
なら俺でも怒るが
return b*b-4*a*c >= 0 ? true : false;
なら怒らない
Re: (スコア:0)
この手の三項演算子結果をboolにしたくなるケースの本質は型が分かりにくいという点にあるのではと最近は思っている
自分ならばこうするかな
int d = b*b-4*a*c;
return d >= 0;
式の中で型が変化しまくる場合、型が変わるタイミングで変数に入れてから、新しい式を作っていけば見通しが良くなるのではと思っている。
Re: (スコア:0)
この例は二次方程式の判別式だからd)iscriminantだとわかるが、プログラム固有の境界条件であれば名前を考える必要があり、定義中の関数名と似たようになるか、さぼってaとかxとかつけて可読性を落とすのが常の住処
人間五十年、境界条件は「…なら真(、それ以外は偽)」と覚えるし、日本語でも英語でもそう読み書きするものだ
だからプログラムでもそうして悪い理由はない
Re: (スコア:0)
>return b*b-4*a*c >= 0 ? true : false;
そこまでいくなら、判定内容がわかりやすい名前の関数にしたら?
って思っちゃうな。
Re: (スコア:0)
動的型付けだったり、型推論したりの場合は
return f(x);
より
return f(x) ? true : false;
のことのほうがありがたい場合がある
とくにf(x)を他人が定義していて、しかもtrueとfalse以外を帰す場合
Re:発端? (スコア:1)
return (f(x)!=0);
みたいに書けばいいと思う。
Re: (スコア:0)
Cだと関係演算子の結果はintの値なので、return する関数の型がboolだったりすると暗黙的な型変換が行われることになるので気持ちが悪い。条件演算子を使うかで true か false を返すようした方が良いと思う。
Re:発端? (スコア:1)
C99で導入されたbool(_Bool)では、false/trueはintなので、結局三項演算子を使ってtrue/falseにしても、_Boolへの暗黙の型変換は行われてしいますよ。
一方、C++で導入されたboolの場合は、比較演算子はbool型を返すので、三項演算子を使わなくても暗黙の型変換は行われない
結局、C99でもC++でも、「cond ? true : false」したからといって型の取り扱いは何も変わらない。
それに、暗黙の型変換がいやだというなら、明示的に型キャストすればいいだけ。
そこで三項演算子を使うのは「言語処理系が提供する型キャスト機能があるのに、同等のコードを手で書く」という車輪の再発明で、無駄にバグの元になりかねない。
Re:発端? (スコア:1)
C99では、
_Bool型が新たに作られた。0と1しか値をとらない、intとは別の型
stdbool.hで、bool は _Boolと定義されている。
stdbool.hで、true/falseは、1/0と定義されている。int型の定数。
なので、「bool a = true;」とかやっても、intから_Boolへの暗黙の型変換が行われる、という話ですよ。
Re:発端? (スコア:1)
C99では、先に「比較演算子は、真なら1、偽なら0になる」という仕様があって、それにあわせて、後からtrueとfalseが定義されている(だから、true/falseは_Bool型ではなく、int型の定数になってる)。
だから、言語仕様上、比較演算子がtrueかfalseを返すのは明白。「a > b ? true : false」みたいに、「trueかfalseな値」を元に「trueかfalseに仕分ける」のは無駄でしかない。そうしないと「不安が残」るようでは、C言語への理解が浅いだけでしょう。
「a+b ? true : false」みたいなコードなら、「明示的にbool化する」という意図は分からないでもない。でも、このコードは車輪の再発明。「(bool)(a+b)」の方が意図が明確。
Re: (スコア:0)
書き手の意図は汲み取れるから怒りはしないけど、
その式が条件式(=真偽の値を返す)であると認識しているから三項演算の条件に使っているのに、
真のときにtrue、偽の時にfalse と書くのはやはり冗長には感じるな。
Re: (スコア:0)
尾も白いアイコンだと思った。