やはりお前らの真偽値メソッド名は間違っている。 〜「Xxx できる？」系メソッドの命名〜

英語の正しさを３単元のsまで強制するのは僕は反対です。3単元のsは英語でも間違えやすいものの一つですし変化も一貫性がないので綴り間違いの危険性も増えると思います。それに引数もしくはメソッドを持っているものが配列だったら？となると動詞は受動態以外の変化形を使わないのほうがわかりやすいと思います。

まあ前ふりはこれぐらいにして本題ですが。
静的片付言語ならば返り値は見えているはずなので定義が見やすい状態なら気にする必要はないと思います。
定義と実装の分離ができない言語でメソッドに埋まってしまっているのならどこかに定義部分だけ抜き出したレファレンスを作ればいいと思います。
動的型付け言語で返り値の型がわかりにくくなっているならばシステムハンガリアンを使って型がわかるような記述にする方法があると思います。
昔は脱兎のごとく嫌われたシステムハンガリアンですが型が見えない時には有効な手段だと思います。

インスタンス化を前提としたオブジェクトの場合とモジュールの中のグローバル関数としても意味が変わりますね。
モジュール自体がそれぞれの言語でオブジェクトそのものだったり名前空間だったりいろいろありますが...、

何の言語やチーム間の命名規則などがあるので一概には言えませんが（それをいうと議論になりませんが)。

@kentaro1530

綴り間違いの危険性も増えると思います

仮に綴りの間違っても、それはある意味 isCanXxx と同じような「可愛い間違い」で意図は伝わる分マシです。仮に can do something の可能性チェックを bool doSomething() で宣言したとして、戻り値で「真偽値」だとわかっているとしても、記事内で述べたとおり「それは Do Something の真偽チェックなのか Do Something の成功性チェックなのか」わからないのです。C 言語でいうと int a = 0; if (a = 1) { } と同じくらいこれは正しいのか正しくないのか判断に迷う書き方です

それに引数もしくはメソッドを持っているものが配列だったら？となると動詞は受動態以外の変化形を使わないのほうがわかりやすいと思います。

こちらは申し訳ないですがどう言った意味でしたのか読み取れなかったので可能でしたら軽い例を挙げていただけると助かります

定義と実装の分離ができない言語でメソッドに埋まってしまっているのならどこかに定義部分だけ抜き出したレファレンスを作ればいいと思います。

「レファレンス作ればいい」まで言われると、それこそ極端な話ネーミングなんて気にする必要がなくなります。全部「レファレンス読め」の一言で片付けちゃえますので。でもソースコード読めば一目でわかることができるようなものなのに、なぜわざわざレファレンスに飛んで仕様を読む時間を割かなくてはならないのですか。ただでさえ我々エンジニアは自分のコーディング以外にも人のコードレビューをしたりテストを書いたりしなくちゃいけないっていうのに。

綴り間違いの危険性は主に動的言語を使った時のことです、綴り間違いでメソッドがなくなってるとかを発生させてしまうことがよくあるので
静的解析ツール使えとかいう話ですが...すり抜けることも多いので

それに引数もしくはメソッドを持っているものが配列だったら？となると動詞は受動態以外の変化形を使わないのほうがわかりやすいと思います。

これも動的片付け言語についてですがJavaScriptで

allowUseSkill([value1[,value2[, ...]]]){
  ...
}

と書いてある場合引数の長さは定義時に決まらないので単数形のみの想定でいいのか？です。逆に三人称単数形でないから複数の引数に対するメソッドであると想像させるのは無理があると思います。

レファレンスはちょっと誤解を招く表現でした。
定義宣言集ぐらいのものを想定しました、静的型付けときちんとしたネーミングルールがあれば定義宣言でだいたい何をやっているのかわかるはずなのでそれを作っておけばいいんじゃないかなぐらいの意味です。
コメントアウトで書いてもいいけどコメントアウトは読みにくいし時に雑音になりえるので別に書いてしまえばいいと思った次第です。

全部「レファレンス読め」の一言で片付けちゃえます

逆の極端に言えば逆にレファレンス作らず全部ソース読めになってしまいます。ソースファイルを読みやすくするためのネーミングルールですしある程度まではソースがレファレンスの代わりになるとは思っています。
ただ細かい実装部分まで見る必要はないと思っていますし実装部分が長くなると定義部分が見難くなるので適宜、実装と定義を分離はするべきだと思いますが詰めていくとどうしても実装が長くならざるおえない部分などが出てくるので宣言だけ抜き出しておけば便利だと思った次第です。
IDE使えば定義宣言なんかすぐ追えるかもしれませんがテキストエディタ派の人間もいるので

@kentaro1530

綴り間違いの危険性は主に動的言語を使った時のことです、綴り間違いでメソッドがなくなってるとかを発生させてしまうことがよくあるので

なるほど。まあ動的言語はそもそも罠がいろんなところに潜んであるし、メソッド名の話とは違うが PHP や Ruby みたいにそもそも変数宣言が要らず新しい単語が出てきたらそれが変数宣言だというものもありますので余計レビューしづらい部分もありますが、ただだからと言って綴りを間違うリスクを恐れて敢えて違う意味のものを使うのは、中国のことわざでいうと喉に詰まるのを怖がって食べることをやめるようなことだと思います。

これも動的片付け言語についてですがJavaScriptで

なるほど。言いたいことはわかりました。が、この例はやや不適切ですね。[value1[,value2[, ...]]] はあくまで allow の対象であって allow の主体ではありません。ですので対象がいくらいようと allows は allows です。許可出すのは彼ら value ではなく system です。

おそらく挙げたかった例は、例えば対象の中に特定のものがあるかどうかみたいなメソッドでしょう。英語でいうと contain ですね。例えば containABC(stringA, stringB, ...) というようなものです。JavaScript が配列に直接メソッドを拡張できるかどうかは知りませんが、ただプログラミングの慣例（少なくとも僕が読んできたいろんなライブラリーでは）としては「これらのオブジェクトをまとめて一つの主体」という認識です。ですので複数主体であっても慣例的にはそれらをまとめて一つの主体と認識して三単現を使っています。原形は「やれ」という命令風に読み取りやすいので。

ちなみに JavaScript もそうですが、C# や Swift などの言語も、直接配列のメンバーメソッドで [stringA, stringB, stringC].contains(object) のメソッドがあります。ご覧の通り配列でも三単現です。配列であっても一つのまとまった主体という認識ですので。（まあ呼び出し元がそもそも「一つのオブジェクトだけ」ですしね）

逆に極端に言えば逆にレファレンス作らず全部ソース読めとも言えます。

むしろまさに目指すべきゴールはこれです。英語で言えばいわゆる Self-documenting code です。内部実装やレファレンスに頼らなくても、利用部の読むだけである程度動きが想像できる作り方こそ読み手にも 3 ヵ月後の作り手にも優しい作り方です。

ところが今更ですが

3単元のsは英語でも間違えやすいものの一つ

過去形とかと比べれば三単現は断然間違いにくい方でしょう。基本 -s か -es しかないから。-es の場合は基本決まったルールがあるのでそれ以外は全部 -s です。（唯一思い当たる「不規則変化」は have → has だけですね）

allowUseSkill([value1[,value2[, ...]]])

これについて比較的にいい例思いつきました。例えばスキルを使っていいかどうかを判断するのは複数のシステムがあるとします。そうすれば確かにこのようなメソッドになっちゃう可能性があります：

allowSkill(system1, system2, ...)

ところがこれはこれでとてもネーミングが悪いメソッドです。なぜならばこれらのシステム全員許可する必要があるのか（AND 判定）、どれか一つさえ許可すればいいのか（OR 判定）がメソッド名から読み取れないのです。ですので、下記のどっちかの名前にする必要があるでしょう

allSystemsAllowSkill(system1, system2, ...)
eitherSystemAllowsSkill(system1, system2, ...)

これで英文法的にも合ってますし、読めばすぐ可能性チェックしてるのをわかります（というかそもそも英文法に合ってれば読めばすぐわかるのは当然です）

isSkillAvailable とかどうですかね

@inductor 私個人の感想でしたら isSkillAvailable でも意図が十分伝わっている & 人によって認識の齟齬はほとんどないという意味では全然 OK だと思います。簡潔さでは canUseSkill に負けますが簡潔さよりもやはり伝わるかどうかの方が大事だと思いますので、少なくとももし私がレビュアーで isSkillAvailable のメソッド名が上がってきたら、「もっと簡潔にかける」という理由で却下することはないと思います。

ただ厳密に考えると、isSkillAvailable は「スキルが利用可能」という意味で、「使っていいかどうか」とは微妙なニュアンスの違いを持つのは確かですので、最終的に isSkillAvailable は適切かどうかはやはり実装次第かと思いますね。

Codeのcontextがわからないのでそのへんは何とも言えないすね。
isCanSkillUseという表現から、"If you can use skill under this condition"という風に受け取ったのでそう表現してみました。(If Skill is available for users under this conditionと同義)
これが単純に"If you can use skill"だけであれば、canUseSkillでも良いと思いますが、どういうcontextであるかによって表現方法は変えるべきではないかと思います。

@inductor

Codeのcontextがわからないのでそのへんは何とも言えないすね。

そうですね。それはあると思います。

例えば isSkillAvailable というテキスト、これも確かに「スキルが利用可能」という意味では「スキルが使える」ことを意味しますが、ゲームの場合は例えば「新しいスキルが使えるようになりました」と言ったニュアンスで「New Skill Available」を使うことが多いかと思います。その場合、どっちかというと、キャラクターがレベルアップしたりスキルポイントを利用したりすることによって「新しいスキルが解除された」というニュアンスになります。この場合は isAble と同じような、利用者の主観的な「できる」の意味合いが大きいです。極端な話、レベルアップして新しいスキルが解除されて、例えその瞬間何かしらの客観的なルールによりそのスキルが利用不可（ホームエリアにいて敵との戦闘状態ではなかったり）であっても、ゲームの案内としては「New Skill Available」が使われたりします。

じゃあ canUseSkill はどういう状況で使うのが一番ふさわしいかというと、経験上、例えば doSomething と canDoSomething のメソッドがあるとすれば、if (canDoSomeThing()) { doSomeThing() } は必ず成立する、と言った状況で can を使うのが一番ふさわしいじゃないかと思います。ここの「成立する」とは doSomeThing() は必ず成功するという意味です。実行中にエラーにならないだけでなく、例えば実行中に何かしらのチェックが通らないことによる早期リターンや例外を投げることがあったらそれは成功するとは言えません。つまり doSomething() の結果は必ず Did Something にならなくてはならないと思います。もしこの文が成立すれば、名前として can を使うのは大丈夫だと思います。

ちょっと補足になりますが、ネーミングには一貫性が必要だと思います。同じ動作なら必ず同じネーミングにすべきであり、逆に同じネーミングなら必ず同じ動作をすべきでもあります。例えばここの can も、場所によっては「主観的にも客観的にもできる」動作もあれば、「主観的にできることだけ保証している」動作もあるのは一貫性がないのでいいコードとは言いにくいと思います。

文脈にもよりますが、私ならhaveSkillsとしたいです。

@Ted-HM せめて hasSkills にしましょう😇

@lovee 失礼。hasSkills

@lovee @Ted-HM っていう話で行くと、Skillも安易に複数形に変えないほうが良い気が・・・。
無論、実際のコードで配列要素とかで一度に複数の値を扱うとかなら別ですが。

@lovee

これが単純に"If you can use skill"だけであれば、canUseSkillでも良いと思いますが、どういうcontextであるかによって表現方法は変えるべきではないかと思います。

これが、まさにその返答と同じことを指しています。

最近 func canAvailable(_:) -> Observable<Void> という新種を発見しました🙈

@inductor

その返答

とは…？🤔

@toshi0383

大喜利の予感🤣

isSkillAvailable 構文はよく見かけるのですが、 (単独の疑問文として使う場合には正しい語順であるものの) 直前に「主語」を置いたり if 文の中で使ったりする場合に英文法として正しい語順にならないので、個人的には skillIsAvailable 構文を推しています。

@magicant いいですねこの書き方も。更に欲を言えばもし具体的にどのスキルを示すためのスキルが引数として使うメソッドがもしあれば、ずっと前から思ってたことですが、利用するときに if (skillIsAvailable(someSkill)) ではなく、if (skill(someSkill)isAvailable) 的な構文が書ける文法が欲しかったです。Swift（とその前身の Objective-C）は変数ラベルがあるおかげで変数の前にその役割を示す単語が書けるようになっているけど、変数の前でしか書けないので最後に isAvailable が書けないのが辛い。遠回りの書き方になるが Swift ならなんとかギリギリここまでは持ってこれるけど：

if skill(someSkill, isAvailable: ()) {
    useSkill(someSkill)
}

（参考：https://qiita.com/eimei4coding/items/a8b8c58f6196ce5047f4

言語によりますけど、ちょい前のJavaはis/set/getを付けてプロパティを構築するのが当たり前だったので、
日本語プロパティ派の人たちなんかはこんなのが強いられてきた時代がありました。

int get課税区分();
boolean is何とか税対象判定();

脱線気味ですが出身によってはis/get/setに特別な意味を感じてる人もいたりする、ということだけ。

前に別の命名系の話題でも軽く触れたことがあるんですが、世の中には
boolean型フィールドhogeへのgetterは、isHogeでなくてはならない、正常に動作しない
という言語/フレームワークがあったりします。IDEのsetter/getterメソッド自動生成機能でも、boolean型に対して実行すると無条件にisを接頭辞としてくっつけるやつも結構います、いました。
最近は少ないんだろうか……。

そしてその慣習にならされると、「booleanを返すメソッドは（getterとかでなくても）全てisから始めなくてはいけない」病に汚染されていったりしますね。

@kacchan6@github
ありましたね Java のゲッターセッター。まあそういう言語とかコミュニティーの縛りがあればそれに従った方がいいと思います
ただ Java でも、例えば文字列に特定の文字列が含まれるかどうかの真偽値チェックメソッドは .contains("someString") ですので、少なくとも Java において is にこだわる必要がなさそうに思います…🤔 Java の開発者ではないので断言はできませんが

@Kilisame
それはありますね、特別なゲッターやセッターがある言語。Objective-C でも value のフィールドに getValue のゲッターが自動で生成されます。ちなみにそれは別に「変数名」が is で始まる必要があるってわけではなくて、あくまでそれのゲッターがそうなっているだけですよね…？

isとかcanとかallowとか、言いたいことはだいたいわかりますのであまりこだわらなくても良いと個人的には思います。
それよりも重要なことは、そのあとに続く、do something で、そこが的確でないと何をやってるのかわからないわけです。
また、我々日本人は文法にこだわりすぎるところがありますが、話したり聞いたりする方も大事です。
よかったらこちらの私の記事もご覧ください(笑)https://qiita.com/tfutada/items/91d727ef435c18fb8dba

Javaの場合はisにこだわるのはプロパティなので、単なる問い合わせのメソッドであれば割りとどうでもいいですね。
最近はpublicなフィールドをサポートしているフレームワークが増えたので、気持ち悪さも低減しています。

skillの例であれば、個人的にはskillsというプロパティを作って、user.skills.allows("any")みたいな感じにしますね。
「何々」の「何々」が「どうか？」というメソッドが増えるとオブジェクトが肥大化するので、
こういう命名が出てきた時点で、名前をどうするかよりも、オブジェクトの設計を先に考えるほうが実際には多いです。

• this/SomeClassのようなインスタンス/クラスを主語としてthis.is~とするメソッド
• 他の何かを主語として明示してthis.isSomething~とするメソッド、
• is~(something)とする関数

有名なライブラリでよく使われるbooleanを返す関数は、（雑ですが）こういう切り分けもできると思います。もちろんcanhasも同じで。個人的にはこれを見る限り、if文内ではどうこうというよりもそもそも自然言語として成り立たせようとしている訳ではない気がします。
あと基本的に複数のものを主語に取れる(複数のものが主体となる）メソッドというのは存在しないと思っているので、やはり三単現の活用は必須だし無ければ（無意識にでも）気持ち悪いと感じる人は多いんじゃないかという気がしています。

同じ機能でも、言語が変われば見た目も変わる気がします。

Rubyでは、foo.nil?のように疑問符をメソッドの末尾に入れられるので、名詞や形容詞で表せる属性なら、finite?とかzero?のようにほぼ名前が決まります。

あと、File.exists?がdeprecatedになってFile.exist?に代替されているように、三単現のsも省略されています。

@tfutada
もちろん do something もとても大事ですよ！それは否定していませんし receive100Yen のメソッド呼び出して逆に 100 円支払わされたら絶対作った人ぶち○す（笑）
ただまあ私が言いたかったのは、別に is にしようとか can にしようという絶対的な基準な話ではなく、むしろ tfutada さんと同じ「的確」なメソッド名にしようという話です。allow の例で言うと、三単現ではないので意味合い的には「このスキルを使えるようにする、成功したら true 返して」と言うメソッドに読み取れてしまうのでやめましょうねと言うお話です。逆にむしろ意味が伝わるから isCanUseSkill の方がまだ笑って済ませる分マシだと言いたかったです（笑）

@kacchan6@github
プログラムの作り方にもよりますので、具体的にどのような作り方にするのがベストなのかみたいな話はちょっと難しいですね、しかも自分は Java は ROM 専で書けないので（）
ただおっしゃる通りオブジェクトの設計を先に考えた方が、あとあとから名前付けるときはやりやすいと思います、多くの場合は設計通りに作れば名前も自然に決まっちゃえます

@sh0

そもそも自然言語として成り立たせようとしている訳ではない気がします

同意です。プログラムは結局のところプログラミング言語であって自然言語ではないので自然言語として成立させるにはとても難しいです。しかもそもそも違う言語は違う言語仕様があるので、例えば Objective-C は [actor move:view to:destination] と書けるけど、C# ならせいぜい Actor.MoveViewToDestination(View, destination) になります。
ただ自然言語にはならなくても、使う単語の形態に気をつける必要が少なからずあるかと思います。例えば同じ validate でも、bool result = object.validate() と bool result = object.validated() が読み手に与えるイメージは全く違いますので

@jkr_22555
Ruby の文末に ? を入れられるのは一般的に見てかなり特殊な仕様ですので、これにより allow? と allow は読み手には違うイメージを与えられるので、Ruby なら別に allowSkill? が使えるのでそれで問題ないと思います。ただ世の中のほとんどの言語にはこの仕様がないので一般論としては「三単現を使わなくても大丈夫」ことにはやはりなりにくいかと…
本文の「またさらに追記」にも書きましたが、言語それぞれ違う規約や習慣があるので、同じ動作でも最終的に違うネーミングになるのはよくあるし正しいと思います。要するに「絶対多数の使う人に伝えたいことが伝わるか」が大事です。