テーマ、知りたいこと
boolean型の変数名に〜flgとつける人をどう思いますか？
背景、状況
boolean型の変数名は、is〜、can〜と付けた方が、
その変数が真のとき、どういう状態か分かり易いよと何度も言っているのに、頑なに〜flgと命名する人がいます。
私はこういう人とは一緒に働きたくないと思いますが、みなさんどう思いますか？
回答39件
#1
総合スコア517
投稿2025/01/17 12:03
編集2025/01/17 12:04あなたの意見に同意します
isはわかるけど、hasも使ったことあるけど、canはわかりづらいかな
#2
総合スコア517
投稿2025/01/17 14:17
ちなみに、flgと書くのは古いプロジェクトの慣習を引き継いでいるだけと思います。
#3
総合スコア10228
投稿2025/01/18 03:38
もし、それで困ることがあるのであれば、規約やルールとして決めておくべきでしょう。
そうでないのであれば、可読性が低いほうを選ばれたとしても仕方がないと思います。
#4
総合スコア1456
投稿2025/01/18 03:55
あなたの意見に同意します。
ただ、isXXXのルールが守られていたとしてもisNotXXXとかの肯定と否定の変数が混在するプログラムは嫌いです。
ところで、isXXXFlgとかはどうなんでしょうね？
頑なに～Flgを付けたい人に対しては、～Flgにしてもいいけどとりあえず接頭辞にisを付けてくれと言えば納得してくれるのかな？
#5
総合スコア517
投稿2025/01/18 05:41
編集2025/01/18 06:06例えばクラス名やインスタンスがflagという接尾辞のついたものなら、特におかしく感じない
もしもflag(flg)が人間の直感に合っているなら、ドメイン駆動設計とか宣言型プログラムみたいに、やりたい結果を重視するような文脈であれば、
何らかの処理を示すためのflagとして宣言しているということが構造上わかりやすいんだと思う。
読み手としてはそれがどこから来てどこに行くのかを知りたいという話だから、何とか両立できそうな気もするし逆に相容れないかもしれない。
プログラムは設計図という考えとプログラムは生きているという考えがあると思っていて、
設計図という考えは、1度作ればコンピュータが勝手に複製も実行もしてくれるから(実際の工業に当てはめた考え方)
この設計図の考え方は大きく同意するけど、多分自分みたいな若者は初っ端から大きいプログラムに触れるだとか、古いシステムを改修するだとかの経験から、flgとかいう意味の推測できない方法はやめね？となるのだと思う。
まあ、強いものが強者ではなく、環境の変化に耐えられるものが強者とかいう自分が中学生くらいの頃に聞いた言葉を引用していいのであれば、解決方法は自分がflgになれることな気がする。
まあ、意見としては質問者さんに同意だけど！
それと質問の本質とはズレるけど、flgみたいな略語は表記揺れする未来しか見えないので好きじゃない
#6
総合スコア14035
投稿2025/01/18 06:00
編集2025/01/21 04:59boolean型の変数名に〜flgとつける人をどう思いますか？
構わないと思う。 場合によっては自分でも使う。
その変数が真のとき、どういう状態か分かり易いよと何度も言っているのに、頑なに〜flgと命名する
これを聞いてもisの方が良いとは思えない。 どちらも対して変わらない。
チームで開発しているのであれば、変数の命名規則はある程度統一していたほうがいい(ここも議論の対象になりそうではある)ので、チームとして意思を統一して、必要であれば明文化すればいいと思う。
ただし、その結果チームとしてその必要は無いという結論になるのであれば、受け入れるべきだし、そうなる可能性は大きいと思う。
#7
総合スコア86160
投稿2025/01/18 13:43
編集2025/01/20 18:10boolean型の変数名に〜flgとつける
「boolean型」という漠然とした話であれば、強いて言えばシステムハンガリアン記法的で止めた方が良いとは思いますね。それ以外は何も思わない。システムハンガリアンは私は自分では使いませんが、システムハンガリアンで書いている赤の他人に「絶対止めろ」というまではしないです。
ただ、おそらく、is～や～flgが、「～という状態である」という意味を持つ前提での質問でしょうから、その場合はisの方が肯定であることが明示されるのでそちらが良いかと思います。flgは～との関係が明示されていない。接頭辞か接尾辞かはどうでも良いですが、isだと自然に接頭辞になりますね。
その変数が真のとき、どういう状態か分かり易いよと何度も言っているのに、頑なに〜flgと命名する人がいます。
これの理由はいろいろ考えられます。
① その人が頑固（他人の意見で自分の意見を変える習慣がない）
② 何らかの理由で～flgの方が良いと思っている
③ ①と②をあわせたようなものですが、あなたの説明がその人から見て納得性がない。「is〜、can〜と付けた方が分かり易い」という結論だけ言うのじゃなくて、その理由をどのように説明されたのか分かりませんが、その説明された理由に共感が得られなかった。そもそも違う考えの人を説得するのは難しいです。相手が「他人の考えを取り入れて自分をより高めよう」という意識を抱いていない限りは、説得者がその道のプロ的な人でないと。別にあなたの説得方法が良くないと言うことではなくて、「他人の考えを取り入れて自分をより高めよう」という意識をもってない人に対しては、私も説得出来ないと思います。「他人の考えを取り入れて自分をより高めよう」という意識がある人になら説明の仕方によっては可能かも知れませんし、議論の結果として第三の結論に両者が合意するかも知れません。
念のために書いておきますが、「~flgがシステムハンガリアン的なので良くない」というのはそれを使っている人に対しては全く説得力が無いので、言わない方が良いです。
私の書いた範囲で説得に使えるかも知れないのは「isの方が肯定であることが明示されるが、flgは～との関係が明示されていない」くらいですかね。ただおそらくすでに説明されたことだとは思います。
論理型のシステムハンガリアンはどう書くのだろうとWikipediaを見てみるとbかfでしたが、例がbDirtyFlagだったのは笑うところか。
https://ja.wikipedia.org/wiki/%E3%83%8F%E3%83%B3%E3%82%AC%E3%83%AA%E3%82%A2%E3%83%B3%E8%A8%98%E6%B3%95
#8
総合スコア642
投稿2025/01/20 13:57
「チーム内でどのようなルールがあるか」ですかねぇ…
例えば「整数か分かりやすくするために、変数名の先頭はiにする」といった、
正直必要か…？と思うようなルールが決まっている場合もあります。
個人的には「フラグ変数であることを明記したかった」という背景があるのかなぁ…とは思います。
個人的な体験談では、型エイリアスなどで同じ感情を持ったこともあります。
ただ、こういうのは意外と社内ルールや顧客との取り交わしに含まれていたりもするので、
- 取り敢えずは大人しく従っておく
- 機会を見付けて問題提起→改善していく
の流れが無難だとは思いますね。
現状主流な考え方ですので、素直に受け入れてくれる方が多いかとは思いますよ。
何よりも仕事は個人の感情で動くものではなく、チームで進めるものですので。
#9
総合スコア14035
投稿2025/01/20 14:57
以下の話は、特定の誰かについての話ではなく、単なる個人の見解として見ていただだければ。
「～の方が分かり易い」とか「～したほうが改善していく」のような意見を聞くことがよくありますが、どのような場合にも正しい方法のいいのは存在しないと思っています。「整数だからiを付ける」とか「フラグだからflgを付ける」という方式だって、それなりの意義も効果もあると思います。
チームで開発しているとあらゆる意味でいろいろなレベルの人が一緒に仕事をすることになるわけで、他にもそういうことはたくさん発生/存在するものです。そういうところは適当に(適切に)、肩肘張らずにやっていくのがいいのではないかと思います。
#10
総合スコア82
投稿2025/01/20 23:22
can〜じゃなくて～ableが多い
readable, writable。。。
#11
総合スコア1
投稿2025/01/21 00:00
個人的には主語なしのisは言語感覚として不可ですね。プロジェクトで強制されるなら反対意見を出すレベルです。
主語があれば親切な命名だと感じます。
#12
総合スコア9
投稿2025/01/21 00:01
自分だとbooleanはis固定というのも、英語としてしっくりこない時があるので、
ts
1let showsStatus: boolean //ステータス表示フラグ
なり
ts
1type Employee { 2 \* 社員データ *\ 3 toBe Displayed: boolean, //表示フラグ 4}
とかしますね。
#13
総合スコア25
投稿2025/01/21 02:34
前提としてチーム内で命名規則を統一するべきだとは思いますが、大事なのはisやcan、flagという部分ではありません。
例えばpost済みであるかどうかの状態を表すなら、postedのように命名すればtrueの際にpost済みである事は自明です。
何かの可否を表すならviewableやavailableのようにXXableとするのも良いでしょう。
また、上記はクラスのメンバー変数名や関数名での話ですが、単純な関数の中の変数の話であれば主語を付けた方が良い場合も多いですね。
重要なのは「isやcanで統一する事」ではなく、「それが何を表しているのかを分かりやすく表現する事」です。
その上でプロジェクト内のソースコードに統一感を持たせる為に「状態を表すものにはisを付ける」といったルール決めを行い、「プロジェクトのルールだから従って欲しい」と強制力を持たせましょう。
「こちらの方が分かりやすい」という説明は反対意見を持っている人には響きませんから、強制力を持って対応するのが一番良いです。
個人的な意見としては、キャメルケースやスネークケース等を統一する事、具体的で誰が見ても何を表しているのか分かる事、の二点さえ守っていればある程度柔軟にして良いと思います。
#14
総合スコア7
投稿2025/01/21 03:12
flgは過去に嫌な思いがあるので使いたく無いです、
新人のプログラム（タスク）に応援に入り、
内容を見たら状態の変化にenumを使わずに
flgを必要以上に使って、自分でも管理できなくなっていた、
局所的対応をしているうちにflgが増えていった
とのことでした、
全部コードを捨て作り直しました、期限が2日
しかなかったので地獄でした。
状態遷移をflgで管理するのは、反対です。
#15
総合スコア312
投稿2025/01/21 03:44
どうでもいいとか思ってしまう、ルールがきまればそれに従う、
名前なんて初心者からベテランまで、いろんな人が口を出せるから、話がまとまらなくて大変です。（プログラムしない人も意見をいってくることもある）
よくあるソースを読めなかった自分が悪いのではなくて、ソースを書いた方が悪いにしたいとかがベースにあったりするとさらに大変です。
わかりやすい名前は大変よいが、単にisをつけて勘違いするような名前が生まれる場合は、名前からわからないほうがましとか思ってしまう。わからなければソース読むでしょうし、勘違いする場合は、長いこと迷走するから
#16
総合スコア12074
投稿2025/01/21 04:32
編集2025/01/21 05:07boolean型の変数名に〜flgとつける人をどう思いますか？
別に何とも思わない．
その変数が真のとき、どういう状態か分かり易い
とのことだが，そんなの is と flg とで差があるとも思えない．
状態が｛ Aである，Ａではない｝の２パターンしかない場合にそれを「Ａフラグ」なるもので表そうという話であれば，
フラグ値と状態との対応関係は，どう考えても普通は「trueならＡである，falseならAではない」とするでしょう．
（そんなところで「わかにくい！」とか言い出す側の方がどうかしてるとすら思えるくらいだが……？）
どんなに洒落た名前を付けてみたところで，それが「フラグ」であることには変わりないならば，「ＸＸＸフラグ」っていう名前にしとくのが最も素直であり分かり易い……という考え方だってあり得るのでは？
【「フラグ」っていうのは，こういうもののことだよ】っていう共通認識が存在する場においては，is とかいうただの英単語よりも flg の方がより具体的な 意味合い/用途 を示す命名と言えるかもしれないよね．
（もちろん 「is ってのは…」という共通認識が場にあるならば差が無い）
個人的には，これ系のやつは，末尾よりも先頭側にあった方が（：真っ先に目に入る方が）意味把握の助けになりやすい気もするので，
その点においては，先頭側に付くタイプである is とかの方がちょっとだけ好みではあるかもしれない．
でもそれを理由にして flg を排斥しようとか思わないな．
#17
総合スコア624
投稿2025/01/21 07:29
編集2025/01/21 07:34そういうことをしたいのでしたら linter 等によって予め制限すべきことではないでしょうか？
ts
1/* eslint @typescript-eslint/naming-convention: ["error", { 2 "selector": "typeProperty", 3 "format": ["camelCase"], 4 "types": ["boolean"], 5 "custom": { 6 "regex": "^(is|has|can)", 7 "match": true 8 }, 9 },{ 10 "selector": "typeProperty", 11 "format": ["camelCase"], 12 "types": ["boolean"], 13 "custom": { 14 "regex": "[f|F]la?g$", 15 "match": false 16 } 17 }] */ 18type Type = { 19 stateFlg: boolean; 20}; 21
例えばこれだと boolean 型のプロパティに is|has|can 始まりが強制され 末尾 flag|flg が禁止されるので
boolean 型の stateFlag は エラーとなります。
#18
総合スコア83
投稿2025/01/21 07:45
チームで行うならflgは避けるべきでしょうねぇ。
個人ならどうでもいいですが。
is～flgに関してはflgいらなくね？ってなりますし。
flgと書く人は｢そこまで困ったことが無い方｣なのではないでしょうか。
排斥するのではなく､まずは作成前のミーティングで
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
・is：状態を表す（例：isActive, isCompleted）
・has：所有や存在を表す（例：hasError, hasData）
・can：能力や可能性を表す（例：canView, canEdit）
・should：推奨や必要性を表す（例：shouldRetry, shouldDelete）
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
を提案してチームで共有すべきではないでしょうか。
チームの多数決でflgでもいいんじゃね？ってなったらそこの会社辞めたらいいと思います。
#19
総合スコア12074
投稿2025/01/21 08:43
flgと書く人は｢そこまで困ったことが無い方｣なのではないでしょうか
誰かに flg と命名されたことで困った経験というのが無いので，そこのところを知りたいのですが，ご教示願えませんでしょうか．
誰かに flg と命名された場合， どのように/どれだけ 困ったことになるものなのでしょうか？
（その困った状況というのは is にリネームするだけで魔法のように解決するという話である様子ですが，想像つきません）
#20
総合スコア12074
投稿2025/01/21 09:16
編集2025/01/21 10:55あんま関係ないけど
ActiveFlag,VisibleFlag← これはキモイがisActive,isVisible← これも同レベルにキモイんですが
……っていう感覚は私だけなのかな．
単に Active, Visible じゃいかんのか？ と．
XXX_flg っていう名前を付けることそれ自体が悪いんじゃなくて
そういう名称にしようとすると XXX の部分がなんか「足りてない感じ」になり易い(?)…のかな？ という気もする．
（XXX だということだけはわかるが，だからどうした？ というあたりが）
例えば，あるフラグが立っていることが意味するところが
【エラーが起きた結果として，今現在，｛モジュール/インスタンス/プログラム｝の状態が，正常時とは異なる「エラー状態」に入ってしまっているよ】
みたいなことなのであれば， ErrorFlag という名前だとちょっと不足かもしれない．
【「エラー状態」に入ってしまっているよ】ということを示したいのならば InErrorState とか，何かもっと違う言い方があるよね，みたいな．
is という語を使う｛文化(?)，ルール(?)｝の元だと，自然と(?) isInErrorState だとかそういう言葉になり易い…のかな？ という気がする．なんとなく．
（hasError とかになってしまうようなら意味ない．）
#21
総合スコア419
投稿2025/01/21 10:44
boolean型の変数名に〜flgとつける
boolean型の変数名は、is〜、can〜と付けた方が、
五十歩百歩。
片方が気持ち悪いなら、他方も同程度気持ち悪いだろうと思います。
私はこういう人とは一緒に働きたくない
別に何とも。
ひょっとすると「『一緒に働きたくない』理由を探しているだけ？」って思うかも。
#22
総合スコア86160
投稿2025/01/21 16:58
#11 Kazzzさん
個人的には主語なしのisは言語感覚として不可ですね。
なるほど。
is～という名前なので、オブジェクトのプロパティーかメソッドだと思い込んでましたが、質問文にはそうとは明示的に書いてませんね。
foo.isXXXXとかには違和感ないですが、独立した変数の名前であれば、主語無しisXXXXはあり得ないというのには賛成です。狭い有効範囲の名前で主語が自明な場合は良い場合もあると思いますが、それだとisは要らないかも。
独立した変数で、主語を書くとしてshugo_is_keiyoshiとshugo_keiyoshi_flgとどっちがいいかの2択なら前者かな。自分で自由に書くとshugo_keiyoshiと書く気もしますが、まあ、こんなものは事前にルール化せずにケースバイケースですね。もしルール化するなら適用範囲を狭く限定してそれ毎に決めるか。
（具体例を書くとその具体例に引きずられそうなので、shugo と keiyoshi と書いてます。また初級プログラマー多数参加の場合は広くルール化した方がいい気はします）
#23
総合スコア140
投稿2025/01/21 17:15
#7 に同意です。
一般論として 論理型変数の名前に flg （ flag ）のようなサフィックスを付けた場合、その値が真/偽の場合に何を指しているのか直感的で無い事から避けるべきだと思います。これに関しては、質問者のhatena99さんに同意します。
ただし、此処で考慮すべきは、「指摘に従わない同僚を自分はどう思うか」ではなく、 「何故、指摘が無視されているのか？」 ではないかと考えます。指摘に納得出来ない妥当な理由が有るのかもしれません。単に貴方の伝え方が悪く上手く伝わっていないのかもしれません。もし、そこを追求せずに「私はこういう人とは一緒に働きたくないと思います」と言っているのであれば、失礼ながら、私は質問者のような方とは一緒に働きたくないと思ってしまいます。直接やりとりすると角が立つかもしれませんので、別の同僚や上司に間に立ってもらって確認したり、調整した方が良いかと思います。
（本題からは少し離れますが、論理型変数の名前として is〜 や has〜 を使うのも、〜flg よりはマシとはいえ、あまり美しくないと感じます。論理型の値を返す関数・メソッドと名付けルールが被るので。可能ならば形容詞や過去分詞を採用しますが、必ず採用出来る手段という訳でもなく、苦し紛れに is〜 や has〜 を採用せざるを得ない事が多いのですが。世の開発者の方々は、どう対処しているのだろうと何時も気になっています。）
#24
総合スコア978
投稿2025/01/21 23:04
私もトピ主と同じく～flgは使わない派です。
周りの人間はあなたと同じ様に自己改善や向上心のある人ばかりではなく
あなたが良かれと思った行為が暖簾に腕押しで失望されているのでしょう。
自分以外の思考や行動を変えるのはものすごく大変です。
同じ考えの人を集めて ～flgを使わないという流れを作っていけば
どこかのタイミングでころっと全体が変わることを祈るばかりです。
頑張ってください。
#25
総合スコア7834
投稿2025/01/22 00:34
大事なのは一貫性、古いやり方やローカルルールであろうと、すでにプロダクトがboolean型変数は接尾辞flgをつける形で統一されているならそれに従うべきです。
そうでなく、その人だけがルールを守らないのであればlinterで強制しましょう。機械的に強制されないルールは破られるものです。
#26
総合スコア12074
投稿2025/01/22 01:35
状態が｛ Aである，Ａではない｝の２パターンしかない場合にそれを「Ａフラグ」なるもので表そうという話であれば，
フラグ値と状態との対応関係は，どう考えても普通は「trueならＡである，falseならAではない」とするでしょう．
（ここの意見の他に，ちょっと気になって適当にググったりしてみた感じ）
どうやらこの私の感覚は世間とはズレている模様．……ということがわかったのは収穫かな．
世の中の 一定数？/大多数？ の人達が
「trueならＡである，falseならAではない」
とは認識しないということなのであれば，「XXXフラグ」なんて言葉を（コード内の名称に限らず）安易に使わないように注意する必要がありそうだな．
#27
総合スコア167
投稿2025/01/22 01:52
読んで分かるなら、他人が書く分にはどちらでも構わないが、自分は邪魔だとしか感じないのでわざわざflgは付けない。is・hasも冗長に感じる時もある。enabledをisEnabledとは書かない。
ちなみに、flg使う人はbool(boolean)ですらない事が時々あるので、そういうのはグーで殴りたくなる。
#28
総合スコア13
投稿2025/01/22 02:19
編集2025/01/22 02:32バックエンドにいる時は~flgでしたが、フロントエンドになってからis~になった印象がある。
回数を入れるときにnumber~にするか~countにするか悩んだのを思い出す。
個人的に新しくなればなるほど、英語圏に近づいているような感じがする。
英語圏 is~, number~
日本圏 ~flg, ~count
#29
総合スコア517
投稿2025/01/22 04:20
好き嫌いじゃなくて、何がいい悪いという文脈だったら、
flgの代わりにa1とかa2とか、なんの意味も持たない変数名でもいい気がしています。
(短いスコープの)変数なんて全部使い捨て。
手続きが長すぎて何をしているのか分からないなら、関係ない手続きはprivateに分割してないのが根本的な問題。
でも、一概にそうとは言えないのかな、とちょっと思って質問をするか迷い中。知らない分野の難しい処理とか読むなら、適当に付けられてたら処理のセオリーとか知らないから。
なんでもいいだろ！的な主張をハッキリしている回答がなかったように感じたけど実際はどうなんだろうか。
なにかの理由でスコープが増えて重要になってしまった変数は一括で名前を変えればいい(そんなことあるのか知らないけれど)
そもそも、人のコードを信用して変数名から状態を推測しようとするのってめちゃくちゃ危険では？
Flgがキモイからisにしてくれ！ってわざわざ突然言いに行ってるならめっちゃマヌケじゃん
#30
総合スコア83
投稿2025/01/23 00:37
#29 utm.さん
そもそも、人のコードを信用して変数名から状態を推測しようとするのってめちゃくちゃ危険では？
めっちゃ共感しました。
例えis～がわかりやすいからといっても､何かあった時結局一応どうなってるかチェックするからflgでもisでも｢無意味｣な気がしますね。
#31
総合スコア12074
投稿2025/01/23 02:27
編集2025/01/23 02:40なんかわからんけどもそんな
フラグ管理という実装方法を選択していて，
且つ，そこは相応に解読困難な処理なのであって，
且つ，そのフラグの名称が is～ なのか ～flg なのかがその解読難易度を（わざわざ言及するほどに）左右するようなもの
…とか書いてるなら，「そのフラグの名称がどうの～」とか言うよりも前に考えるべきことがたくさんありそうな気がする．
なんというか，~flg と書いている相手に言うべき事柄というのは「～flg という名前はやめろ！ is～ にしろ！」とかじゃなくて，もっと全く別のことなのではなかろうか？ ……とか．
（相手への 指摘?/要求?/etc の仕方というのが，的を射ていない感じになっちゃってるのではないかな？）
#32
総合スコア37207
投稿2025/01/24 09:28
編集2025/01/24 09:48「booleanの変数名に〜flgとつける人をどう思うか」というのは仕事におけるコミュニケーション論であって、「booleanの変数名に〜flgとつける事をどう思うか」と切り離した方がいいかと思います。
そして、ご質問のタイトルや「背景、状況」をお読みする限り、前者なのだろうな、と感じました。
個人的には、その方との関係次第なのではないかな、と思いました。
その方との関係性が薄く、仕事における指示系統が別である場合、「え、この人、急にどうした？ 安易に従ったら他にも細かいことに口挟まれるかもしれんな、聞き流しとくか」となるかもしれません。
hatena99 さんとしては、十分な関係性があり適切な距離感でアドバイスしているのかもしれませんが、人間関係の距離感というのは人によって異なります。もしかするとその方にとっては近すぎる距離感だったのかもしれません。
また、アドバイスを流されたからといって嫌いな人を作っていると、職場のソーシャルグラフが狭くなり、hatena99 さんにとってもよいことばかりではないと思います。
まずは、関係性を深めてみてはどうでしょうか。
おそらく、この回答はあまり気持ちよく読めないだろうと思います。まことにアドバイスと言うのは難しい……
#33
総合スコア86160
投稿2025/01/26 09:18
#32:
そして、ご質問のタイトルや「背景、状況」をお読みする限り、前者なのだろうな、と感じました。
皆さんのコメントの対象がばらばらなので、質問者が「聞きたいのはこれ」と、整理してくれるかと待ってたのですが、全然ですね。
#7の真ん中あたりに少し書きましたが、どうしたら良いかという相談であれば、
個人的には、その方との関係次第なのではないかな、と思いました。
で、「あなたが上司で相手が部下」「相手が上司であなたが部下」「ほぼ同格のチームメイト」「あなたはそこそこ経験があり、相手が後輩」「相手がベテランで、相手から見るとあなたは経験が足りない若者」とかいろいろ考えられて、どういう動き方をすればよいかはケースバイケース。
「コーディングルールやツールで縛ったらいいのでは？」という意見も出てますが、そもそものあなたの目的は何なのか？相手が納得しなくても上司として強制できればいいのか？相手を納得させたいのか？チームでネーミングルールを作ろうとしていてその検討を決着させたいのか？など、目的をしっかり言語化すれば、あとはその目的を達成するためのプロセスを設計して実行します。
そういう「何らかの目的を達成したい」ということじゃなくて、単に「こう言う人どう思う？」とアンケート的な質問であれば、#7の最初に書いたように「なんとも思わない」ですね。
「『～である・～でない』についてのネーミングはどうしたらいいか？」についての自分の意見も書きましたが、こういうのは一般論で聞けば10人いれば10種の意見ありと思った方が良いです。分野・対象を絞れば意見の種類は減ると思いますが。
#34
総合スコア65
投稿2025/01/27 02:01
う～ん、設計レべルで、「支払済フラグ」を「支払済」って書くと分かりずらいんだよね。すると、その実装はIsPaidFlg としちゃうことが多い。
日本語でも英語でも boolであることが明瞭でないと、なかなか受け入れられない。そう言う意味で flgは便利。kbnとかも良く使う。
#35
総合スコア82
投稿2025/01/27 06:37
flgの代わりにa1とかa2とか、なんの意味も持たない変数名でもいい気がしています。
そもそも、人のコードを信用して変数名から状態を推測しようとするのってめちゃくちゃ危険では？
それを言ったら元も子もない
これってコードの可読性をあげるための施策なので、
a1 や a2 とかでプログラムを組まれると、
他の人が読みにくくて仕方ないかと
変数の内容を疑ってかかるのは当然として、
変数名にそぐわないコードが書かれていたら、そこも指摘すべきと
#36
総合スコア22
投稿2025/01/28 00:46
編集2025/01/28 00:49エントリレベルのメンバーが対象で、「is〜」「has〜」という可読性を上げるコードの書き方を知らないのであれば、伝えるだけで済むと思ったのですが、そうじゃなかった。（かつては私もそうでしたと、遠い目をしながら回答しようと思って来たのですが）
それを知ったうえで頑なに変えるつもりがないという前提であれば、その個人を責めることなく行動変容を促すにはどうすればよいかをチームの問題として本人を含めて考えていくかな？
コードはどのようにも書けてしまうので、そのように書くことを個人の意識に期待するよりは、コーディング規約やレビュー・PRで、そうしたコードを「通さない」ように整備するのがチームで仕事をするということなので。
どのように思うか？という感想的なことを言うなら「この人、頑固やなぁｗ」という感じです。
#37
総合スコア1096
投稿2025/01/28 03:26
（あなたがわたしの部下ならこうアドバイスすると思います。）
自己分析
「私はこういう人とは一緒に働きたくないと思います」と思った感情を調べてみることですね。負の感情は好ましくありません。組織に不和をもたらして仕事が円滑に進まなくなることが多いから。自己分析を勧めます。その感情は何か別のことを意味していないか、なぜここに投稿したのかも含めて、冷静に自分自身を見て下さい。私の場合は自分が◯◯ゆえにその感情が生じていると思うことが多いです。
質問(たとえば)
- プログラミング言語がbooleanをサポートすると何がよいのかを考えてみましょう。
- booleanを持たない言語も存在するわけですが、フラグを使う場合の注意点は何ですか。
フラグはハードウェア仕様やネットワーク電文に登場しますか。フラグの値範囲は仕様書に明記しますか。 - 自然な英語に近づくように命名するとしたら、SVOに該当するものがプログラムに表されていなければならないはず。それは変数ですかメソッドですか。具体例を考えて下さい。
よく知っているつもりでも調べ直すことを勧めます。
対話
「こういう人」と対話してください。対話は説得ではありません。相手を尊重しなければ対話は成り立ちません。
#38
総合スコア1096
投稿2025/02/16 00:46
#37 補足
◯◯とは
先入観を持たれないように◯◯としましたが、私の場合ほとんど「無知」になるかと思います。「未熟」も考えられますが「無知」に起因するとすればひとつです。
その感情が自分の身を守るために自然に起こるとすれば悪とは申せません。感情がなくなるために、どんな前向きな行動をとればよいのかを考えてみることですね。
SVO
SVO型は語順にかかわる類型です。SVOはちょと大袈裟でしたね。
boolean型の変数の命名isXXXは、なぜそうなのか英語話者のつもりで想像すると、
x.isValid // x is valid. 主語はインスタンス x。x の状態を表す。
しかし、厳密に適用しようとするとすぐに破綻します。(別な表現も考えられますが ... )
~x.isValid // not x is valid. -> x is not valid.
メソッド名に動詞原型を使うものがあります。これは使役表現とみて、
x.execute() // let x execute. 主語は、メソッドexecuteを駆動する不特定なオブジェクトと考えられます
大雑把ですが命名に関してこのように考えてみました。英語表現がそのままプログラムに変換可能とは申しませんよ。
isXXX命名法は業界の共通合意だと思います。ここは早く通り過ぎて重要な問題に取り組んでください。
あなたの回答
tips
プレビュー
バッドをするには、ログインかつ
こちらの条件を満たす必要があります。