all(empty)==true
@fumieval: 「配列のすべての要素が条件を満たすならtrueを返す」関数を定義するとき、空の配列を渡したらfalseを返すかtrueを返すかが、良いプログラマかどうかの一つの境目だ @fumieval: 「メールのすべての添付ファイルが安全であれば受信箱に入れる」という処理において、添付ファイルのないメールはどうすべきかを考えれば、自然と答えがイメージしやすい @kumagi: 「数学的にこれが自然であるからこうすべきである」と「このプロジェクトの要件は数学の要件に沿っていると俺は勝手に思ってるから数学に寄せた上で異論のあるやつをセンスが無いと罵るべき」の間には海より深い溝があるが気付けない人は居るものである。 @IgnorantCoder: 要件によるとか言ってる人が結構いてビビる。1+1が2かどうかは文脈によるみたいなことばっか言って、一生実装してくれなさそうな気がしてしまうが…。 ・論理で判断できる項目でドキュメントを参照する手間を増やすのは良くないので、状況に拠らないで欲しい
・多くの環境では「全員が論理的に考えられる」と思わない方が良いので、ドキュメントやコメントは気を使うべき
@Cryolite: あなたはプログラミング言語の作者です．その言語の標準ライブラリの「配列のすべての要素が条件を満たす時かつその時に限り true を返す関数 all」と「配列のある要素が条件を満たす時かつその時に限り true を返す関数 any」に空の配列を渡した場合，あなたは以下のように動作するよう実装します： https://gyazo.com/a507fe50693b99f4d99fcad94968ed94
@nishio: anyの定義を「配列の一つ以上の要素が〜」と書くことによって誤解を減らそうとする @3156: この議論でtrue一択でそれ以外は失格とか言ってる猛者たちは普段から標準ライブラリの実装ばかりやってんのかな？ ほとんどのプログラマはアプリケーションレベルで仕事してるんじゃないのか？
客の要望が曖昧な場合は実装前に詳細まで詰めるやろ。
「プログラマ」の主語がでかすぎなのか。
@kis: 客の要望であればそれはビジネスロジックの実装の話であって、「配列がすべての条件を満たせばtrue」とかではなく「カートが出荷条件を満たすか」のような話になると思う。 @kis: あと、結局アプリケーションロジックを作るときにも、数学的な原則を踏まえたビジネスルールにしたほうが堅牢な処理になりがちなので、身体感覚として身についていたほうがいいと思う。 @ito_yusaku: この議論の意見を分けている要因、当人がプログラマとして生まれ育った環境がどうだったかになっている気がするんですよね。正規のプログラミング教育受けた人はたぶんtrue一択。（追加燃料投下） @kazuho: そいえばこれ、「関数の名前はallとかでいいけど、定義に「配列に条件を満たさない要素がひとつもないか否かを返す関数」と書くべき」みたいな主張がないの面白かった。正しさと誤解を産まないことの両立というか @chokudai: 自分がさっきのでtrueを返せと強く主張してるのは、こういう「論理で考えればわかるところで論理に反することをするのって、全体の開発速度の遅延に大きく影響するし、日本の開発力がマジで下がると思ってるから」なんだけど、納得できないなら自分の説明力が足りないのでごめんって感じです＞＜ @nishio: これを別のたとえで説明すると「sumの実装、品物の値段の合計に使うから自動で10%の消費税をつけたらいいと思うんだ！」と言ってる人に対して「いいわけないだろ！！」とつっこんでるみたいな状態なわけです 明らかに汎用処理である要件を、それが実際の要件ではなくなにかビジネス上の具体的な要件をボカしてるに違いないと勝手に決めつけてるから「要件による」って言っちゃうんだよね。
書いてあることを書いてあるとおりに読むかどうかの問題。
@inuro: 責務の切り分けが曖昧なこの手の設計、不幸なことに往々にしてよく目にする。 こういうふうにsumが実装されてしまっているシステムは世の中めちゃくちゃいっぱいあるので、
たとえ話をすればするほど議論は拡散していく気がします。
@nishio: 拡散はしません。例えば「バグってるプログラム」が世の中にたくさんあったとしても「だからバグってる方が正しい」とはならないのと同じです。 これの亜種ですね