概要
よく迷うことやレビューでよく議論になることをまとめてみる。
溜め込んでおいて、辞書的に使えれば良いかなって感じ。
キリが無いのでとりあえず思いついた箇所だけざっと調べてまとめてみた。
別に得意でもちゃんとした本とかを持ってるわけでもないので、それぞれについて 6, 7 記事ほどネットで斜め読みして抜粋した感じ。
既にこの手の変数名やコミットメッセージに関する英語記事は沢山あるけど、以下の理由があって自分でもまとめてみた。
- クラス名やメソッド名のため、品詞を重視する
- 今の自分の仕事に関係することにフォーカスする
- 自分の頭と手を使って集めて整理する
（追記）
これをまとめている途中で 面白い本 を買ったので、内容は加筆されたり修正される可能性が大いにあります。
品詞
プログラムにおける名付けの良し悪しは品詞が８割（体感）。
例えばfailNoticeみたいな変数名があったとして、「エラーに落とす処理？」「なんかのエラーハンドルに使う処理？」「それとも失敗通知みたいな情報？」みたいに混乱して、結局前後のコード読まないといけなくなることって、あるよね！？（例が微妙だけどさ）
クラス名や変数名は名詞にする ( N[c] / N[u] )
申込書なら名詞なので application
application = new Application(...)
Noun なので名詞をNと略記する
また countable なので可算名詞をN[c]、uncountable なので不可算名詞をN[u]と略記する
メソッド名は動詞 ( V )
申込なら動詞なので apply
service.apply(application)
Verb なので動詞をVと略記する
形容詞 ( A )
Adjective なので形容詞をAと略記する
例）V fail / N[u] failure / A failed
- 動詞は失敗する
- 名詞だと失敗や不成功のこと
- 形容詞は失敗した〜〜みたいに使う
ので、冒頭のfailNoticeの例は、処理ならfail、失敗自体を管理してるならfailure、失敗した通知を管理しているならfailedになるのが適切だ、みたいに一語ずつちゃんと品詞を気にして名付けをした方が良い。
ちなみにオチは「失敗を通知する」だったりしてね、よくあるよね。
その場合はnoticeFailureになるのかな？
単語
ここから先は似た単語をひたすら列挙して調べた違いを整理する
例によってとても長いので qiita の生成してくれるサイドバーのインデックスを頼りに、気になるところだけ参考にする感じで
お金
料金
案外明確に違う
N[c] fee
- 施設や組織に払う対価
- 専門職への謝礼にも用いられる
- 診察料、授業料
N[c] charge
- サービスの利用料や手数料
- 通話料金、配送料、席料、キャンセル料
- 動詞の場合は請求するという意味で使われる
- 現金に対してクレジットカードとして用いられることもある
- cash or charge
N[c] cost
- 費用
- 生活費、医療費
N[c] rate
- 特定の基準により設定された料金
- 料金体系があるサービスの料金
- ガスや電気水道
N[c] fare
- 交通機関の料金や乗車賃
- 電車賃、飛行機の運賃
- bus fare はバスの運賃
N[c] price
- 商品の価格に対して使われる
- bus price はバス自体の値段
N[c] toll
- 橋や道路などの使用量や通行量
- 電話料金も
- free dial は和製英語で、正しくは例えば toll free call とでも言うらしい
支払
V pay / N[u] pay / N[u] payment
- pay は支払う
- payment は支払い
- 名詞の pay もあり、給料を示す
- wages, salary 等の違いは今の自分にあまり関係ないため少し調べたが割愛
V purchase
- 購入する
V bill / N[c] bill
- 動詞は請求する
- 名詞は請求書
処理
予約
V book / N[u] booking
- book は帳簿に由来していて、記帳した時点で確定するニュアンスを含む
- 予約時点で料金が発生するなら book
- 宿とか
V reserve / N[u] reservation
- キープのニュアンスを含む
- キャンセルの可能性がある
- 物や席の予約をするなら reserve
- レストランの席なんかはよく [ reserved ] って書いてある
V appoint / N[u] appointment
- 人との約束や会う予定
V plan / N[c] plan
- 計画のこと
- 継続して何かのために行う行為や手段のニュアンス
- 前後の文脈で計画の内容が述べられるのが一般的
V schedule / N[c] schedule
- 予定のこと
- 何かを行う特定の時間を示すニュアンス
- 計画のための時間枠のことで、計画そのものではない
- 前後の文脈で時刻や順番が述べられるのが一般的
申込
システムで頻出すると思われる単語
V order / N[c] order / N[u] order
- 注文する、発注する
- 利用者としてお金を払ったり、命令だったり
- まず断らないというニュアンス
- 不可算名詞だと順序や整理等の意
- 可算名詞だと注文書や注文品
- 個人的には動詞も名詞も同じ形の単語はプログラミングでは避けたい
- が、注文としては適切なので仕方ない
- ちなみに注文明細は素直に order details で良さそう
- （追記）と思っていたが、英語の本を読んでたら order lines と言っていた
V offer
- オファーされる人が喜ぶ物を提供する
- どうするかはオファーされる人の自由というニュアンス
V submit
- 提出する、投稿する
- http で post する時のボタンのイメージが強いかな？
V apply / N[u] application
- 応募する、申請する
- 審査や選抜を伴う
- application には色々な意味があり、適用の様な場合は不可算名詞だが、申込書なら可算名詞
入会
どんなシステムでもアカウント登録は大抵あるだろうから、馴染みはあるはず
V register / N[c] register / N[u] registration
- 登録する
- 帳簿などに氏名等を書き加える
- 公的機関への登録、チェックイン、イベントの参加申込
- regist という単語はない
- 名詞の register は登記や記録、名簿のようなリストを指す
V admit / N[u] admission
- ある団体の会員となること
- 入場する、入会する
V sign up
- 登録を申し込む
- register と違いがわからないけど、こちらの方がやや口語的というニュアンスみたい
- ちなみに sign upped ではなく signed up
V subscribe
- 定期的なサービスに申し込む
- 他に署名する、同意する、も
参考
どうもピンと来ないので、いくつかのサービスの url とかを見て整理してみた
| 単語 | アカウント |
|---|---|
| sign up | google microsoft github jetbrains |
| create account | sony apple |
| register | amazon evernote ニンテンドー チャットワーク ニコニコ動画 |
| subscribe | youtube のチャンネル登録 ブログ購読 intellij のライセンス購入 |
退会
同様にアカウント管理について回る単語について
V unregister
- 登録を解除する
V resign
- 辞職する、辞める
V withdraw
-
退会 英語で調べるとひっかかるけど、英和辞書を見ても退会という意味は見当たらない... - 申し出を撤回するというニュアンスがひっかかってるのかな
V unsubscribe
- subscribe を辞める
参考
こうして見ると、入会と退会で対になっている単語のような物はないのだろうか
| 単語 | アカウント |
|---|---|
| :-- | :-- |
| delete account | google github jetbrains dropbox |
| deactivation | |
| withdraw | ニンテンドー |
| close | チャットワーク |
| unregister | ニコニコ動画 |
| unsubscribe | github でコメント通知を受け取らないようにする |
結論
create account と delete account はシンプルだけどわかりやすくて良いと思ったし、案外使ってるサービスが多かった
個人的に対になっている方がわかりやすいしソースコードも理解しやすい気がするので、この組み合わせは覚えておこうと思う
それか、register / unregister かな？
user = service.register(name, mail)
service.unregister(user)
物
端末
N[c] mobile phone
- 英国
N[c] cell phone
- 米国
N[c] phone
- phone のみで文脈で判断する場合が多いらしい
- telephone の略記が phone で、意味の違いはない
- 固定電話とスマホとガラケーを整理するならこんな感じ？
phone
|-- landline
`-- mobile phone / cell phone
|-- feature phone
`-- smart phone
N[c] terminal
- 電子計算機の端末装置
- 携帯電話を示す場合は mobile phone で、携帯する接続端末は portable terminal みたいなニュアンスなんだろうか？
- 携帯電話も端末装置には違いないけど、携帯電話販売の様な文脈では phone を用いる気がする
商品
先に日本語を整理
- 商品: 売買で取り交わされる品物
- 製品: 加工された品物
N goods
- 商品
- 複数形である
- a good の用に単数にはせず、a piece of goods の様にする
N[u] merchandise
- 消費者と販売者間で用いられる goods に対して、merchandise は会社間で用いられる
N[c] commodity
- 商品
- 農業や鉱業のニュアンスが強い
N[c] ware
- 商品
- 陶器や器物のニュアンスが強い
N[c] product
- 製品
N[c] item
- 品目
- goods や product から特定の品目を明示する場合に item を用いる
An auction is a process of buying and selling goods or services by offering them up for bid, taking bids, and then selling the item to the highest bidder.
- 集合を goods と言い、落札した個別の商品を item と言っている
在庫
N[c] stock
- 完成品や商品の在庫のニュアンス
N[c] inventory
- 資材や材料等のニュアンス
可否と要否
一応整理
- 可否はして良いかどうか
- 要否は必要かどうか
許可
V accept / N[c] acceptance
- 受け入れる
- acceptance は受諾や受理
V allow
- 受動態は allowed
V permit / N[c] permit
- allow よりもフォーマル
- 受動態は permitted
- 名詞の場合は許可証
- without a permit で許可証なしに
N[u] permission
- 許可
- without permission で許可なしに（断りなく）
拒否
V decline
- 丁寧に断る
- 辞退する
V refuse
- 依頼や要求を断る
V reject
- 提案や申請の却下
- refuse よりも強い
- decline < refuse < reject
V deny
- 否定する
機能的に認めない / 権限的に認めない / 状況的に認めない
システムが特定のロジックで何かをチェックして応答を返すってのはよくある場面だけど、許可 / 拒否にも色々な種類があると思う
- チャットにメンバーを追加することができない、と表現したい
- 権限的にできないなら、permission denied とか
- メンバー数が上限一杯だからできないなら、refused とか rejected とか？
- 購入した商品をキャンセルすることができない、と表現したい
- システム的にできないなら、denied とか？
- 発送してしまったからなら、やはり refused とか rejected とか？
- decline はシステム目線だと使わない感じがする
この辺を少なくとも自分ではブレなく使い分けるには、もっと勉強が必要そう...
（追記）
refuse は拒否、reject は無理ってニュアンスという話も聞いた。要勉強。
要否
例えば、通知を必要に応じて行いたいので列挙型で表現したい場合、適切な単語は何か
僕個人の結論では、require と request のどちらかで、違いも明白
V need to / N[u] necessity / A necessary
- 主観的だったり感情を伴ったりするニュアンス
- I need you 的な
- あまりシステムでは用いないのかも？
- 形容詞になる場合は necessary で、necessary procedures で必要な処理みたいな感じ
V require / N[c] requirement
- 規則や法律的なニュアンスがあり、行動は表さない
- 例えば法的に通知の要否が決まる場合
- Requirement = Required | Not required
V request / N[u] request
- 依頼、行動を表している
- 読了メールを要求する、等
- 例えばユーザの依頼内容によって通知の要否が決まる場合
- Request = Requested | Not requested
時間
時刻と時間だけ、日本語を整理
- 時刻は一点を示す
- 会議の開始時刻は 15:00 です
- 正午や深夜
- 時間は二点の幅を示す
- 会議の時間は 30 分です
- 午前中や夜間
そこはわかりやすいけど、時間の表現は難しいよね...名付けとかでもよく迷う...
期間
N[c] period
- 期間
N[c] term
- 期間
- 特に公的、公式に決められたもの
- 任期や契約期間、懲役年数
N[u] duration
- 期間
- 持続するというニュアンス
- 通話時間や駐車時間
at, on, in
- at < on < in の順に時間軸が長い（at の方がピンポイント）
キャンセル時に削除する、みたいな処理をいつも delete at cancellation か delete on cancellation か迷うけど、特定のタイミング一点を示すには at っぽい
on は特定の日、in はもっと長い期間って感じみたいなので、月末に更新は update on end of month で、夏に値下げは price off in summer って感じ？
start / (stop)
- 止まっていたもの（こと）が再開するニュアンス
- 特に機械に対しては start
- starter は、例えば起動器
begin / (end)
- 新しいもの（こと）を始めるニュアンス
- start よりややフォーマル
- beginner は初心者
なので契約開始日（終了日）は start (stop) よりも begin (end) なのかなって思ったけど、contract starting date だと 12000 件、contract beginning date だと 4500 件ヒットだなぁ...??
from / (to)
- 何日から何日まで、のニュアンス
- 場所に用いる場合も多い
- 時間でも場所でも、開始地点を示すニュアンスっぽい
since / (until)
- from と違い過去の起点から現在まで続いているニュアンス
- 週末 9 時から受け付けは from 9 o'clock on weekends で、去年から受け付けているは since last year って感じ
- 過去から継続しているというニュアンスが強いので、何らかの検索条件やスケジュール登録の場面みたいな未来のニュアンスが必要な場合は注意が必要っぽい
前後
これも難しい...
ago とか front とかもあるけど、キリが無いので今は絞ってまとめる
before / (after)
- ある時点を起点に、過去を表現する
- java とかだと
LocalDate#isBeforeがあったりする - 変更前の住所みたいなニュアンスでは使わない
- before address みたいなのをよく見るけど、それだと住所以前
- 期間 before 起点、の形で使う
- 住所変更後の数日、を表現したいなら a few days after address update になるのかな？
last / (next)
- （今を起点に）１つ前の、というニュアンス
- ただし the が付くと最後の、という表現になる
- last week だと先週だけど、the last week だと直近７日になる
- 他には、例えば last one は前のもの、the last one は最後のもの、になる
- last day は前日だけど、the last day は最後の日であって過去とは限らない、のか
- 変更前の住所と表現したいなら before address ではなくて last address が正しいはず
- last は一連の最後を表すが、それが最後とは限らない
- 限る場合は finish の方が適切
previous / (next)
- 順番や順序の話であって、時間の流れについての表現ではない
- 前回のあらすじ、とか
- previously on Lost とか言ってるよね
- last address だと直前の住所で、別の住所を起点にそれの前を表現する場合は previous になる感じ、のはず
- 連なる住所の変更履歴をさかのぼるときは、
address.last().last().last()ではなくてaddress.prev().prev().prev()となる感じ...??
- 連なる住所の変更履歴をさかのぼるときは、
データ
追加
V add
- 追加する
-
TとTを足すイメージ - あまり前後の意味は無い気がする
- けど、一般に文字列も
+で足す表現が多いので気にしすぎなのかな...
- けど、一般に文字列も
print 1 + 2 # 3
print 2 + 1 # 3
print '1' + '2' # '12'
print '2' + '1' # '21'
V append
- 追記する
- 末尾に追加するというニュアンス
-
<T>の末尾にTを足すイメージ
xs = [1, 2, 3]
xs.append(4)
print xs # [1, 2, 3, 4]
V prepend
-
<T>の先頭にTを足す
V concat
- 連結する
- concatenate の略
- linux の
catの語源のはず
- 文字列における
+の実体は add より concat な気がする... - 数値では使わない
"java".concat("8"); // java8
作る
V create
- 創造する
- なにもないところから何かを作る
- 例えば IntelliJ の新規プロジェクト作成は create new project
V generate
- 生成する
- もともとある材料から変更や変換の操作を加えて作る
- 例えばフレームワークによくあるテーブル定義からコードを生成する様なやつは code generator
V build
- 組成する
- 比較的大きな物というニュアンスがある
- 徐々に作り上げるニュアンスがある
-
Builderパターンがまさにそれ
V make
- 一番一般的な作る
- 比較的小さな物というニュアンスがある
- src を持って来て
makeするのはいつも generate なのではないかなと思うのだけど、どうなんだろう...??-
Makefileを基にするけど材料があるわけではない、つまり創造でも生成でもない、という感じなんだろうか... - gradle や stack なんかは、build っていうサブコマンドがあるけど...
-
なんとなく create / generate / build の違いは分かるんだけど、make はいまいちピンと来ない...
探す
V search
- 探す場所を目的語にとる
- search a file はファイルの中身検索
- web search とか言うと web で検索
V find
- 探すものを目的語にとる
- find a file はファイルを探す
- 確かに linux の
findはファイルを探すな
- 確かに linux の
- 見つけるニュアンスがある
V seek
- 形が無いものを探す
- 探求とも
取得
絵で分かる〜〜みたいな記事が沢山あるので、見るとイメージが付く
V bring
- 持ってくる
- コード読み書きをしていて見たことないな...
V take
- 持って行く
-
takeWhileって色んな言語にあるけど、持って行くのニュアンスなんだろうか...??- 変数に格納するなら
storeWhileとかでも良かった...?? - と思ったけど、取り出すと言う意味もあるからそっちのニュアンスか
- 変数に格納するなら
V fetch
- 行って取ってくる
- http 通信をして情報を取得する場合は大抵 fetch を使う気がする
- db 検索でも
fetchRowsとか言うな - 外部リソースに情報を取りに行く時は fetch で良さそう
V acquire
- 習得する、獲得する
- 外国語を習得とか、顧客獲得とか
V get
ここは余談
何かインスタンスを返す処理でよくgetが使われるけど、個人的には getter の先入観が強すぎるので getter 以上の事はしない方が良いと思っている
Manifest manifest = ...;
Attributes attributes = manifest.getMainAttributes();
↑は実処理もreturn attr;なのでgetでしっくりくるけど、
connection = DriverManager.getConnection(url, user, password);
↑はgetと言うより新たに作ってないか？と言う気がする
分岐ロジックや例外処理も含んでいるし、冪等製もわからないのでgetとはなってるけど連打して良いものか判断に困る
この場合はcreateとかの方がなんというか、軽々に使われない気がして安心度が上がる気がする
それか僕ならこうしてみるかも ↓
connection = DriverManager.connect(url, user, password);
変換
IT におけるピンとくる説明がなかった...
実際はx.toString()とかDate.from(str)とかで済ましてしまうことが多い気がする
V convert
- 同レベルの物に変える
V change
- 全く違うものに変える
V transform
- 変形させる、性質を変える
選択
V select / N[u] selection
- 多くの中から選び出すこと
- 一番良い物を入念に選ぶ、吟味するニュアンスがある
V choose / N[u] choice
- 自分の意思で選ぶ
- 好ましい物を選ぶというニュアンスがある
- select より範囲が狭い
チェック
まとめ終わってみると、結構明確に使い分けられそうだと思った
V check / N[c] check / A check
- どの品詞でも check だとは、意識したことなかった
- 処理名に check を使うのは辞めようという記事はごまんとあるので割愛する
- 〜をが示されない、結果何が起きるかわからない、等の理由だったはず
- 激しく同意
V verify / N[u] verification
- プロセスである場合が多い
- ディスクへの書き込みの後に verify する
- テストや調査により製品が正しいか verify する
V validate / N[u] validation
- 妥当であるか、適切であるかを確認する
- 入力データを validate する
- 製品が規格に沿っているか validate する
- 顧客の要求と合っているか validate する
V assert / N[u] assertion
- 強く主張する、要求や正当さを主張する
- プログラミングでは表明と言い、必ず真になる式を用いて前提条件をチェックする
V confirm / N[u] confirmation
- 事前に取り決めた事実を確認する
- 入力内容を confirm する
- 予約後に confirmation mail を送る
認証と認可
ここも記事はごまんとあるので軽めに
とりあえず個人的には auth という単語は使わない使わせないを心がけている
N[u] authentication
- 認証
- id と password で本人認証をしてログインする、等
- api クラスで処理してシステム自体へのログインを指すと捉える
N[u] authorization
- 認可
- 管理者権限がある場合に新規チャットグループを作成できる、等
- 認証が通ったあと、各種処理それぞれをそれぞれのロジックで認可して機能制御をすると捉える
状態
ここも記事は沢山あるので軽め
ざっくり言うとこの様な感じみたい
status
- 表す状態
state
- 具体的な個別の状態
ServerStatus = Running state | Suspended state といった感じだろうか...??
言い回しとか
ここから先は類義対義ではなくて言い回しとかよくある間違いとかをざっと整理する
複数形
data
- data が複数形で、単数形は datum
index
- データベースの用語として用いられる index は順番に並べられた情報の集合を意味し、indexes とするのが望ましい
- 他の文脈では indices となる
- 例えばループ変数等の
Int indexを複数にするとList<Int> indicesとするということだろうか？
- 例えばループ変数等の
- 動詞として用いた index の場合、三単現は indexes になる
data, information
これらの単語は原則として用いない
単数複数がややこしいし、単語が指し示す意味がないため
employee data だと「とある従業員の情報」なのか「全従業員」を表しているのかがわからない
result
これも data とほぼ同様の理由で、変数名としてはあまり使いたくはない
StringUtil vs StringUtils
static method を書くクラスを例えばStringUtil.javaとするか、StringUtils.javaとするかは地味だけど結構気になってる
調べてみたけど、推奨される方とか非推奨の理由とかはパッとみて見当たらなかった
（似た英語の議論はあったけど、結論ははっきりしてなかった感じだった）
- haskell に
array-utilsというライブラリがあり、import Data.Array.Utilして使う - かと思えば haskell に
data-utilというライブラリがあり、import Data.Utilで使うっぽい - java の
apache-commonsにはStringUtils.javaというのがある - python に
python-string-utilsというのがある - python の
list-utilに相当するのはitertoolsかな
こうして見ても世間一般ではこっち、というのが見えない気がした
〜〜出来る
ここも先人の議論が沢山あるので、自分の興味がある範囲で軽くまとめる
can
- 能力や許可に基づき出来るか
- 持ち合わせている能力で可能か
- I can swim. は泳ぐ能力があるよ、と言う感じのはず
be able to
- 条件や資格を満たしているか
- その時点で実現が可能か
- I am able to swim. は今（水着を持っているので）泳げるよ、と言う感じだろうか
どちらを使うべきか
なので例えば厳密に考えると、能力によることや常にかわらないことは can で、主語が同じものでも状態による場合は be able to になるのだろうか？
interface ChatUser {
boolean canCreateGroup()
}
class User implements ChatUser {
@Override boolean canCreateGroup() { return false; }
}
class Admin implements ChatUser {
@Override boolean canCreateGroup() { return true; }
}
↑の様な場合は能力によって出来る出来ないが決まっていると考えらる
class User {
boolean isFileUploadable() { // 今月のアップロード容量の上限に達していない場合 }
}
対して↑みたいなのは状況や状態によって出来る出来ないが決まっていると考えられる
ただし xxxable はエディタにタイポ警告をされやすいのと、無理矢理 is から始めるとやや不自然になることもある
また先頭 is のis_locked()ではなくてlocked()にするべきだろうと言う内容の記事も沢山あるので、興味があれば
（ちなみに）
uploadable に違和感があるので、僕なら最終的にはこうするかも...
class User {
boolean isAllowedToUpload() { ... }
}
存在する
一番簡単なやり方は、java も php も python も c# も全部existsと言っているので、それに合わせれば良い
ちなみに existent / non existent が形容詞で、existence が不可算名詞
数
List<T>をTかList<T>かOption<T>にする話
複数の値を特定の条件で絞るときに、案外気になる
きっちり１つ
- exactly one
- 集合を特定の条件で絞り込み、期待する結果数が 1 の場合
List<T> = ???
T t = exactlyOne(ts, condition)
多くても１つ
- at most one
- 集合を特定の条件で絞り込み、期待する結果数が 0 か 1 の場合
List<T> -> Optional<T>
List<T> = ???
Option<T> t = atMostOne(ts, condition)
少なくとも１つ
- at least one
- 集合を特定の条件で絞り込み、期待する結果数が 1 以上の場合
List<T> -> List<T>
List<T> = ???
List<T> ts = atLeastOne(ts, condition)
否定
コーディング中にちゃんと使い分けられる程理解しているか、ちょっと自信ない
ただ、品詞を意識するだけで違ってくる気がする
not
- 副詞
- （英文法的には）be 動詞や助動詞の後ろ
- service is not available.
- 例えば終わった / 終わってないという列挙の要素名なら Finished / Not Finished だろうか
- have already finished と have not finished の助動詞が削られた形
non
- 接頭辞
- 名詞や形容詞の前
- blocking io に対して non blocking io
- 形容詞に対して non が付いている
no
- 形容詞
- 名詞の前
- no options の様に使う
演算
演算子自体をググろうと思ったりオーバーロードをしようと思ったときとかのために、単語を知っておくと調べる効率が全然違う
（最近は記号でも google 検索出来る様になったけど）
多分必ず一意な表現ではないので、数言語からピックアップして列挙する
このあたりの単語のどれかなんだろうな、って覚えておくと良いはず
演算子
- operator
- operand は被演算子で、演算の対象となる値の方
加算
-
+とか
| 日本語 | 英語 | 言語例 |
|---|---|---|
| 足す | add | python |
| 足し算 | addition | |
| 足す | plus | groovy |
| 和 | sum |
減算
-
-とか
| 日本語 | 英語 | 言語例 |
|---|---|---|
| 引く | sub | python |
| 引き算 | subtraction | |
| 引く | minus | groovy |
| 差 | difference |
乗算
-
*とか
| 日本語 | 英語 | 言語例 |
|---|---|---|
| かける | multiply | python, groovy |
| かけ算 | multiplication | |
| 積 | product |
除算
-
/とか
| 日本語 | 英語 | 言語例 |
|---|---|---|
| 割る | divide | python, groovy |
| 割り算 | division | |
| 商 | quotient |
剰余算
-
%とか
| 日本語 | 英語 | 言語例 |
|---|---|---|
| 剰余 | modulo | python, groovy |
| 余 | remainder |
>
- shell や perl で言う gt
- a is greater than b
- html の
>
>=
- shell や perl で言う ge
- a is greater than or equal to b
<
- shell や perl で言う lt
- a is less than b
- html の
<
<=
- shell や perl で言う le
- a is less than or equal to b
>>
- python や groovy で言う right shift
<<
- python や groovy で言う left shift
&
- ampersand
- まれに
&という演算子がある言語があるので、記号名を覚えておいて損はない
- まれに
|
- vertical bar
- Unicode では vertical line と言うみたい
- pipe は linux のプロセス間通信の仕組みであり、それに
|を用いるだけで記号名ではないみたい
おしまい
ざっと単語並べるくらいにしようかと思ってたけど、それだと身につかないし価値もないのでこうなった。
ネットの記事だけがインプットなので、言い換えればこれと同じ内容は調べればわかる。
ので新たな発見を生む記事でもないだろうし、もっと良い記事がごまんとある。
けど僕は学べたし、なにより面白かったので良し。