Q&A
数値が同じとき、どのような出力をしたいのでしょうか？（何も出力しない、など）
Pythonで関数を使って二つの数を比べて小さい方を出力したいです。小さい方を出力することはできたのですが、数字が同じときの処理に困っています。
Python
1def getMinimum(a,b): 2 if a<b: 3 return a 4 elif b<a: 5 return b 6 7A=getMinimum(10,15) 8print("最小値は"+str(A)+"です。")
if A=None:と書くとエラーが出てしまいます。解決方法を教えてください。
回答1件
0
ベストアンサー
if A = None: を if A == None: にすれば動作するでしょう。
if A is None: だとなお良いです。
あるいは関数の最終行に return a などと書いても良いでしょう。
この場合呼び出し元には値が同じだと伝わりませんが、最小値が返っていることに違いないです。
投稿2021/04/21 13:39
編集2021/04/21 13:42
総合スコア35660
できました！ありがとうございます！
関数名がgetMinimumなのだからreturnの方が良い気がします
命名と役割が一致しないのは良くない
同一値の場合に小さい方を判定出来ない関数なら、getLowerとかで許容じゃないかな
choiceLowerだと同一値の時、選べない感じがしていいんじゃないでしょうか
でもchoiceなんて使わないからfindの方が良い？
> 関数名がgetMinimumなのだからreturnの方が良い気がします
私もreturnの方が使い良いと思います。
関数名というより、 f(1, f(2, 2)) と f(f(1, 2), 2) の結果が異なるのは嫌だな、と。
>関数名というより、 f(1, f(2, 2)) と f(f(1, 2), 2)の結果が異なるのは嫌だな
(１/2)/2 と 1/(2/2)は結果が異なるように、それは気にすることじゃないと思ったです。
ただ、関数名がgetMinimumなのだったらf(1, f(2, 2)) と f(f(1, 2), 2)の結果は一致すべきだと思います。
推移性（結合法則）が成立する処理名だと思うので。
結局、関数名だと私は思うです。しつこいですが。
関数名でgetMinimumとなってるのに、中身は「最小値の取得」ではなく
「小さい方を取得。値が同じ場合にはNoneを返す」という処理だと
名前だけで判断できず、実装を確認しないといけない。
いや名前だけで判断できるはずの関数名になっているのに
実は名前だけでは判断できない関数というとても悪い関数だと思います。
特別英語に強いわけでは無いですが、mininumとlowerで意味の差をくみ取るのは難しいように思います。
何らかの事情があってNoneを返す関数を組むなら、ret_smaller_if_possible とか私なら命名するかもです。『possibleじゃないときは何を返すのかな？』と確認を促す期待も込めて。
＞mininumとlowerで意味の差をくみ取るのは難しいように思います。
getmininum? それなら似たようなものですね。
ただ、そうではなく今回の関数名はgetminimumです
minimumは最小なので必ず値の結果があります。その為確実にまずいです。
他の名前だと何が良いかは、よくわからないですね。
必ず値を戻す。という意味が含まれていないなら、何でもいいと思います。
ただ、代替案を出さないのは如何なものか、と思いましたので
必ず値を戻すという意味が含まれていなさそうなのを提示したつもりです。
「差をくみ取るのは難しいように思います。」と言いますが
lowerが必ず値が取得できるという意味が含まれていますか？
None以外が引数の場合のgetMinumumで値を返さない時がある。と言うのは
極端に言うと、getMaxと言う名前で小さい方を返す。と言うのと似たような側面がある。という事です。
minimumなら値を返すべき、lowerなら返らないこともある、という感覚はいまいち分かりません。
私の感覚だとminimumもlowerもsmallerも表現力に大して差が無いように思いますので、
もし命名するなら ret_smaller_if_possible とか文的な表現にするとの意見でした。
私の英語力不足なのかもしれませんが、判断材料が無い分には何とも言い難いです。
（後でまとめて記述しました）
設計のまずさを補うために命名を工夫する必要が生じていて、
なぜ設計が悪いかと言うと結合の向きに依って結果が変わるから、との考えです。
命名は悪くないと言っているわけでなく、命名以上にまずい部分を先に何とかすべきかと思って書いています。極端な話、関数名がfuncだろうとaだろうとhogeだろうと、先に修正すべきは名前ではなく設計です。
...との個人的意見です。
＞もし命名するなら ret_smaller_if_possible とか文的な表現にするとの意見でした。
その部分は一切否定していません。なんでもいいと言ったではないですか。
代替案としていいと思いますよ。
＞「minimumなら値を返すべき、lowerなら返らないこともある、という感覚はいまいち分かりません。」
なるほど。最小値というのは、必ず存在するものです。覚えておいてください。
https://nekodamashi-math.blog.ss-blog.jp/2015-12-04
lowerが必ずあるという意味があるかどうかは、私は正確には理解していません。
もし必ずあるという意味を持つなら私の代替案は不適切だったとなりますが
まぁ。必ずあるという意味を持つなら、それを教えてください。
＞設計のまずさを補うために命名を工夫する必要が生じていて、
＞なぜ設計が悪いかと言うと結合の向きに依って結果が変わるから、との考えです。
「結合の向きに依って結果が変わるから設計が悪い」というのは
(1/2)/2 と 1/(2/2)という普通の処理があるように間違いである。と指摘したつもりです。
＞命名以上にまずい部分を先に何とかすべきかと思って書いています。
＞極端な話、関数名がfuncだろうとaだろうとhogeだろうと、先に修正すべきは名前ではなく設計です。
＞...との個人的意見です。
質問に提示しただけの範囲で、設計に問題があるとまでは思えません。
名前に設計の意図が含まれていると解釈した場合には、問題があると言えるかと思います。
この質問文に記載された程度で、設計が悪いという根拠は何ですか？
関数名は関係なしに根拠があるというなら提示してください。
推移性（結合法則）が成立しないから悪い設計というのは間違っています。
ん？ f(1,f(2,2))は、この関数だとエラーになりますね。
まぁ。どうでもいいことですね。
私の意見を以下に記します。
minimumの場合、1と1が要素だと、結果は 1 になります。
なのにNoneを返す。と言うのは関数名的におかしいい。という指摘と
推移性が成立しないから、良くない。と言うのは
関数名を加味しないなら、誤りである。という指摘の２点です。
まず、『一番小さい数を求めること』は、『二つの数のうち、小さい数を求める』ことの繰り返しだという点はご理解いただけるでしょうか。
その観点では return reduce(関数, [2, 2, 1]) が最小値1を返さない時点で設計は破綻しています。
また、minimumとlowerの違いについても明確な説明をいただきたいです。私はminimumもlowerも良くないと主張しているわけですから、minimumが悪い命名だとご教示いただいたところで意見に変わりは生じ得ません。
また、私は『関数名は一切どうでも良い、判断基準にならない』と主張しているわけではなく、
『関数名より先に改善すべきことがある』と言っています。
>まず、『一番小さい数を求めること』は、『二つの数のうち、小さい数を求める』ことの繰り返しだという点はご理解いただけるでしょうか。
では、質問の関数が『一番小さい数を求めるもの』という設計であるという理由は何ですか？
「二つの数を比べて小さい方を出力したいです。」「（同じときは）比較できませんと出力したかったです」ということが質問とコメントに記載されています。
「一番小さい数を求める」という関数であるとは関数名を除いては一言も言っていません。
っていうか「一番小さい数を求める」ってなんの話ですか？どこから出てきたんですか？
＞minimumとlowerの違いについても明確な説明をいただきたいです。
＞私はminimumもlowerも良くないと主張しているわけですから、
＞minimumが悪い命名だとご教示いただいたところで意見に変わりは生じ得ません。
なるほど。lowerは、代替案の提示です。
貴方が許容できないというのであれば、気にしないでください。
気にしないなんて出来ないというのであれば、貴方が調べてください。
私は、貴方がlowerを許容できないというのであれば「そうでしたか。感覚の相違ですね」で、すむ話だと思っています。
質問文以上の条件が分からない以上、ひょっとしたらNoneを返すのが非常に優れた設計なのかもしれません。しかし判断基準が無いので、機能をより汎化することを優先して考えます。
活用しやすいかしづらいかで設計の良し悪しを判断するのは普通だと思います。結合度を下げ、強度を上げます。
目的が達成できればそれでオーケーではなく、その先の話をしています。計算結果が正しいことが良い設計の証左になるのなら、それこそ関数名などどうでも良いという話になります。
xail2222さんがminimumの数学的な原義を重視するわりに、関数の数学的な妥当性を軽視する動機が分かりません。
>機能をより汎化
その元々の機能は、何なのですか？名前から判断した「一番小さい数を求める」と言うものではないのですか？
凡化したのが「一番小さい数を求める」と言うのであれば、なぜこの関数の特徴であるNoneを返す点を無くしても良い特徴と考えたのでしょうか
＞活用しやすいかしづらいかで設計の良し悪しを判断するのは普通だと思います。結合度を下げ、強度を上げます。
であれば「あるいは関数の最終行に return a などと書いても良いでしょう。
この場合呼び出し元には値が同じだと伝わりませんが、最小値が返っていることに違いないです。」というのは如何なものでしょうか。
「return aでもよいでしょう。」ではなく、「return aであるべき」となりませんか？
また「最小値が返っていることに違いないです。」と言う部分ですが、なぜ最小値と考えたのでしょうか。
関数名以外に最小値という条件は無いですよ？
＞xail2222さんがminimumの数学的な原義を重視するわりに
＞関数の数学的な妥当性を軽視する動機が分かりません。
妥当性？どういうことですか？
関数名からすると、妥当ではない。というのは分かりますが
関数名を加味しなければ、推移性がなくても妥当であると思いますよ。
関数名がなければ、「一番小さい数を求める」というものだという理由はありませんから、推移性を持たせて結合度を下げ、強度を上げた方がいいとは思いません。
関数名がminimumなので、推移性を持たせる必要があるとは思いますけどね。
あくまで関数名が根拠になります。
もしかして割り算を悪い設計だとでもいう気ですか？
私は割り算を悪い設計だと否定する気はありませんので
「推移性を持たせた方が扱いやすいから、割り算の機能を変えた方が良い。」とは思いません。
割り算、あっても良いんじゃないですか？
いや、無いとだめでしょう。
今回の関数もこれと同じです。
推移性が無いから良くないとは、安易に言うべきじゃないと思いますよ
ですから、私は『関数名は一切考慮しない』と言っているわけではなく、『他の改善点より優先していない』と述べています。
あと割り算の話は全く反論になっていないです。演算の種類によって特徴が違うのは当たり前です。
『小さな数を求める演算には結合性があるべき』という意見を、『あらゆる演算には結合性があるべき』だと拡大解釈しないで下さい。
＞私は『関数名は一切考慮しない』と言っているわけではなく、
＞『他の改善点より優先していない』と述べています。
他の改善点の根拠が、関数名に依っていないですか？
と指摘しているのですが。
＞演算の種類によって特徴が違うのは当たり前です。
はい。そうですね。
＞『小さな数を求める演算には結合性があるべき』という意見を
質問の関数はただの小さな数を求める関数ではありません。
同じ値の時にNoneを返す。と言った特性を持った関数です。
その特性をなくすべきだという根拠は何ですか？と確認しています。
根拠が関数名に依っていないですか？
と指摘しているのです。
関数名に依らないのであれば
『あらゆる演算には結合性があるべき』と言っているのと同じですよ。
と指摘しているのです。
① 説明文や実装を元に仕様を把握します。
② 暫定的対症療法的な対策を考えます。この時点で回答は可能です。
③ 設計と関数名の両方に問題があると判断します。
④ 設計を優先して直すべきと考えます。
私が関数名は優先されないと言っているのは④です。①の段階で無視はしていないです。
何回も『関数名より先に設計を直すべき』と言っています。『仕様を把握するときに関数名を無視しても良い』とは言っていません。
割り算の件もそうですが、私が主張していないことに対して反論をされても困ります。
＞私が関数名は優先されないと言っているのは④です。①の段階で無視はしていないです。
＞何回も『関数名より先に設計を直すべき』と言っています。
＞『仕様を把握するときに関数名を無視しても良い』とは言っていません。
ん？ 私の意見は関数名の方を先に直すべき。という意見ではありません。
今の仕様であれば、別の名前の方が良いという意見です。
また
「関数名というより、 f(1, f(2, 2)) と f(f(1, 2), 2) の結果が異なるのは嫌だな、と」
という見解で
「説明文や実装を元に仕様を把握します。この段階で（関数名を）無視はしていないです。」
というのはおかしいでしょう。
「関数名というより」ではなく「今の関数名だからこそ」そのような見解になるんじゃないですか？
という私の指摘通りだと思いますが。
＞割り算の件もそうですが、私が主張していないことに対して反論をされても困ります。
「今の関数名だからこそ」というのであれば、割り算の件とは違いますが
「関数名というより」と言っているのだから、割り算の件と同じと言っているのです。
『関数名と言うより』を、『関数名を無視して』と読み替えるのはどうしてでしょうか。
『関数名も問題あるけれど、それ以上に』という意味で書いているのですが。
『ごはんよりパンが好きです』と聞いたとき、『この人はごはんが嫌いなのだな』と解釈するのですか。
一度先入観をなくして考えてみてください。
回答を洗練するためにコメントしているのか、私を言い破るためにコメントしているのか、目的を見失っていませんか。
日本語の言い方の問題に帰着するのは明らかにおかしいです。そんな表面的な議論をする気は無いです。
返信がないようなので、まとめとして修正します。
（１）
このコメント欄は「回答を洗練するため」だけにあるとは私は考えていません。
このコメント欄に書かれた意見に対するコメントも含まれていると考えています。
（２）
関数名単独では問題などありません。
処理単独でも今回の場合問題ありません。
二つが矛盾しているのが問題なんです。
そしてキーとなっているのは、関数名です。
「関数名というより、 f(1, f(2, 2)) と f(f(1, 2), 2) の結果が異なるのは嫌だな、と」
「『関数名も問題あるけれど、それ以上に』という意味で書いているのですが。」
関数名であればこそ必要な性質「f(1, f(2, 2)) ＝f(f(1, 2), 2) 」を
関数名よりも問題と言っているので、論理的におかしい。
（３）
日本語で表現している文章なのだから、指摘される場所は
日本語の文章です。当たり前です。
表面にあらわれる文章を指摘されたから、表面的な議論だと
解釈するのは、間違いです。
今回の質問の回答としては、コメントを合わせて
『if A = None: を if A == None: にすれば動作するでしょう。
if A is None: だとなお良いです。』
がベストアンサーとして正しいでしょう。
『あるいは関数の最終行に return a などと書いても良いでしょう。
この場合呼び出し元には値が同じだと伝わりませんが、最小値が返っていることに違いないです。』
これは『比較できませんと出力したかったです』という要件を満たしていませんから、間違った提案です。
しかし、今回の質問に出てくる関数には
関数名と処理の内容があっていない。という問題があります。
今回の質問の主旨には含まれません。
その問題点の改善という趣旨では、言い方は問題ありますが妥当な提案です。
そして、コメントの後付けの理由が、特におかしな内容になってしまってる。ってことですね。
ですから、『関数名を完全に無視』などしていません。
私の言いたいことは 2021/04/23 23:24 のコメントに集約しているので、それ以降のコメントはxail2222さんの読解力に合わせて補足しているのだと理解して下さい。
私は命名がまずいと主張しているわけではありません。
関数名と処理内容の不一致が問題であると言っています。
関数名を処理内容に合せるか、処理内容を関数名に合せるか
どちらかを行った方がよい。という見解です。
命名の方を変更すべきという意見ではないですし
処理の方を変更すべきという意見でもありません。
さて、それに対して。
＞③ 設計と関数名の両方に問題があると判断します。
＞④ 設計を優先して直すべきと考えます。
＞命名は悪くないと言っているわけでなく
＞命名以上にまずい部分を先に何とかすべきかと思って書いています。
どこが食い違っているかわかるでしょうか。
わからないなら、わかるように説明できるように頑張ります。
あと、やっぱりここですね。
＞関数名というより、 f(1, f(2, 2)) と f(f(1, 2), 2) の結果が異なるのは嫌だな、と。
関数名が「f(1, f(2, 2)) ＝f(f(1, 2), 2)」となるべき根拠になっているのに
「関数名というより」と、比較の対象として持ち出している時点で論理的におかしいです。
この論理的におかしいという点を説明するのに苦労しているんですよねぇ。
どうしたものでしょうか。
んー。関数名を前提にした状態であれば、そこで関数名の修正なんてありえないんです。
論理の前提条件を、論理の帰結で否定している状態ですので、矛盾な思考といえるでしょう。
関数名を前提にしたら、関数名の修正よりも先に設計を直すべきとなるのは明らかな話です。
だって、関数名の修正という事自体が前提を覆すことですので。
ですから「関数名というより」という言い方がおかしいわけです。
「関数名も問題あるけれど、それ以上に」の方が更におかしいです。
貴方の言うように、読解力の問題でしょうか、私の表現力の問題でしょうか。
レビューをする際には、本人の説明、関数名などメタな情報、実装、その他から複合的に判断します。
関数名を一切気にしていない、実は気にしている、そのような二元論に持ち込むのはおそらくxail2222さんの悪い癖です。過程に拘り過ぎです。
そもそも 2021/04/24 12:55 のコメントで、仕様を把握するときに関数名を無視していないと明記しているじゃ無いですか。
書いていることを読んで下さい。書いていないことに反論するのでは無く。
＞関数名を一切気にしていない、実は気にしている、
＞そのような二元論に持ち込むのはおそらくxail2222さんの悪い癖です。
＞過程に拘り過ぎです。
んー。そんな二元論に持ち込んだ記憶はないのですが…
＞仕様を把握するときに関数名を無視していないと明記しているじゃ
＞無いですか。書いていることを読んで下さい。
＞書いていないことに反論するのでは無く。
私はLouiS0616さんが関数名を無視しているから問題だと指摘しているわけではありません。
「この質問文に記載された程度で、設計が悪いという根拠は何ですか？
関数名は関係なしに根拠があるというなら提示してください。」
ここが誤解を与えたのでしょうか。
LouiS0616さんが「関数名というより、 f(1, f(2, 2)) と f(f(1, 2), 2) の結果が異なるのは嫌だな」とおっしゃったので
「f(1, f(2, 2)) = f(f(1, 2), 2)であるべき 」という見解が関数名を根拠としていないと判断しました。
しかし、前提としていた。というのであれば、それは了解しました。
「この質問文に記載された程度で、設計が悪いという根拠は何ですか？
関数名は関係なしに根拠があるというなら提示してください。」
というのは撤回します。
そして、関数名を前提としていたというのであれば
「関数名というより、 f(1, f(2, 2)) と f(f(1, 2), 2) の結果が異なるのは嫌だな」
と言うのは論理的におかしくなりますよ。と指摘しているんですが
わかりますか？
このおかしくなる点については2021/04/25 19:38のコメントに記載してあります。
2021/04/24 00:52 で書いたとおり、選択する余地があるならばより汎用的な設計を選ぶのが普通です。
汎用的な部品を使って特殊なロジックを組むのは簡単ですが、その逆は難しいからです。
＞選択する余地があるならばより汎用的な設計を選ぶのが普通です。
＞汎用的な部品を使って特殊なロジックを組むのは簡単ですが、
＞その逆は難しいからです。
そうですね。異論はありません。そこを問題視はしておりません。
その理由として
「関数名というより、 f(1, f(2, 2)) と f(f(1, 2), 2) の結果が異なるのは嫌だな」
と言い出すから、いやいやいや。それはおかしいでしょう。となるのです。
私は「関数名の方の変更の方が大事だろ」と言っているわけではありませんよ？
「関数名を問題視していないからよくない」と言っているわけでもありません。
結合則を満たす方が、より汎用的に活用できます。その実例として出したのが 2021/04/24 00:31 に挙げた例です。
まず「結合側を満たす方が良い」を問題視しているわけではありません。
だって、私の一番初めのコメントは「return aの方がよい」ですよ？
その根拠の中には「結合側を満たす方が良い」も含まれると言えるでしょう。
しかし、それは名前がgetMinimumとなっているから
「結合側を満たすべき関数」となるんじゃないですか？と指摘していました。
関数名の方を先に直すべきとか言う話ではありませんよ。
Noneを返す実装を維持する場合、私は getMinimum も getLower も不適だと思いますし、
aを返す実装に変更する場合、そのどちらでも良いと思います。
2021/04/24 00:31 のコメントに対し、xail2222さんは 『では、質問の関数が『一番小さい数を求めるもの』という設計であるという理由は何ですか？』と返していますが、2021/04/25 20:14 のコメントでは『（選択する余地があるならばより汎用的な設計を選ぶことに）異論はありません』と書いています。
意見が変わったとの認識で良いですか？
＞Noneを返す実装を維持する場合、私は getMinimum も getLower も不適だと思いますし、
こちらは、異論がありますが、見解の相違として置いておきます。
私の見解としても意味は矛盾しないかなということでgetLower は許容なだけです。
＞aを返す実装に変更する場合、そのどちらでも良いと思います。
これには同意です。
＞ 『では、質問の関数が『一番小さい数を求めるもの』という設計であるという理由は何ですか？』と返していますが
＞2021/04/25 20:14 のコメントでは『（選択する余地があるならばより汎用的な設計を選ぶことに）異論はありません』と書いています。
＞意見が変わったとの認識で良いですか？
その二つの発言を取り上げる理由がいまいち理解できませんが
とりあえず、意見は変わっていませんよ。
『では、質問の関数が『一番小さい数を求めるもの』という設計であるという理由は何ですか？』
という質問は、関数名を根拠に持ってきていない。と解釈したからこその質問です。
関数名を根拠に持ってきている。と回答があったので、解決した質問であると考えています。
私のLouiS0616さんの意見への指摘は
「関数名というより、 f(1, f(2, 2)) と f(f(1, 2), 2) の結果が異なるのは嫌だな、と。」
というコメントが論理的におかしいという指摘です。
「関数名の修正よりも、処理内容の変更の方が妥当である。」
という意味であるならば、同意になりますが
そのコメントがつけられた私のコメント内容は
「関数名がgetMinimumなのだからreturnの方が良い気がします
命名と役割が一致しないのは良くない
同一値の場合に小さい方を判定出来ない関数なら、getLowerとかで許容じゃないかな
choiceLowerだと同一値の時、選べない感じがしていいんじゃないでしょうか
でもchoiceなんて使わないからfindの方が良い？」
です。
「関数名の変更をすべきだ」というコメントではありません。
関数名の変更をすべきだと言っているようにしか読めないですか？
関数名に処理内容を合わせるべきだ。というのが一番目の見解としてあり
処理内容に関数名を合わせるのであれば、こんなのかな。という提案です。
ですから「関数名というより」と返されたので、まさか「関数名の修正よりも」と言っているとは思わず
「関数名だからこそでしょう」と返したのです。
何度も繰り返しになりますが、私は関数名が問題だと言っているわけではありません。
5行中3行で別の関数名について言及しているのに、『関数名の変更をすべきだ、との意見ではない』との主張には無理があります。
また、実装を変えるべきとの点で同意があったのなら、逆に『なぜ実装を変えるべきか』との理由が見当たりません。まさかとは思いますが、関数名に合わせる以外の理由は無かったのですか？
＞5行中3行で別の関数名について言及しているのに、
＞『関数名の変更をすべきだ、との意見ではない』との主張には無理があります。
まず、その文中に「命名と役割が一致しないのは良くない」と記載があります。
そして、命名に処理を合わせるなら、return
処理に命名を合わせるなら、色々。と言う内容です。
LouiS0616さんが誤解したという事は了解しました。
しかし、私は何度も言っていますが「不整合を問題にしている。」と言ってきたはずですよ。
＞実装を変えるべきとの点で同意があったのなら、逆に『なぜ実装を変えるべきか』との理由が見当たりません。
＞まさかとは思いますが、関数名に合わせる以外の理由は無かったのですか？
「実装を変えるべきとの点で同意理由」ですか？
そうですね。関数名だけが理由にはなりえません。
私の見解は「関数名と処理内容の不整合が問題」との立場ですから
関数名の方をただ優先すべきであるとは思いません。
また、関数名から必要であると導かれる推移性の要請は
関数名に由来することですから、
LouiS0616さんの意見は、関数名に合わせる以外の理由は無かったという事だと思います。自分でまさかと思う理由をつかってるわけですが自覚できますか？
対して、私の意見の理由は、関数名と処理内容どちらを維持すべきかとしたときに、関数名の維持を取る。というものです。
問われたので、今初めてその理由を説明しますが
なぜなら、処理内容は同じ値の時にNoneを返す関数が必要になる状況が分りませんでしたし同じ値の時に「比較できません」と言っているのも、意味が分からなかったからです。
同じ値であるという結果も、比較した結果なのだから比較できているだろう。と
というように、よくわからない処理より明記されている関数名ということで、関数名の維持を選択したわけです。
大した理由じゃないですけどね。
そして、関数名の維持には「結合側を満たす方が良い」は含まれますから
「結合側を満たす方が良い」には同意となるわけです。
今までかなり誤解をさせてしまったようですが、わかりますでしょうか？
最終的に実装と関数名が呼応すべき、これは当然合意できるでしょう。
しかしこれは、まず仕様（あるいは役割）があって、仕様を満たすように実装され、役割を表すように関数が命名され、結果的に揃っているに過ぎません。
実装に合わせて関数名を変更するのはもちろん、関数名に合わせて実装を変更するのも本末転倒です。木を見て森を見ずとはまさにこのことです。
一つ一つの関数の設計書をいちいち作らないとしても、設計と実現のレイヤは分かれています。
MinimumとかLowerとかgetとかfindとか他人に通じるか分からない微妙なニュアンスの付与に腐心するのはずっと後です。
仕様のレイヤの議論でやたら関数名について聞いてくるので不思議だったのですが、そこを区別できていなかったということなんでしょう。きっと。
仕様は、質問文で完全には表現されていません。
その仕様を第三者が勝手にこういう風な仕様であるべき。と言うのは、如何なものか。と私は考えています。
その観点であれば「推移性を持つべき」との見解は、まさに行き過ぎたものだと思います。
割り算、引き算という例もあるように「推移性」は持たなくてもよいものです。
ただ、関数名がgetMinimumだからこそ、想定されるあるべき仕様という意味では「推移性を持つべき」となるだけです。
関数名を根拠にしている事に変わりはないのですよ。
仕様のレイヤの議論であったとしても、材料につかってるのは関数名ですよね。ということです。
＞仕様のレイヤの議論でやたら関数名について聞いてくるので不思議だったのですが
＞そこを区別できていなかったということなんでしょう。きっと。
疑問を持ったのであれば解釈に誤りがあるのでは。と考えるべきですよ。
LouiS0616さんの誤解によるコメントから関数名についてを何度もいう事になったのですから。
何度も言いますが、私は関数名を問題視しているわけではありません。
それなら『仕様が明確でないので何とも言えない』で終わりじゃないですか。なぜ割り算の話とかで仕様レベルの反論があったのか理解できません。
反論するための反論には価値がありません。
>それなら『仕様が明確でないので何とも言えない』で終わりじゃないですか。
＞なぜ割り算の話とかで仕様レベルの反論があったのか理解できません。
それはLouiS0616さんの誤解によるコメントと、私の誤解によるコメントの帰結でしょう。
理由が気になるなら、それぞれどのように誤解したかを考えてみていけばいいかと思います。
＞反論するための反論には価値がありません。
何の話ですか？ 何の話か分かりませんが
また誤解して言ってるのでしょうか？
ま。。。「価値がありません」と言っているのだから
何かを批判しているのでしょうか。
理由が明確にはわからないのでなんともいえないですね。
ということでよろしいでしょうか。
ちなみに私の側では、ここでの要対応事項はもう無いと考えています。何か対応が必要なことはありますか？
特に無いです。
以前書いたとおり、私が書くべきことは 2021/04/23 23:24 で述べているので、それ以降のコメントはただのノイズです。
傾いた家を目の前にして、その家の表札のデザインについて議論する趣味は無いですし、ましてや『もともと傾いた家なのかもしれないじゃないですか』なんて言われたらどうしようも無いです。
面白い例えですね。笑ってしまいました。お付き合いありがとうございました。
あなたの回答
tips
プレビュー
