あいまいを避けて勘違いの起きない命名をするための体系的分類（を目指して） ―― 英文法による一般化と明確化 - Qiita
はじめに：この記事を書いた動機 これらの素晴らしい先行記事を見て、「言語学を用いれば、共通点を見つけ出して一般化・大項目化したり、取り違えやすいエッジケースを明確化できるんじゃないか？」と思ったことが、この記事を書き始めたきっかけになります。 １章は３つの主要なパターンとその詳細・例外、２章はそれらに関する文法的な解説になっています。 構造化・体系化が必要な理由 太郎くんと花子さんが英作文の問題を解いています。 次の日本語を英文に訳せ。 (1) 彼女は楽しい人だ。彼女といると退屈することがない。彼女はいつも新しいことに挑戦して…… 太郎くん（『楽しい』って英語で何やったっけ……） 狩井先生@ 1年6月「exciting は楽しいって意味やで～」 ~~ 月日が流れる ~~ 柱鈴先生@ 2年4月「excited は楽しいって意味やで～」 太郎くん（……って教わったけど、exciting か e
弊社で使っているAWSリソースの命名規則を紹介します | DevelopersIO
みなさんこんな画面を見たことありませんか？？ このような状態は避けるべきです。理由は以下の通り。 各リソースの役割がわかりにくい オペレーションミスが発生しやすい リソース削除などの判断が難しくなる 単純に見栄えが悪い そこで今回は弊社が環境を構築する際によく使う命名規則を紹介したいと思います。 新規でリソースを作成する際に参考にしていただけると嬉しいです。 ※AWSアカウントでシステムや環境を分離していたとしても、命名規則を守ったほうがリソースの見通しがよくなります。 リソース名から何を知りたいのかを考える みなさんはリソース名（主にNameタグ）から何を知りたいですか？？ 対象のリソースによっても異なりますが、共通で知りたいものは以下になるかと思います。 対象システム 環境(本番、検証、開発) また、リソースによってはこれ以外に知りたい情報もあるはずです。 Subnet、RouteTa
”delete”と”remove”の使い分けについて | SDNA ローカライズチームブログ
私たちは「削除」という日本語文言を英語化する時、仕様によって“delete”と“remove”を使い分けています。“delete”は、例えばファイル自体が削除される場合に使用し、“remove”は一覧からの項目削除などファイル自体は削除されない場合に使用しています。 Microsoft スタイルガイドでも下記のように書かれています： Do not use remove to mean delete. Remove is correct in technical contexts such as the following: - To refer to taking an item off a list in a dialog box that has Add and Remove buttons. - To refer to taking a toolbar button off a to
プログラマが知っておくべきネーミングの基本 - Frasco
開発者の間で最も多い問題の一つはネーミングです。どのような名前にしようかと考えるのに何時間費やしたか、また、望ましくない名前を含むコードを理解するのに何時間費やしたか、数え切れません。オブジェクト名、メソッド名、クラス名、その他なんであろうが、そんなことは関係ありません。コードを書くよりも、コードを読む方に時間を費やしているということは証明されているので、良いネーミングをするということは、将来的に応えてくれるということなのです。 好ましい名前を使うことにより、あなたのコードはより良く、また、より簡潔なものとなります。良い名前をつけることで、コードのそれぞれの役割を直観的に識別しやすくなります。そして、将来、あなた自身が読むときと同様に、他の開発者があなたのアプリケーションを読むことを容易にしてくれます。 次の数分で、良いネーミングの重要性を説明し、良い名前を思いつくための有益なコツをシェア
真偽値を返す関数のネーミング - Qiita
みんな exists を使ってます。 納得できようができまいが、exists なのです。 ソフトウェアの世界では、Apple と Microsoft と Google が黒と言ったら黒です。 黙って従いましょう。 このように、関数名の表現に困ったら、世の中の API を参考にすると良いです。 非ネイティブの我々では思いつかないような的確な表現が見つかることもあります。 関数の名付け方 真偽値を返す関数は if 文で使われることが多いので、頭に if を置いて最もしっくり来る表現が良いと思います。 個人的には、真偽値を返す関数名を考えるときは以下のフォーマットに当てはめるようにしています。 if オブジェクト名 関数名 「項目が選択中だったら」なら "if item is selected" なので関数名は item.isSelected() となります。 同様に「項目が存在したら」なら "
SQLスタイルガイド - Qiita
はじめに 本文書はSQLのスタイルガイドです。 PythonやRubyのようなプログラミング言語には有名なスタイルガイドがあり、共通のレイアウトルールに沿ったインデントや命名規則に則ったコードが生み出されています。 一方、SQLには知名度のある統一されたスタイルガイドがありません。 そのため、思いのままに書かれたSQLが散見されます。 もちろん、SQLを使ってアドホックな分析を行う場合は、必ずしもルールに沿う必要はなく、効率よく書いても良いと思います。 しかし、Webサービスやバッチの中に組み込むようなもの、つまり自分以外の誰かに読まれるSQLは、多くのプログラミング言語同様に何らかのスタイルガイドに沿うことで多くのメリットを享受できると思います。 クエリが構造化され、可読性が高まる バグの発見や修正が容易になる 改行位置やインデントなどのフォーマットの悩みが解消される スタイルガイドを共
今さら聞けない、変数や関数の命名規則と、まず覚えるべき英単語200
（Wikipediaより） ハンガリアン記法のメリット 論理型であるbFlagと、文字列型であるsNameが bFlag + sName となっていれば誤りであることがわかる。 型の記述が2文字程度で済むので、変数名が短く済む。 ハンガリアン記法のデメリット 暗黙の型変換ができない。変数の型を変更するごとに変数名まで変更しなくてはならず、命名法に添って名前を付けるのが面倒。 （同じユーザーIDでも使い方によってはsUserid、iUseridなど） キャメル記法 文字のラインが凸凹になる様をラクダのこぶになぞらえてキャメル記法と名付けられた。 大文字小文字を区別する言語と区別しない言語があるので使う場合は全体を統一すること。 先頭の文字を大文字にするか小文字にするかで2つのパターンがある。 アッパーキャメルケースまたはパスカルケース（1単語目から大文字） 悪い例 $userparamete
codic-vim を使ってスペル補完をするとかなり捗る - 漂流日記
codic というサービスがあります。 プログラムのクラス名･メソッド名や変数名の名前をつけるとき、適切な単語が見つからなくて悩んだりすること、あると思います。 そんなとき、codicを利用すれば、類語辞典のように、適切な英単語を見つけることができます。 vimから利用する場合、codic-vim(紹介記事)を利用するのがよいでしょう。 :Codic 実行 等とすると、以下のように候補を知ることができます。 これだけでもかなり便利なのですが、今回、そこからさらに一歩踏みこんで、codic-vimを利用して入力補完の機能を作りました。 https://gist.github.com/sgur/4e1cc8e93798b8fe9621 見ての通り、codic-vimのcodic#search()関数を利用して、補完機能に仕立てています(故に、codic-vimがインストールされていることが前提
Visual Studio 拡張をリリースしました - codic ブログ
ようやくVisual Studio拡張が完成しました。長らくお待たせしました。 インストールと設定 1. Microsoft GalleryからVSIXをダウンロードして実行してください。 2. メニュー “Tools” > “Options” でオプションダイアログを開き、”Codic Extension” のオプションページより、アクセストークンを設定してください。アクセストークンは、codicにサインアップ後、APIステータスのページより取得できます。 使い方 1. コンテキストメニューから “Generate Naming for …”を選択するか、Ctrl+Shift+Dでクイックダイアログが開きます。また、エディタ上で翻訳したい単語を選択した状態で行うと、直接変換もできます。 2. 候補が表示されますので、矢印キーで選択、”Enter”で置換できます。 ネーミングを編集する 今
メソッド名を考えるときに気をつけること - 亀岡的プログラマ日記
大学時代に、プログラミングだけでAO入試で入ってきて、部活に熱中しすぎて一年留年して、成績優良で某幸之助じいちゃんの会社に行った奴がいましてね。そいつにずっと言われてたのが プログラムは自然言語としてよめるべき。コメントはいらないよ。 という話で、そのときは「いやいやwww」と思ってたけれど、最近の僕の思考は、もう「自然言語として読めるか」に尽きるようになってきた。 んで、こんな話。 @ngsw_taro @yy_yank @soudai1025 なるほどー。。。booleanなメソッドなのに、is～ではないことがわりと違和感ですが。。。そうでもないんでしょうか。。。— しょぼちむ@物理 (@syobochim) 2015, 3月 16 booleanはIshogehogeなのか？ そうであることは多いですよね。でも、例外も非常に多いです たとえば、 Enumerable.Contains
FINDJOB!終了のお知らせ | FINDJOB!
FINDJOB! 終了のお知らせ 2023年9月29日にFINDJOB!を終了いたしました。 これまでFINDJOB!をご利用いただいた企業様、求職者様、様々なご関係者様。 大変長らくFINDJOB!をご愛顧いただき、誠にありがとうございました。 IT/Web系の仕事や求人がまだ広く普及していない頃にFind Job!をリリースしてから 約26年間、多くの方々に支えていただき、運営を続けてまいりました。 転職成功のお声、採用成功のお声など、嬉しい言葉もたくさんいただきました。 またFINDJOB!経由で入社された方が人事担当になり、 FINDJOB!を通じて、新たな人材に出会うことができたなど、 たくさんのご縁をつくることができたのではないかと思っております。 2023年9月29日をもって、FINDJOB!はその歴史の幕を下ろすこととなりましたが、 今後も、IT/Web業界やクリエイティブ
変数とメソッドの命名ベストプラクティス15 - 杉風呂2.0 - A Lifelog -
この記事は、Cagdas Basarane 氏のブログ、 CodeBuild から 2012年2月20日の記事 "15 Best Practices of Variable & Method Naming" を翻訳したものです。 原文URL http://codebuild.blogspot.com/2012/02/15-best-practices-of-variable-method.html 十分短く十分長い変数名をスコープごとに使用する。一般的に、ループカウンタには1文字、条件やループ変数には1単語、メソッドには1-2単語、クラスには2-3単語、グローバル変数には3-4単語を使用する。 具体的な(specific)名前を使用する。例えば、"value"、"equals"、"data"といった変数名はいかなる場合も有効ではない。 意味のある(meaningful)名前を使用する。変数
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
http://www.smaroomch.net/programing-naming/