类似 dto、vo、bo 这些类的命名后缀是大写还是驼峰？比如： UserDto 或者 UserDTO？

个人习惯大写

缩写一般大写

dto 本来就是 data transfer object 的缩写了，肯定是全大写 DTO 啊...

统一即可，两种写法在多个开源项目中都看到过。

建议驼峰 UserDto ，把 DTO 当做一个单词看待。
如果用下划线的写法，那么应该是 user_dto ，可以看出 dto 是一个整体。
如果是 UserDTO ，那么转换成下划线形式的时候容易出问题。

看项目规范吧，大家统一起来就行。

DTO 大写

我看到的一般都是大写，不知道是不是规范，但是比较统一

标准库的 java.net 的 HttpURLConnection 类就是混用的，HTTP 用了驼峰，URL 用了大写

重要的是统一 不过我和 5l 一样 把它当做一个词去看待 所以就 Dto 这样写了

我也是 Dto ，不然总会有提示要改成驼峰，不知道是哪个插件的

阿里的规范，但是我们项目是 Dto
[强制] 类名使用 UpperCamelCase 风格，但以下情形例外：DO / BO / DTO / VO / AO / PO / UID 等。 正例：ForceCode / UserDO / HtmlDTO / XmlService / TcpUdpDeal / TaPromotion 反例：forcecode / UserDo / HTMLDto / XMLService / TCPUDPDeal / TAPromotion

@CodeCodeStudy HTTPURLConnection 看着头疼

把驼峰法的 UpperLetter 理解成下划线法的_就好了.
所以是 UserId, UserDto

把 Dto 看成一个单词，UserDto

受不了 DTO 全大写

这种东西建议用无脑方式，不管是不是缩写的单词全部不要大写，减少这方面用脑支出，否则碰到 Id, Db ，Html 之类的都要纠结一下

大写

谷歌 Java 风格里对驼峰写法的建议是 Dto ，另外 iOS 应该写作 Ios 、IPv6 应该写作 Ipv6

https://google.github.io/styleguide/javaguide.html#s5.3-camel-case

我习惯 UserDto , 大写单词一眼看不懂,需要反应反应

阿里开发规范是大写

@yiqunz #13 是啊，所以我觉得还是用驼峰的好，如果用大写的话，万一碰到多个缩写，全都是大写字母就很难看了

**DTO **VO **BO 感觉好丑， 最好是能有一些名词代替。 订单这种 可以用 bill (账单 代替 OrderDTO) invoice (票据
OrderVO)

user_id userId userID ？

觉得不妥可以写全嘛，userDataTransferObject

建议和下划线的写法相对应，这样能够完全统一下来，并且一些自动转换能得到正确的结果。

都可以，Dto 可以的

新项目大写。
现有项目 跟着项目风格。

@CodeCodeStudy #5
谁字段名起 xxx_dto ，这东西只是一个特殊的传输对象，json key 也不会用 xxx_dto 。

无所谓, 统一即可

都可以, DTO 看起来帅一点也更符合本身单词的逻辑, 但是对自动转换驼峰和蛇形的反射器不太友好. 取舍以后保持一致就行.

我们这边设置了强制用 Dto 这种风格 ……

我们的规范事缩写也作为普通单词

最朴素的直觉，全部大写很丑

@wolfie #29 我不是指 DTO 这种东西，而是说要把缩略词当做一个单词看待

公司里的 sonar 检查 DTO 这种会报错。。

看自己的情况。
全大写对我来说更符合直觉，能一眼分辨出是三个单词的缩写

我很好奇这些名字谁起的，完全不习惯这种起名

习惯了 DTO

习惯小写。。当做普通名词来看待吧。我觉得大写相对小写来说，没有那么直观。虽然影响是不大。

我都乱来,哪怕你函数名叫 A 也没关系,但是函数和关键地方注释一定要有..

都可以

这些都是正常写法，我们所有的命名全是中文拼音第一个字母，变量，方法，类，包，文件，文件夹，数据库字段，已经吐槽了很久了，现在想想很可能是涉密原因吧。

我之前也纠结过，现在认为针对这种缩写形式，可能看成一个单词更好。
参考 Url （ Uniform Resource Locator ）、Id （ Identity ）、Http （ Hyper Text Transfer Prtcl ），虽然是缩写，但含义已经极其明确，你全大写和首字母大写都可以。
个人感觉 Dto 、Vo 、Bo 的形式比较合理。（在一定上下文环境中省略前缀后）变量就是 dto 、vo 、bo （这里要特别吐槽一下阿里的 DO ，如果全小写会变成关键字 do ，所以我用对应的 PO ），要不然变量叫 dTO 、vO 、bO ，总感觉怪怪的。
写到这里，回去看了一下自己的项目，发现目前用的是 UserVO 这种写法，一般对应的变量直接叫 vo ，如果多个 VO 同时出现，那么会写成 userVo ，感觉也挺舒服。。。

都可以，看该项目规范，要统一

新项目还用这些东西命名吗，太丑陋了

我记得.net 的规范是 小于等于 3 个字符，全大写，例如 DTO ，VO ，大于 3 个字符就驼峰，例如：Http ； GO 的规范是全驼峰。

@eronekogin #25 标准库的 java.net 的 HttpURLConnection 类应该改成 hyperTextTransferProtocolUniformResourceLocatorConnection

@shayuvpn0001
有苹果 API 那味了，https://developer.apple.com/documentation/sirikit/ingetavailablerestaurantreservationbookingdefaultsintentresponse

我习惯全驼峰，这样命名函数的时候看着没那么累。比如 ConvertDTOToItem ，就会容易看成 DTOT

所以从这一点来看，还是下划线比较好。

一般将缩写当普通单词比较普适，也就是 HttpClient 。
考虑在 golang 里的命名规范，首字母大小写区分公私有成员，私有成员 httpClient ，公有成员 HttpClient ，如果全大写就会搞出 hTTPClient 这样不伦不类的命名。

就是一个标准统一就好，我个人更喜欢驼峰。
虽然阿里巴巴的标准是全大写，并且目前我们项目领导也要求这样，我也遵守了这样的规范。

DTO 和 HTTP 、URL 、SQL 、NBA 、NASA 、API 、GUI 、REST 一样都是一类专有名词缩写，针对于驼峰命名法而言，我的理解是按照驼峰结构修改，和普通单词一样，按照驼峰方式拼写。
QueryUrl 、UpdateSql 、NbaList 、FakeApi 、Rest 、UserDto 、UserVo 。

而 DTO 、VO 、DAO 这类东西和前面其他专有名词缩写有一点不一样的地方在于它在名字中是存在特定编程含义的，而其他专有名词在技术层面没有任何意义。
NbaList 、CnCity 、这类缩写对于某个新加入项目的人而言与 AList 、BObject 并无区别理解代码改造代码的时候无需了解这个缩写的含义； DTO 和 VO 你看到他们的时候你就知道这个类的用途。

所以我可以理解为什么有人认为该保持全大写，但我个人更倾向于统一用驼峰，不能因为它表达的含义不同就专门例外。

起码谷歌工程师都是用驼峰的，比如安卓中有个 DnsResolver

@shayuvpn0001 对啊，这不是 java 特色之一么，超过 50 个字符长度的类名不是分分钟 XD

整个项目统一就行