乃们怎么看

选择了 Ruby 和 Rails，就选择了学英语，我是这么理解的

我觉得统一用单数形式挺好，规约大于配置嘛，这样规约不更简单吗？ person -> people，可读性差不多，语义上某些条件下更精确，但也多了单复数这个成本。

#2 楼 @winnie 是哈，得加强 English 了

#3 楼 @feitian124 我也是这么认为，感觉作者太偏执狂了

学好英语……

这是来源于面向对象，是一种抽象。 人类 --> 具体的人群 Person -> people

有什么执着不执着的，对于以英语为母语的人来说用单复数就跟吃饭睡觉一样自然，你会觉得自己天天吃饭很执着么？

#6 楼 @hozaka #7 楼 @blackanger #8 楼 @PrideChung 你们说的有理，原来我是站在中国人，非英语为母语的基础上说这话的。我懂了

其实 person 的复数形式就是 persons... 只是现在日常中基本都习惯用 people 了... 好吧好像回答的没在点上...

我觉得 rails 使用复数形式来做 table name 和 restful api，带来太多的麻烦，在实际用途中，共用一个词的单复数形式来做 route 的情况大家都会改个名字，避免误解，比如同时用 users（用户集合）和 user（当前用户） resources :users resource :user

通常第 2 个都会改成 resource :profile

只用单数可以少去大量的反射（外键，表名，controller 等等）

楼主可能没有理解 Restful 的精髓，鉴定完毕

#12 楼 @leomayleomay restful api 设计从来没有要求 resources 必须用复数形式来表达

如果 person 复数换成了 personList，那么要是还存在一个 personList 的 model, 它的复数如何表示？personListList?

Ruby 的世界是完全自由的，想怎么来就怎么来。 @iveryang 可以试试重写 ActiveSupport::Inflector，把规则改成 resources -> resource_list

同意楼主，确实比较蛋疼。。。但是就当学英语了。。。 而且这种非规则变化，我觉得写代码的人也做的蛮辛苦的。。。

1. 从汉语看，用户：个体，用户列表：群体，两个词里的 用户 虽然看起来一样，但是暗示的数量不同且无歧义，这是 OK 的。但是从英语看 user 和 user_list，两者的 user 虽然一样，却无法暗示数量有差别，你可以说 user_list 是 N 个用户组成的列表，也可以认为是一个用户的列表，虽然前者更常见，但仍然有歧义。REST 虽然并没有强制规定复数资源一定要用名词的复数形式，但是 REST 提倡资源的表述应当准确，消除歧义。也许在多数应用里这样的变化不至于让人摸不着头脑，但是谁敢保证所有的业务场景用后缀 _list 都不会产生歧义？一旦产生歧义怎么办？改用复数形式？改后缀？那么所谓的“一致性”又如何体现？Rails 在设计之初约定了使用名词的复数形式，这是英语天然的特性（名词皆有复数形式），且符合 REST 用名词指代资源的倡导，所以这是自然而然的事情。

2. Rails 的理念是“约定重于配置”，而不是“只有约定没有配置”。如果你的应用程序在设计时可以确定新的约定不会引起歧义，那么你可以重新配置。正是 Ruby 语言和 Rails 框架的灵活性才得以让二者得兼，因此完全没有必要抱怨默认的约定不符合你的“口味”，更何况这个“口味”的根源在于英语不过关……

#15 楼 @swordray
#16 楼 @mahone3297 刚刚我发现加入这行代码是可以的：ActiveRecord::Base.pluralize_table_names = false，你们试试吧

楼主不习惯的根本原因是 你的母语不是英语 对英语国家来说，复数比 XxxList 好理解多了。

#17 楼 @nightire 是的，我想明白了，对说英语的人而言，我的想法是可笑的，但是对于不少俺们中国人来说，英语不太熟，还是觉得不习惯，不过还好了，他可以加入：ActiveRecord::Base.pluralize_table_names = false 来取消这个的。

恩恩，你们说的也对。 但是，说句实话，不光是我这个中国人不适应，老外也不适应，比如 spring 的作者，他说他更喜欢 xx_list 这样的方式。 #19 楼 @kgen
#17 楼 @nightire

我用过的一个 java 的编码规约要求数组或者 List 的变量的命名要以 List 结尾，这跟英语不英语没关系吧（手机上网不方便回去找找 google 的 java 编码规约的）

#21 楼 @iveryang 特例不适用，你应该想想什么叫“约定”，“惯例”。作为一个北方人，初到上海时我也不适应把在“好的”后面非要加个“呀”，但我知道这是地方特色，是习惯，既然如此就应该适应。Rails 社区已经形成此种约定多少年了？会因为少数群体的不适应而改变大多数人已经习以为常的惯例吗？再说了，又不是不允许你改，只是默认的是一种惯例罢了。你不觉得以你为代表的少数群体太“娇气”了吗？

#23 楼 @nightire 想听听你对这个问题的意见，是否也需要约定好 http://ruby-china.org/topics/17686

有自己的一套最好

#24 楼 @swordray 本地的事情，不会影响到团队协作，何必约定？

#26 楼 @nightire ruby + css + js 的人协作，也是要经常交换本地环境地址的，尤其是前端同学不清楚 url 定义

复数主要用在

1. routes
2. controller
3. table lookup
4. model association
5. form text generation

routes 中复数有用的，就是 route 可以写 resources 跟 resource，两者能代表不同意义。这算是不错。

但是最讨厌的是，虽然前方 route 能定义单数 /profile 路径，但是后方接的 controller 最好还是要写成 ProfilesController，不然要多写一大堆设定，只会带给你坏处没有好处。

因为 Table lookup 一定都是复数，那还不如像是 modal 命名一样也用单数，这样子脑子不用多想像是 Person class 对应到 peoples table。

Model association 是唯二用复数表达很直觉，能简单分辨 has_many :topics 跟 has_one :topic，不过这也只算是语法糖。

最后，form 的文字产生的确有好处，不过到头来大部分的网站最后还是会手工刻 form，又或者中文根本不需要，所以这部份说实在重要性不高。

此外，都是单数的话，IDE 的 auto complete 会更爽。用复数命名时，如果有 companies 跟 company_employees 两字，每次按 tab 都会卡到 compan。

所以还是支持单数。

我怎么觉得都有点说远了。我主要遇到的问题就是英文的单复数没有规律，遇上元编程需要批量动态定义方法的时候头疼得很。有 Rails 还好办些，拿它的组件来注册一下不规则复数。纯粹写 Ruby 代码的时候实在不想自己这么干，也觉得没必要为了个单复数去专门引入 Rails 的 ActiveSupport。

好像跟习惯不习惯英文关系不大吧。

#1 楼 @iveryang 你英语不够好，haha

#27 楼 @swordray 那你们团队内部约定就好了，这种事情我没有意见，团队定一个就是了，这种事情不需要大范围的约定。

然后我比较奇怪的是，你们写作开发，代码里交换 url 还一定要带上 hostname 吗？真没觉得有这个必要。你最好说一个比较具体的 case，到底什么样的情况下，不同环境的本地开发需要大家统一 hostname，我用我的 localhost，你用你的 127.0.0.1，难道不行？

#31 楼 @nightire 但我有公司团队，社区团队，好基友团队，不统一很麻烦

#32 楼 @swordray 我当然知道你有团队，我也有团队啊，可我从来没碰到过连这个都需要统一的问题，所以请你说具体点。

#33 楼 @nightire 我的意思是多个团队，各个 localhost 不一定愿意用一样的，我作为中间人就为难了

#33 楼 @nightire 我的意思是多个团队，各个 localhost 不一定愿意用一样的，我作为中间人就为难了

#33 楼 @nightire 我的意思是多个团队，各个 localhost 不一定愿意用一样的，我作为中间人就为难了 #33 楼 @nightire

#29 楼 @yuan 专门写个 gem 支持单复数……专门写个 task 查询单复数……

这没什么可讨论的。除非你有能力成为 Rails 核心开发人员，并说服其他人按你的想法改造 Rails。否则还是接受现实，总结规律吧： http://note.youdao.com/share/?id=4cc076c3b82907952bf4b1250caa46a7&type=note

#34 楼 @swordray 没错啊，这就回到了最开始我的观点，这种事情有什么好统一的？个人的开发环境只要不影响提交代码的一致性，人家爱用啥就用啥好了，你为何一定要统一呢？

要不然你就上 vagrant，省却一切争论不完了？你自己的团队之间是否要一致，我一个外人也说不上话啊。

#39 楼 @nightire 跟协作有关系，比如说要给前端发用户页面地址，A 团队我给他发 http://0/users/1 ，但是到了 B 团队用 127.0.0.1 又得发 http://127.0.0.1/users/1

#40 楼 @swordray 如果是我的话，我只发 /users/1 就够了，我不用 care 你本地的 hostname 是什么。

#41 楼 @nightire 对萌妹子要好一点嘛，把完整 URL 发过去方便人家点击

#42 楼 @swordray 呵呵，好吧，那我就没办法了。对我来说，工作就是工作，不会因为性别或其他的什么去迁就或歧视什么的。

#43 楼 @nightire 萌妹子是打个比方嘛，我对帅哥也会很温柔的把完整 URL 发过去方便人家点击

#44 楼 @swordray haha

#44 楼 @swordray 还是没明白………localhost、127.0.0.1、甚至某些 0.0.0.0 不都是同一个玩意么………除非你是虚拟机但对于一个 ip——那就更容易了工作局域网内大家都可以访问那个地址啊………所以无论你发什么不都应该可以直接打开………

#46 楼 @cassiuschen

因为水星是处女座的守护星，影响到处女座的人 追求完美，挑剔和神经紧张，吹毛求疵正是他们的特性 。处女座的人大都很谦虚，但很容易为自己带来压力，许多人一听到处女座就很害怕，明知他们挑剔，唠叨又婆婆妈妈，和人相处很不愉怏，人际关系“认真麻麻”，不过处女座的人爱帮助别人是另一事实。

#47 楼 @swordray 其实………我就是处女座的………so what？而且这跟 localhost 有个毛线关系！