アカウント名:
パスワード:
きっかけはこのおもしろい(オブラートに包んだ表現)ツイートではないかな
https://twitter.com/fnya/status/1192036095820615680 [twitter.com]
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 いいね
?!じゃねえよ。頭が正常系でできてんのか?
昔の C で bool 型を整数型の typedef とかでやってた頃の話じゃね?C99 以降の stdbool.h 使ってる分には true との比較になんか問題あるかなあ??
ダメ_Bool は暗黙のキャストにおいて優先度が一番低いから、その手の比較に関しての問題は_Boolが無かった時代とまったく同じ。
https://twitter.com/toku51n/status/1192100468144521216 [twitter.com] の流れの話だと思うけども、_Boolの変数に対してif (変数 == true) {}したとして、「_Bool は暗黙のキャストにおいて優先度が一番低い」という話がなんで出てくるのかがまずわからん
みんな分かってると思うけど補足。
!= false と書くべきって理由は、false 、true は値としては 0 、1 になるってところ。そこに 2 とか 3 とかの値が来たときにどう動くのか、それを考えろってこと。
0 、1 以外は想定外？ それならそれを保証しろ、と。ドキュメントとか assert() とかでも良いけど、実環境の実行時には無力。
あと、ツイートの「条件式だけで動作する」ってやつは「式の値」だと思うけど、C 特有で分かりにくいとは思う。「副作用」もあるだろうし。
_Bool は 0 か 1 以外の値取り様ないだろアホか
頭が正常系でできてんのか?
これ重要な指摘かと。プログラマたるもの鼻から悪魔を出させるようなことはしたくないにちがいないのですが、だいたいの処理系の鼻には悪魔がたくさん住み着いているので。
マが読みやすい読みにくいと言う場合は大抵認知的負荷に関する発言だから個人の感性の問題ではないよ。ただ、計算機科学やソフトウェア工学の分野の人間は認知科学に関する知識が絶望的に足りてないから他分野とは言え知らなすぎると言うのは問題だろうね。
計算機科学やソフトウェア工学の人間に「お前らが普段から言ってるクラスだの何だのも認知科学とか存在論とかオントロジーとかと領域被ってんぞ」って言っても理解され難いし。
>危険というのは、PHPやJavaScriptでオブジェクトがtrue判定されることですか？はまあ、アレよ。真偽値が抽象化されてて（真偽値型がある）真偽値の生の表現に変換できない言語しか触ったこと無いんじゃないの？boolean型やtrue/falseの定義を気にしなくていい言語。
それでは、? true : false の有無による認知的負荷の違いについて、認知科学の立場から説明して下さい。
if ( (a == b) == true )みたいなのはコード引き取ると良くある…
if (!Foo()) { ... }って書きたいけど、「!」の視認性が悪いから、
if (Foo() == false) { ... }としてるんだという意見に対して、
if (!!!Foo()) { ... }のように奇数個の「!」を気の済むまで書けばいいじゃんていう話好き
# そして間違って偶数個の！を書いてしまうまでがブック
#define NOT !
if (NOT Foo()) { ... }プロはこう書く(書かない)
プロなら規格で用意されているnotを使う。実際、C++の商用コードで見かけたことはある。
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); とする方が評価式を返してるのがより明らかに思えるけどなあ。
自分が書くのにどちらがよいかではなく、他人が書いたのに怒るかどうか、許容できるかどうかの話をしているのですプログラマーは論理思考ができないのか
「怒る」「許容できる」なんて主観的な基準を論じてるんだから「自分が書くのにどちらがよいか」の話だろお前の論理思考では何がどう違うんだ
これはコードレビューの話だから、怒るとか許容できないというのは自分一人だけの問題ではなく、チームの総意である「おまえはこんな書き方はやめろ」と禁止するなら、禁止する理由が必要だ和ゴミを嫌っていても、禁止する理由がなければ禁止できないのと同じだ
俺の書き込みはそのチームの一員と仮定してだした意見であり、個人的に好む書き方とは限らない
＞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(_Bool)では、false/trueはintなので、
仕様としては stdbool.h に定義されてるのは論理型 bool と論理値 true と false だからそれを使うべきだよ。
暗黙の型変換がいやだというなら、明示的に型キャストすればいいだけ。
キャストの危険性認識してない奴がなんか言ってらぁｗ
C99では、_Bool型が新たに作られた。0と1しか値をとらない、intとは別の型stdbool.hで、bool は _Boolと定義されている。stdbool.hで、true/falseは、1/0と定義されている。int型の定数。
なので、「bool a = true;」とかやっても、intから_Boolへの暗黙の型変換が行われる、という話ですよ。
stdbool.h に定義されてる true と false は論理値として用意されてるものなので bool のオブジェクトに代入するのは安心してできますね。対して、算術演算の結果が 0 や 1 になるからといって 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)」の方が意図が明確。
C99で導入されたbool(_Bool)では、false/trueはintなので、結局三項演算子を使ってtrue/falseにしても、_Boolへの暗黙の型変換は行われてしいますよ。
C99のstdbool.hは妥協の上での折衷案ですが、再定義も認められているのでそうすれば済む話ですね。#include <stdbool.h>
#ifdef true#undef true#endif#define true ((_Bool)1)
#ifdef false#undef false#endif#define false ((_Bool)0)
When any scalar value is converted to _Bool, the result is 0 if the value compares equal to 0; otherwise, the result is 1.
という言語仕様でも不安がなくならないって、強迫神経症か何かなの？
こんな再定義こそ「気持ち悪い」と言うのでは？
otherwise, the result is 1.
int hoge(int i){ bool b = i; return b == i;}が常に 1 返す保証でもない限りはスカラ値から論理型への変換は避けるべき。
ごめん、その保証がないと何が不安なの？
あんたでもtrueとfalseのかわりに全部1と0で書いてあるコードや、変数名がぜんぶ連番のコードを読まされたら怒るだろ？プログラミング言語の意味論と、人間にどう見えるかは全然別の話だよプログラミング脳になっちゃってるのか、頭が悪いやつはごっちゃにしてるけどな
味噌も糞も一緒な人に説明する意味がどれだけあるやら
そこは
return !!f(x);
が様式美じゃない？
ゼロやnullじゃないってのはコメントがないとぱっと見では分からないけど、!!は瞬時にわかるしよく見かける(気がする)。
!!は二重否定だからプログラミング言語の意味論以外には、トートロジーでしかないプログラム上にトートロジーがあるとは普通は思わないから、これを!一つと見間違える可能性が出てくるつか、なんども煮え湯を飲まされたf(x) ? true : falseは見ての通り冗長だが、間違えようがない他人に見せないときは好きにしろ
!!って人生で10回も使った事無いと思うが、!!と!見間違えるか？見間違えるか、そうなのか。そうかもしれないな。まあ実際そんなに褒められた書き方じゃないと思ってるしな。
とはいえ ? true : falseは個人的には!!よりかなり許せないレベルなんだが、boolean型がある言語ならそれへのキャストなり変換関数なりがあるんじゃないかな。
一般論だが、間違えて思い込んでしまうと、そこから自力で抜け出すのは非常に難しい「！！」を実際に使う機会はおっしゃる通り少ないから、ロジックをあらかじめ知っていればともかく、他人のコードの「！！」は見間違えがちだそうなると、そこ「以外」を切り刻んで、最後の最後に「もしや…上様」となってしまう
俺も好きか嫌いかで言えば、?true:falseは好きではない何も計算していないからなしかし、止めてくれというほどの理由もないし、
return b*b-4*a*c >= 0 ? true ; false; は、素直に「ｂかけるｂひく４かけるａかけるｃが0以上の『とき』に、真を返す」と読み下せるが
return b*b-4*a*c
return !!f(x)
書き手の意図は汲み取れるから怒りはしないけど、その式が条件式(=真偽の値を返す)であると認識しているから三項演算の条件に使っているのに、真のときにtrue、偽の時にfalse と書くのはやはり冗長には感じるな。
何を重視するかによる。実行パフォーマンスにシビアな環境で前者の方が実行効率良けりゃそう書くこともあり得るよ。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
目玉の数さえ十分あれば、どんなバグも深刻ではない -- Eric Raymond
発端? (スコア:3, 参考になる)
きっかけはこのおもしろい(オブラートに包んだ表現)ツイートではないかな
https://twitter.com/fnya/status/1192036095820615680 [twitter.com]
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: (スコア:0)
TokusiN @toku51n 11月6日
返信先: @fnyaさん
trueとの比較は危険なのでやってはいけない。もしどうしてもbool型との比較が必要なのであれば!=falseにしなければいけない。
1件の返信 2件のリツイート 10 いいね
昔の C で bool 型を整数型の typedef とかでやってた頃の話じゃね?
C99 以降の stdbool.h 使ってる分には true との比較になんか問題あるかなあ??
Re: (スコア:0)
ダメ
_Bool は暗黙のキャストにおいて優先度が一番低いから、その手の比較に関しての問題は_Boolが無かった時代とまったく同じ。
Re: (スコア:0)
https://twitter.com/toku51n/status/1192100468144521216 [twitter.com] の流れの話だと思うけども、
_Boolの変数に対して
if (変数 == true) {}
したとして、「_Bool は暗黙のキャストにおいて優先度が一番低い」という話がなんで出てくるのかがまずわからん
Re: (スコア:0)
みんな分かってると思うけど補足。
!= false と書くべきって理由は、false 、true は値としては 0 、1 になるってところ。
そこに 2 とか 3 とかの値が来たときにどう動くのか、それを考えろってこと。
0 、1 以外は想定外？ それならそれを保証しろ、と。ドキュメントとか assert() とかでも良いけど、実環境の実行時には無力。
あと、ツイートの「条件式だけで動作する」ってやつは「式の値」だと思うけど、C 特有で分かりにくいとは思う。「副作用」もあるだろうし。
Re: (スコア:0)
!= false と書くべきって理由は、false 、true は値としては 0 、1 になるってところ。
そこに 2 とか 3 とかの値が来たときにどう動くのか、それを考えろってこと。
0 、1 以外は想定外？ それならそれを保証しろ、と。ドキュメントとか assert() とかでも良いけど、実環境の実行時には無力。
_Bool は 0 か 1 以外の値取り様ないだろアホか
Re:発端? (スコア:1)
これ重要な指摘かと。
プログラマたるもの鼻から悪魔を出させるようなことはしたくないにちがいないのですが、だいたいの処理系の鼻には悪魔がたくさん住み着いているので。
Re: (スコア:0)
マが読みやすい読みにくいと言う場合は大抵認知的負荷に関する発言だから個人の感性の問題ではないよ。
ただ、計算機科学やソフトウェア工学の分野の人間は認知科学に関する知識が絶望的に足りてないから他分野とは言え知らなすぎると言うのは問題だろうね。
計算機科学やソフトウェア工学の人間に「お前らが普段から言ってるクラスだの何だのも認知科学とか存在論とかオントロジーとかと領域被ってんぞ」って言っても理解され難いし。
>危険というのは、PHPやJavaScriptでオブジェクトがtrue判定されることですか？
はまあ、アレよ。
真偽値が抽象化されてて（真偽値型がある）真偽値の生の表現に変換できない言語しか触ったこと無いんじゃないの？
boolean型やtrue/falseの定義を気にしなくていい言語。
Re: (スコア:0)
それでは、? true : false の有無による認知的負荷の違いについて、認知科学の立場から説明して下さい。
Re: (スコア:0)
if ( (a == b) == true )
みたいなのはコード引き取ると良くある…
Re:発端? (スコア:1)
if (!Foo()) { ... }
って書きたいけど、「!」の視認性が悪いから、
if (Foo() == false) { ... }
としてるんだという意見に対して、
if (!!!Foo()) { ... }
のように奇数個の「!」を気の済むまで書けばいいじゃんていう話好き
# そして間違って偶数個の！を書いてしまうまでがブック
Re: (スコア:0)
if (!Foo()) { ... }
って書きたいけど、「!」の視認性が悪いから、
#define NOT !
if (NOT Foo()) { ... }
プロはこう書く(書かない)
Re: (スコア:0)
プロなら規格で用意されているnotを使う。
実際、C++の商用コードで見かけたことはある。
Re: (スコア:0)
if ( ( a b) != false ) じゃなかっただけありがたいと思うんだ。
Re: (スコア:0)
いらんだろと消してあげても、すぐに復活する
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); とする方が
評価式を返してるのがより明らかに思えるけどなあ。
Re: (スコア:0)
自分が書くのにどちらがよいかではなく、他人が書いたのに怒るかどうか、許容できるかどうかの話をしているのです
プログラマーは論理思考ができないのか
Re: (スコア:0)
「怒る」「許容できる」なんて主観的な基準を論じてるんだから「自分が書くのにどちらがよいか」の話だろ
お前の論理思考では何がどう違うんだ
Re: (スコア:0)
これはコードレビューの話だから、怒るとか許容できないというのは自分一人だけの問題ではなく、チームの総意である
「おまえはこんな書き方はやめろ」と禁止するなら、禁止する理由が必要だ
和ゴミを嫌っていても、禁止する理由がなければ禁止できないのと同じだ
俺の書き込みはそのチームの一員と仮定してだした意見であり、個人的に好む書き方とは限らない
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: (スコア:0)
暗黙的な型変換は全てが気持ちが悪いということでしょうか？
そうでなければ、なぜ気持ちが悪いか説明が必要だと思いますが。
Re: (スコア:0)
C99で導入されたbool(_Bool)では、false/trueはintなので、
仕様としては stdbool.h に定義されてるのは論理型 bool と論理値 true と false だからそれを使うべきだよ。
Re: (スコア:0)
暗黙の型変換がいやだというなら、明示的に型キャストすればいいだけ。
キャストの危険性認識してない奴がなんか言ってらぁｗ
Re:発端? (スコア:1)
C99では、
_Bool型が新たに作られた。0と1しか値をとらない、intとは別の型
stdbool.hで、bool は _Boolと定義されている。
stdbool.hで、true/falseは、1/0と定義されている。int型の定数。
なので、「bool a = true;」とかやっても、intから_Boolへの暗黙の型変換が行われる、という話ですよ。
Re: (スコア:0)
stdbool.h に定義されてる true と false は論理値として用意されてるものなので bool のオブジェクトに代入するのは安心してできますね。
対して、算術演算の結果が 0 や 1 になるからといって 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)
C99で導入されたbool(_Bool)では、false/trueはintなので、結局三項演算子を使ってtrue/falseにしても、_Boolへの暗黙の型変換は行われてしいますよ。
C99のstdbool.hは妥協の上での折衷案ですが、再定義も認められているのでそうすれば済む話ですね。
#include <stdbool.h>
#ifdef true
#undef true
#endif
#define true ((_Bool)1)
#ifdef false
#undef false
#endif
#define false ((_Bool)0)
Re: (スコア:0)
という言語仕様でも不安がなくならないって、強迫神経症か何かなの？
Re: (スコア:0)
こんな再定義こそ「気持ち悪い」と言うのでは？
Re: (スコア:0)
otherwise, the result is 1.
int hoge(int i)
{
bool b = i;
return b == i;
}
が常に 1 返す保証でもない限りはスカラ値から論理型への変換は避けるべき。
Re: (スコア:0)
ごめん、その保証がないと何が不安なの？
Re: (スコア:0)
あんたでもtrueとfalseのかわりに全部1と0で書いてあるコードや、変数名がぜんぶ連番のコードを読まされたら怒るだろ？
プログラミング言語の意味論と、人間にどう見えるかは全然別の話だよ
プログラミング脳になっちゃってるのか、頭が悪いやつはごっちゃにしてるけどな
Re: (スコア:0)
味噌も糞も一緒な人に説明する意味がどれだけあるやら
Re: (スコア:0)
そこは
が様式美じゃない？
ゼロやnullじゃないってのはコメントがないとぱっと見では分からないけど、!!は瞬時にわかるしよく見かける(気がする)。
Re: (スコア:0)
!!は二重否定だからプログラミング言語の意味論以外には、トートロジーでしかない
プログラム上にトートロジーがあるとは普通は思わないから、これを!一つと見間違える可能性が出てくる
つか、なんども煮え湯を飲まされた
f(x) ? true : falseは見ての通り冗長だが、間違えようがない
他人に見せないときは好きにしろ
Re: (スコア:0)
!!って人生で10回も使った事無いと思うが、!!と!見間違えるか？
見間違えるか、そうなのか。そうかもしれないな。まあ実際そんなに褒められた書き方じゃないと思ってるしな。
とはいえ ? true : falseは個人的には!!よりかなり許せないレベルなんだが、
boolean型がある言語ならそれへのキャストなり変換関数なりがあるんじゃないかな。
Re: (スコア:0)
一般論だが、間違えて思い込んでしまうと、そこから自力で抜け出すのは非常に難しい
「！！」を実際に使う機会はおっしゃる通り少ないから、ロジックをあらかじめ知っていればともかく、他人のコードの「！！」は見間違えがちだ
そうなると、そこ「以外」を切り刻んで、最後の最後に「もしや…上様」となってしまう
俺も好きか嫌いかで言えば、?true:falseは好きではない
何も計算していないからな
しかし、止めてくれというほどの理由もないし、
return b*b-4*a*c >= 0 ? true ; false;
は、素直に「ｂかけるｂひく４かけるａかけるｃが0以上の『とき』に、真を返す」と読み下せるが
return b*b-4*a*c
Re: (スコア:0)
return !!f(x)
Re: (スコア:0)
書き手の意図は汲み取れるから怒りはしないけど、
その式が条件式(=真偽の値を返す)であると認識しているから三項演算の条件に使っているのに、
真のときにtrue、偽の時にfalse と書くのはやはり冗長には感じるな。
Re: (スコア:0)
return (条件)? true : false; なんて書くくらいなら return 条件; だよなあ
そりゃレビューで落とすでしょ感
何を重視するかによる。
実行パフォーマンスにシビアな環境で前者の方が実行効率良けりゃそう書くこともあり得るよ。