状態に関するメソッドで ensure が記載されていますが、 assert も同じ意味で使われていると思います。

@7of9 assertだと例外を投げるかexitするかほぼ確実に強制終了に近いことしそうなので、ensureみたいにエラーコードを返すこともありそうな名前と同列に扱うべきではないと思いますよ

@aokomoriuta なるほどです。

http://www.codeproject.com/Articles/1863/Design-by-Contract-Framework
にCheck.Ensure()の実装例がありますが、このように、assert()でなく例外で使う、という方法もあるということですね。

 public static void Ensure(bool assertion, string message)
    {
      if (UseExceptions)
      {
        if (!assertion) throw new PostconditionException(message);
      }
      else
      {
        Trace.Assert(assertion, "Postcondition: " + message);
      }
    }

勉強になりました。ありがとうございます。

ensure は「期待する状態かどうかをチェックし、そうでない場合はその状態にする」関数にも使われますね（ディレクトリが存在しなければ作成する、とか）

• http://docs.ruby-lang.org/en/2.2.0/Gem.html#method-c-ensure_gem_subdirectories
• http://elixir-lang.org/docs/v1.0/elixir/Code.html#ensure_loaded/1

@uasi ありがとうございます。勉強になりました。
rubyやelixirはやっていませんが、こういう使い方というのは参考になります。

@KeithYokoma さん、Twitterが公開している文書 http://twitter.github.io/effectivescala/index-ja.html にある、副作用有無とか冗長なものは避けるとかそんなアドバイスがあると素敵かもしれませんね

以下、引用

副作用を起こす操作は能動態で命名する
user.setActive() ではなく user.activate() とする。
値を返すメソッドは説明的に命名する
src.defined ではなく src.isDefined とする。
ゲッター (getter) の名前の先頭に get を付けない
以前のルールと同様にこれは冗長だ。site.getCount ではなく site.count とする。
パッケージ名やオブジェクト名で既にカプセル化されている名前を繰り返さない
object User {
  def getUser(id: Int): Option[User]
}
ではなく
object User {
  def get(id: Int): Option[User]
}
とする。User.getUser は冗長だし、User.get よりも多くの情報を与えない。

@makito さん、ありがとうございます！

適切な量の情報を伝えるという点では、単語の意味の側面以外にもいろいろありそうですね！ここでは単語の意味に注目してみましたが、それらも含めてまた更新してみようとおもいます。

私がよく使うのに、

「検索して取得する」の retrieve
コレクション等から「特定の値を抽出する」の pluck

があります。ご参考まで。

https://twitter.com/codic_project
こちらのTwitterアカウントも見ておくといいですね。よく参考にさせてもらっています。

キューやスタックの「次に処理する要素を取り出す(取り除く操作を含まない)」というメソッドには、C++ではtopという名前を使いますね。peekは馴染みがなかったです。
似たような用途だと、Javaの乱数ライブラリやイテレータでは、nextという名前も使いますね。
キューやスタックには少々適切ではないと思いますが、シーケンシャルなコレクションだとC++ではfront/backという名前が使われます。

検索は、findに加えてsearchもあるといいですね。depthFirstSearch/breadthFirstSearchとかがよく使われる例です。

【IT英語】findとsearchの違い / find は「探し出す」とも訳されるように、「探す」行為が完了し何かが見つかることにフォーカスがあります。反対に、serachには完了するニュアンスはなく「探してみる」感じに近くなります。（140文字だとこれが限界...）
https://twitter.com/codic_project/status/317055943881936896

参考までに、私は状態に関するメソッドでPrefixにCheckも使うことが多いです。

@narumi888

check は何をどうチェックして何を返すのか曖昧になるので自分は避けるようにしています。他人のコードで見かけたら、何を実行するか予想がつかないので警戒しつつドキュメントやソースを読みます。

たとえば Ruby 2.2.3 に添付されている RDoc モジュールには check の名前を持つパブリックメソッドがいくつかありますが、挙動はバラバラです：

RDoc::Parser#check_modeline(file_name)
    ファイル内の modeline を検索して一致する文字列または nil を返す

RDoc::Options#check_files
    配列 @files 内の各ファイルパスをチェックし、存在しなければ配列から取り除く
    存在するが読み書きできない状態なら、取り除かずに warn でエラーメッセージを出す

RDoc::Options#check_generator
    コマンドライン引数 --generator が1回以上与えられていたら例外を投げる

（これらは rdoc コマンドの実装詳細であり自分が直接呼び出すことはないとは思いますが……）

自分ならそれぞれ find_modeline, reject_missing_files, ensure_generator_unspecified にするかなと。

単純に期待する状態か否を見て bool を返すメソッドなら、名前は is_*, can_*, または exists のような動詞にしたほうが分かりやすいと思います。

validate_* や verify_* という名前なら、期待する状態でない場合に詳細なエラー報告を返しそうだと予想できますし、 ensure_* なら期待する状態に修正してくれるか例外を投げそうだと分かりますね。

@ka215

pluckは以下を見て解釈すると「コレクションなどから特定の値を抽出する。その時、コレクションからは削除する」という使い方になりそうですね。

コレクションから取り出して、コレクションには残したままにしたい場合には他の用語がよさそうに思います。

とても有用な情報です。勉強になりました。

Apple の cocoa のガイドラインです。
https://developer.apple.com/library/mac/documentation/Cocoa/Conceptual/CodingGuidelines/Articles/NamingMethods.html#//apple_ref/doc/uid/20001282-BCIGIJJF

こちらでも、単純なプロパティへのゲッターには get は不要となってますね。

ただし、(引数を元に計算などして) indirectly な値を取得する場合のみ、get〜 をつけましょう、とあり、これもわかりやすくて良いと思います。

check〜 のメソッド名は、私も避けるべきと思います。出てきたら、普段の数倍緊張して読みますね。

from と近い感じで of とかよく使います。クラスが単一の値を表したものの場合は Xxx.valueOf とかも。

何かの後に続けて行うメソッドの接頭辞や接尾辞に thenもよく見ます。

また、～と一緒に的な意味や、インスタンスに付加情報を足した新たなインスタンスを生成するメソッドに withXxx、～のために的な説明や、from/ofと似たような用途で forXxx なんかも使いそうです。

check は曖昧になるので避けるってのは私も同意見です。他にも似たようなのに test、judge とかも危ない名前かなという感じがします。
特に、業務的なチェック処理なんかでbool値を返す check～ は(とてもよく見かけますが)、殆どが期待値かどうかを調べるメソッドなので isValid/isInvalid や validate などを使うのが適切かなって思ってます。

ただし、結果がおおよそ予測できそうな単純な処理や、抽象化された機能では、これらの名前を使うのもありかなとは思います。

e.g.

• JavaのライブラリGuavaのPreconditionsでは事前条件のアサーション用のメソッドにcheckで始まる名前を使ってます。
• Predicate の test メソッドなど。

get/set は、個人的には冗長なので好みじゃないですが、JavaBeans のように仕組みとして利用されてたりする場合もあるので、冗長とわかっててもあえて get / set で揃えちゃう事もあるかも。(IDEの補完の一覧で同じ接頭辞で並ぶのでプロパティと判断し易いっていうメリットもいくらかはありそう・・・かも？)

あと細かいとこちょこちょこ。

• push、pop、peek があるなら poll もあってよさそうかも。
• 主にデータ操作系、こういうのどうでしょうか。
  • 先頭要素 head または first
  • 末尾要素 tail または last
  • 次 next
  • 前 prev または previous
  • 受け入れる accept
  • 提供/供給する provide または supply
  • 計算する calc、calculate、compute

メソッドというかクラスのメンバに属さないようなただの独立した関数だとis~などの接頭辞は個人的になんか付けにくいですね。戻り値を代入する変数名と被ってしまうので。

// ok
var isHoge = piyo.isHoge();

// NG
var isHoge = isHoge(piyo);

@syuiloさん

そうですね。var isHoge = isHoge(piyo);を回避するため自分はvar bfHoge = isHoge(piyo);(bf: bool flag)などする場合もありますが、しっくりきてないですね。

isHoge(piyo)は、"piyo"が"Hoge"という状態にあるかどうかを判断するのだから、
その戻り値を格納する変数は "Hogeという状態" を表す名前にするとよいと思います。

var hogeMode = isHoge(piyo)
if (hogeMode){
    ....
}

というか、「そのフラグをif文に突っ込んで、英文として意味が通じますか？」という問いを立てれば、
if (isHoge) とか if (hoge_flag) みたいな事にはならないと思いますが…。

「状態」という考えからhogeModeというのはなるほどと思いました。

反面、数ヵ月後のソースリーディングで以下のコードを見た時、「処理2はどういうモードなのだろうか?」という疑問を持つ可能性もあると感じました。

if (hogeMode) {
   // 処理1
} else {
   // 処理2
}

var hoge = isHoge(piyo);

// 複数行にわたる記述

if (hoge) {
   // 処理1
} else {
   // 処理2
}

「hogeかどうか」を見る場合にhogeという変数名にする。
ただし、「trueかどうか」の場合に破綻する。var true = isTrue();

ただの感想です。
実用的で美しくて大変感動しました。
素敵な記事をありがとうございます。

toやforってどうしてますか。
自分はキャッシュやDBに保存するときなんかは~ToCacheみたいに書いてるんですが、
ForCacheとか書いている人もいて英語的にどうなんだろうと。。。。

@0xCAT さん

Delphi/C++ BuilderではSaveToFile(), LoadFromFile()を僕はよく使います。
Cache に 保存の場合は、SaveToCache() ( SaveToDB() )だと意図が分かりやすいと思います。

githubで検索すると
- saveToCache() : 15万件
- saveForCache() : 0件

forCacheの場合は「Cache用に」という意図なのでしょう。
関連 http://stackoverflow.com/questions/15197600/bind-image-and-save-for-cache-folder

And i want that when i bind it it will save the image to my disk for cache issues

"Cache用"の意図での「SaveForCache()」はアリ、だと思います。

なるほど！やはり保存場所を明確にしたい場合はTo一択なんですね
ありがとうございます

@syuilo @7of9 @kameon
ちょっと反則的かもしれませんが、「piyoがhogeという状態である」をそのままpiyoIsHogeとするのはいかがでしょう。

var piyoIsHoge = isHoge(piyo);
if (piyoIsHoge) {
    // piyoがhogeである時の処理
} else {
    // それ以外の時の処理
}

isHoge()関数が引数を取らない時はstateIsHogeにするとか。

var stateIsHoge = isHoge();
var stateIsPiyo = isPiyo();
if (stateIsHoge) {
    // hogeである時の処理
} elseif (stateIsPiyo) {
    // piyoである時の処理
} else {
    // それ以外の時の処理
}

「名前に『is』が入ってるからbool値だな」（変数ならbool値が入っている、関数ならbool値が返ってくる）と判断し、頭に名詞を付けることで「これは変数だな」と判断できるのではないかと思います。