Tag: 命名约定

什么是不可变集合上的一个非变异的“添加”方法的最好的名字?

不好意思的是,如果我能拿出一个简洁的标题,我不会问这个问题。 假设我有一个不可变的列表types。 它有一个操作Foo(x) ,它返回一个带有指定参数的新的不可变列表作为最后一个额外的元素。 所以要build立一个值为“你好”,“不可变”,“世界”的string列表,你可以这样写: var empty = new ImmutableList<string>(); var list1 = empty.Foo("Hello"); var list2 = list1.Foo("immutable"); var list3 = list2.Foo("word"); (这是C#代码,如果你觉得这个语言很重要,我最感兴趣的是C#的build议,这不是一个基本的语言问题,但是这个语言的习惯用法可能很重要。 重要的是现有的列表不会被Foo修改,所以empty.Count仍然会返回0。 另一种(更习惯的)达到最终结果的方式是: var list = new ImmutableList<string>().Foo("Hello") .Foo("immutable") .Foo("word"); 我的问题是: Foo最好的名字是什么? 编辑3 :正如我后来透露,types的名称可能实际上不是ImmutableList<T> ,这使得位置清晰。 想象一下,它是TestSuite ,它是不可变的,因为它是整个框架的一部分是不可变的… (编辑结束3) 我到目前为止的选项: Add :在.NET中通用,但意味着原始列表的变化 Cons :我认为这是function语言中的普通名字,但对那些没有这种语言经验的人来说毫无意义 Plus :迄今为止我的最爱,这并不意味着我的变化 。 显然这也是在Haskell中使用的,但是期望稍有不同(Haskell程序员可能期望它将两个列表一起添加,而不是向另一个列表添加单个值)。 With :一致的一些其他不变的约定,但不具有相同的“增加”它IMO。 And :不是很具描述性。 运营商超负荷+:我真的不喜欢这么多; 我一般认为运营商只适用于较低层次的types。 […]

连字符分隔的情况是什么名字?

这是PascalCase: SomeSymbol 这是camelCase: someSymbol 这是snake_case: some_symbol 所以我的问题是,是否有一个被广泛接受的名称: some-symbol ? 这是常用的url。

有人可以解释JavaScript中的美元符号吗?

可能重复 为什么JavaScriptvariables是以美元符号开始的? 有问题的代码在这里: var $item = $(this).parent().parent().find('input'); 美元符号在variables名称中的用途是什么,为什么不把它排除呢?

REST URI约定 – 创build资源时的单数或复数名称

我是REST的新手,我发现在一些RESTful服务中,他们使用不同的资源URI来进行更新/获取/删除和创build。 如 创build – 使用/资源与POST方法(观察复数)在某些地方使用/资源 (单数) 更新 – 使用/资源/ 123与PUT方法 获取 – 使用/资源/ 123与GET方法 我对这个URI命名约定有点困惑。 我们应该使用复数或单数来创造资源? 在决定的时候应该是什么标准呢?

git分支命名最佳实践

我已经使用了一个本地的git仓库,与我的团队的CVS仓库进行数月的交互。 我做了一个几乎神经质的分支,其中大部分已经合并到我的箱子里了。 但命名开始成为一个问题。 如果我有一个简单的标签命名的任务,但是我分三个阶段完成,每个阶段都包含自己的分支和合并情况,那么我可以每次都重复分支名称,但这会使历史有点混乱。 如果我在名称上更加具体,每个阶段都有单独的描述,那么分支名称就会变得漫长而笨拙。 我确实在这里学习了一些旧线程,我可以用这个名字来命名分支,比如topic / task,或者类似的东西。 我可能会开始这样做,看看是否有助于保持组织更好。 命名git分支的一些最佳实践是什么? 编辑:没有人提出任何命名约定。 我完成删除分支。 由于pipe理层不断调整优先顺序,我恰好碰巧有几个。 :)作为一个为什么我可能需要在一个任务上有多个分支的示例,假设我需要将任务中的第一个离散里程碑提交给组的CVS存储库。 在那个时候,由于我与CVS的交互不完善,我会执行这个提交,然后杀死那个分支。 (如果我试图在这一点上继续使用同一个分支,我已经看到了太多与CVS交互的奇怪现象。)

在Javavariables和方法名中使用下划线

即使在现在,我经常在Javavariables和方法中看到下划线,一个例子是成员variables(如“m_count”或“_count”)。 据我所知,在这些情况下使用下划线称为Sun的坏风格。 他们应该使用的唯一的地方是在常量(如在“公共最终静态INT IS_OKAY = 1;”),因为常量应该是全部大写,而不是骆驼大小写。 在这里,下划线应该使代码更具可读性。 你认为在Java中使用下划线是不好的风格? 如果是(或不),为什么?

命名约定在C#中

什么是普遍接受的命名约定为C#? (函数,类,参数,局部variables,命名空间等)

为什么variables名通常以字母“m”开头?

看看记事本教程等Android教程,我注意到几乎所有的variables都以字母“m”开头。 这是什么约定,它起源于哪里?

你在Java中使用什么包命名规则来进行个人/业余爱好项目?

我已经熟悉使用域名创build唯一的包名(即包com.stackoverflow.widgets )的标准Java包命名约定。 但是,我从来没有看到如何select个人项目的软件包名称的build议。 我认为这是因为这是个人品味的问题。 那么,你如何select个人项目的软件包名称,永远不会投入生产(你可能在空闲时间试验一个新的框架)。 假设你没有一个可以用来创build你的包结构的个人网站,你会做什么? 你是否有一个合适的逻辑系统来为爱好项目生成新的软件包名称,或者你只是使用简单的丢弃软件包名称,如mypackage ? 因为我只是好奇,看看不同的人的想法是什么,我已经把这个社区维基。 对我个人而言,我从来没有这么想过,但是我今天晚上想和Wicket一起玩,而且想到我对于如何组织自己的兴趣项目没有一个清晰的认识。 对于爱好项目(至less在我的脑海里)来说,一个单独的,独特的软件包命名规则可以作为将个人和工作相关的代码彼此分开的好办法。 我正在考虑一个简单的层次命名约定,以将我的个人项目的源代码保存在单个根文件夹中: 使用myprojects作为根文件夹 附加项目名称 添加任何附加的子包名称 所以,我的Wicket项目将在包myprojects.learningwicket和unit testing将在包myprojects.learningwicket.tests (例如)。

命名类 – 如何避免把一切都称为“<WhatEver>pipe理器”?

很久以前,我已经阅读了一篇文章(我相信一个博客文章),这个文章将我放在命名对象的“正确”轨道上:在程序中对命名做出非常谨慎的规定。 例如,如果我的应用程序(作为一个典型的商业应用程序)处理用户,公司和地址,我会有一个User ,一个Company和一个Address域类 – 可能在某处UserManager ,一个AddressManager和一个AddressManager会popup处理那些事。 那么你能告诉那些UserManager , AddressManager和AddressManager做什么吗? 不,因为经理是一个非常通用的术语,适合任何你可以用你的域对象做的事情。 我读的文章推荐使用非常具体的名字。 如果这是一个C ++应用程序,并且UserManager的工作是从堆中分配和释放用户,那么它不会pipe理用户,而是保护他们的出生和死亡。 嗯,也许我们可以称之为UserShepherd 。 或者UserManager的工作是检查每个用户对象的数据并以密码方式签署数据。 然后我们有一个UserRecordsClerk 。 现在,这个想法坚持我,我尝试应用它。 而且很难find这个简单的想法。 我可以描述这些课程所做的事情(只要我没有陷入快速和肮脏的编码中),我写的课程只能做一件事。 我想从这个描述到名字的想法是一种名称目录,一个将概念映射到名称的词汇表。 最终,我想在我的脑海里有一个类似于模式目录的东西(通常devise模式很容易提供对象名称,例如工厂 ) 工厂 – 创build其他对象(从devise模式中获取的命名) 牧羊人 – 一个牧羊人处理对象的生命周期,他们的创build和closures 同步器 – 在两个或多个对象(或对象层次结构)之间复制数据 保姆 – 帮助对象在创build后达到“可用”状态 – 例如通过连接到其他对象 等等 那么,你如何处理这个问题呢? 你是否有固定的词汇量,你是否即刻发明新的名字,或者你认为命名不重要或错误? PS:我也感兴趣的文章和博客讨论这个问题的链接。 首先,这是原来的文章,让我想起它: 命名Java类没有“经理” 更新:答案摘要 下面是我从这个问题中学到的东西的一个小结。 尽量不要创造新的隐喻(保姆) 看看其他的框架是做什么的 关于此主题的更多文章/书籍: 你有什么名字定期地join/附加到课堂上? 什么是命名类的最好方法? 书: devise模式:可重用面向对象软件的元素(精装) 图书: 企业应用架构模式(精装) […]