Boolean型の変数名・メソッド名に主語を含めたい時はどうしたらいいか - Qiita前提 Javaを中心に考えています。 他の言語でも大体成り立つ話になるとは思いますが、Rubyとかは怪しいです。 基本のおさらい Boolean型の変数名・メソッド名には、以下のような名前がいいと一般的に言われています。 ・isEmpty ・canRead ・hasChanged ・exists これらの名前はif文の中で特に効果を発揮します。 例えば、
モノの数を数える変数名の命名 は fooCount の形式が良いみたい - Qiita
数えるモノの名前を仮に foo として「foo の個数」を、プログラミングの文脈ではなく素朴に英訳すると「number of foos」になるが、これを元に変数名にすると長いし何か落ち着かない。などと以前から思いつつ何となく流していた。ふと、少し調べてみた。 英語ネイティブの言語感覚で fooCount が比較的多くの人が合意しうる案のようだ。 ざっと読んでの要点メモ number では foo に関する何の数字か分からない。count ならば個数のことであることが示唆される。（書籍「CODE COMPLETE」にこの曖昧さについて記述があるらしい。） number には名詞、count には動詞の感じがある。が、辞書的には両方ともどちらにも使えて（動詞）「数える動作」（名詞）「そうやって得た数」の意味がある。 count には数え上げて総計を求める動作の感じを伴う。数え上げた結果の数なら
boolean 値を返却するメソッド名、変数名の付け方 - KUSAMAKURA
boolean 値を返却するメソッド名や、変数名の名前のテンプレを作ってみた。名前に気を付けるだけで、意外と綺麗なコードになるので、参考にして欲しいです。 名前の付け方 is + 形容詞 形容詞の状態であるかを尋ねる. ex) isEnabled has + 過去分詞 動詞の状態となったか（完了、経験、継続）を尋ねる. ex) hasSent can + 動詞原型 動詞の挙動が可能かを尋ねる. ex) canGet 三単現動詞 動詞の状態かを尋ねる.後に続く名詞が明確な場合に利用する. ex) exists 三単現動詞 + 名詞 動詞の状態に名詞があるかを尋ねる. ex) existsError, hasError should + 動詞原型 動詞の挙動を行うべきか尋ねる. ex) shouldCollect, shouldRedirect NOTE： ※基本的に Yes を動詞, 形容詞
プログラムのネーミングに迷ったら GitHub でコード検索すると参考になる説 - Qiita
TL;DR プログラムのネーミングで迷ったら GitHub でキーワードを検索して、ヒットした件数が参考になるのでは？ 複数キーワードを検索して結果の一覧を表示する CLI 作りました https://github.com/kyoshidajp/ghkw ネーミング迷いますよね？ みなさん、コードを書いていて変数やメソッド名のネーミングって迷いますね。 こんな時に自分たちはチームを横断して「こういう名前考えたんだけど、これってどうかな？」という確認を Slack 上で行っています。先日、この Slack チャンネルを見ていて考えました。 「GitHub で検索すれば世の中のコードでどのぐらい使われているかざっくり分かるので参考になるのでは？説」 GitHub で検索できるという条件付きではありますが、コードの規模からするとある程度期待できそうです。 GitHub で検索 例えば「除外条件」
入社からの半年間でコードレビューで指摘されたことのまとめ - 30歳からのプログラミング
実務未経験でプログラマとして入社して半年以上が経った。 コードレビューで指摘されたことを備忘録としてまとめておく。 自分なりにまとめたものなので、レビュアーが言いたかったこととニュアンスや解釈がずれている可能性はある。 初歩的な内容ばかりで我ながらうんざりする。 せっかく優秀な同僚ばかりなのだからもっと高度なことを学びたいが、こういう初歩的なことが出来ないのが俺の現状なのだから、仕方ない。 そもそもPullRequestを送ったこともなかったわけだし。入社初日は、一人でPullRequestの出し方を練習していた。 それを考えればまあ、こんなものだろうか。 当たり前のことをちゃんと当たり前に出来るようになって、早く、次のステージに進みたい。 PullRequest(PR) PRのタイトルは分かりやすいものに。必要に応じてチケットの番号なども入れる。 コミットやPRは出来るだけ粒度を細かくす
vim も zsh も捨てた - AnyType
プロジェクト移行期に入って暇な時間ができたので、開発環境をリフレッシュすることにした。vim や zsh の設定が少しずつ壊れてきていたのだった。 .vimrc や .zshrc を眺めてみると、かつて意識が高かった頃に施した設定が何のためのものだったのか忘れてしまっていた。別人が書いたスパゲティコードのようだった。 また vim や zsh の設定を検索して理解するべきなんだろうか。ここで覚えた知識はまたすぐに忘れてしまうんじゃないだろうか。設定が洗練されるほどに、それを更新する機会もまた少なくなってくる。設定が必要になるきっかけは忘れた頃にやってくるもんだ。 やり方を根本的に見直す時期なのかもしれない。新しいツールもいまなら選択できる。 まず、vim から atom に移行した。git のコミットメッセージやちょっとしたファイルの修正ではまだ vim を使うものの、細かい設定が必要にな
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
http://www.gembook.org/python_grammar_book.html
