我是想说形容词+静态类型感觉加个 is 有点多余了，像 C＃默认属性很多 Enabled 这样的

主要是因为命名是件很麻烦的事情，加上 is 可以降低与其他命名冲突的可能性，就这个优点已经值得加上了。

一是这个名称的本身含义，二是防止冲突。

不喜欢 is 你可以 if...一眼就能看出这个变量是啥啥啥呀

提高代码的可读性和维护性
增强代码的表达力和清晰度

看情况，有时候我会写
has_been_xxx
hasBeenXXX
can_do_xxx
canDoXXX

避免歧义、准确表述最重要。该用 is 时就用 is ，该用短语就用短语，没必要畏手畏脚。

看代码不一定要 ide 吧，看到 is 就知道是 bool ，一目了然

看个人习惯或者团队要求，统一就行，别有的有有的没
顺便一说对于 java 来说绝对是多余的，因为访问需要走 isXxx ，再加一层就会变成 isIsXxx

主要是添加语义和防止冲突，不然你在做很大上下文的情况下，容易搞混

写 js 时候用

这是否也是一种匈牙利命名法

可以让代码更接近语言,我就很喜欢用很长的命名方式,尽可能描述信息

有必要，你也不想 isSetName 与 SetName 分不清谁是谁吧？

isChild 与 child 歧义就大了。

虽然大多时候可以通过 if(!name()) 强转判断，但有明确的类型岂不更好？

加 is 本身没有问题，有问题的是在本身语义就是布尔的名字前面加了一个 is ，比如 enable 、deleted 等

1.这是语义化、可读性的要求，有助于看名知意，否则读代码时，你需要先查看类型再思考含义？
2.也不都是 is, 还有 can, has, -able, 等等，共同点是接近英语用词。 如：isAnimal (这里不用 is 就不能良好表达含义) isRunning, hasEmail, available, callable
3.也有不用这些词缀也很合理的场景。如：expired, running, exists

总之，懂点英语，就不会困惑了。

isEnabled 是一个很规范的写法吧，像苹果就大量使用这种变量名

搜了以下代码库,有一个例子: BOOL IsClient, 不用 "Is" 的话，Client 变量歧义会不会有点儿大啊。 别人看到第一印象肯定不会认为它是一个 BOOL

isEnabled 这种形容词前面还加 is ，是否略微繁琐了一些
写在代码里面语义个人感觉 Enabled 更舒服

if Enabled {
xxx
}

楼主想说的：1. 强类型 -> 静态类型； 2. 形容词前面加 is

形容词前面加 is ，确实是没必要，有的时候甚至会造成问题，比如 enabled / running ，没必要写成 isEnabled / isRunning

前端一些约定俗成的boolean变量不会加，比如loading show等。
其他的也都会加is has之类的前后缀，即使使用的是 TypeScript 注明了类型

如果是形容词性的表语，不加 is 也可以清晰表达语义，但名词性的表语不加系动词基本上就是可读性的噩梦了。

那有没有可能，不规范的是苹果

IsEnabled 可以说是冗余，Enabled 就可以。
但是 IsName 和 Name 就是完全不同的含义了。

不过个人认为只要不是名词应该都不需要加那句多余的 Is 。

见名知意
也可以 can/need/has 等等表判断语气的前缀开头，不加可能产生歧义，加上更明确，那干脆就加

参考上古匈牙利命名法的历史

我一般都加一个 check 前缀，其实返回值就能区分了，你不能 isname 返回值是个 string 吧，不得事 bool 么。

多敲俩字母不费事，但能省事儿。找了一个我写的类
[ObservableProperty] private string _Title = string.Empty;

[ObservableProperty] private bool _HasChanged;

[ObservableProperty] private bool _Completed;

[ObservableProperty] private bool _CanMeasure;

[ObservableProperty] private bool _CanSave;

[ObservableProperty] private bool _CanRefresh;

[ObservableProperty] private bool _IsPaged;

[ObservableProperty] private bool _HasNextPage;

[ObservableProperty] private bool _HasPrevPage;

[ObservableProperty] private bool _HasTextFilter;

[ObservableProperty] private string _Keyword = string.Empty;

建议代码里的 bool 值基本只用 is ，has ，can 这些前缀就足够了，数据库字段命名也是如此，不要用 check 这种的意义不明的前缀。另外，不要反义词，比如用 isEnabled ，不要用 isDisabled 这种。

dog.isAnimal 一看就是 bool
dog.animal 不是很懂想表达什么

类似的还有数据库字段命名：
company.creator_id 一看就是 ID
company.creator 不知道到底是 ID 还是对象

像你说的 Enabled 这种一般不会加 is ，没必要。

不多于啊，我看变量 我怎么一眼就知道是 bool 类型呢

先看框架语言，如果框架语言都使用 is 那就加 is 跟框架对齐，比如 js 、c＃。
再看词性，本身就是 adj 不会引起歧义就可以考虑不加，比如 enabled ，activated 。

咋就冗余了，打英文 is running 和 is enabled 不都是正确用法吗

我记得 java 语言某些语言框架默认 boolean 的 set/get 方法使用 is 开头，导致如果错误的使用 is 开头方法反倒会出问题

Ruby 看着你们讨论这个笑而不语, 直接在变量后面加一个问号

1. 毫无冗余。

2. 不加 Is 是制造歧义。

   我个人觉得是冗余了，所以我不用。
   类似地，我也很少在后面加 data 或 info

   个人感觉，现在加不加 is 都无所谓，反正一眼能看出来。

   “这他妈谁写的狗屁！”
   “我擦我写的，三年前”

   看个人习惯，有的喜欢直接明了就会加 is ，有的喜欢简洁一点，就会省去 is 。

   systemctl is
   is-active -- Check whether units are active
   is-enabled -- Check whether unit files are enabled
   is-failed -- Check whether units are failed
   isolate -- Start one unit and stop all others
   is-system-running -- Query overall status of the system

   这比 bool_xxx 好多了吧

   哼！语义上的那都不叫事
   上古代码还有很多这种表示类型的
   szPath
   strAddress
   dwFlags
   cbSize

   对于 boolean 的属性，也就是类型是bool的变量、字段或属性，isXxx 没什么不好的，而且还能统一清晰的让人知道这个字段表达「 XXX 的状态」这个概念。

真正有病的是某些语言里 boolean 的 getter 非要叫 isXxx ，所以禁止 boolean 属性以 is 开头这件事。

ruby 变量不能加问号, 但是定义方法可以加问号

＃21

现在微软也这样了，xamarin.forms/maui 框架里的 BindableProperty 一水的 IsEnabled

😂😂Win32 确实是这样的，lpfnWndProc lpszClassName

is has can need

bool 型都命名 xxxxFlag ，某些序列化框架对 is 处理有问题

如果不用 is
至少也得用过去分词形式

我用 Java ，不加 is ，但加 has/flag ，虽然更想加 is ，但三方库 Lombok 自动加的 setter 会导致变量映射失败。
其实主要是想要填充语义，比如“是否是黑色”的变量名用 isBlack 就比 blackFlag 更贴切。