Questions tagged «naming-conventions»

命名约定是指管理分配给编程结构(例如变量和方法)的名称的通用规则。这些约定通过增强跨不同模块的命名一致性来提高可读性,从而提高代码的可维护性。

5
Java(带有多个字符)的通用类型参数命名约定?
在我写的某些界面中,我想使用不止一个字符来命名通用类型参数,以使代码更具可读性。 就像是.... Map<Key,Value> 代替这个... Map<K,V> 但是当涉及到方法时,类型参数看起来像java类,这也很令人困惑。 public void put(Key key, Value value) 这似乎是键和值是类。我发现或想到了一些符号,但没有什么比Sun的约定或最佳常规更好。 我猜或发现的替代方案... Map<KEY,VALUE> Map<TKey,TValue>

11
C语言中最常见的命名约定是什么?
C语言中常用的命名约定是什么?我知道至少有两个: 具有lower_case_functions的GNU / linux / K&R ?名称 ?具有UpperCaseFoo函数 我只在这里谈论C。我们的大多数项目是使用C的小型嵌入式系统。 这是我计划用于下一个项目的一个: C命名约定 Struct TitleCase Struct Members lower_case or lowerCase Enum ETitleCase Enum Members ALL_CAPS or lowerCase Public functions pfx_TitleCase (pfx = two or three letter module prefix) Private functions TitleCase Trivial variables i,x,n,f etc... Local variables lower_case or lowerCase Global variables …

30
为什么不应该使用“匈牙利表示法”?
已锁定。该问题及其答案被锁定,因为该问题是题外话,但具有历史意义。它当前不接受新的答案或互动。 我知道匈牙利语指的是-提供有关变量,参数或类型的信息作为其名称的前缀。每个人似乎都在疯狂地反对它,即使在某些情况下,这似乎是一个好主意。如果我觉得正在传递有用的信息,为什么不把它放在可用的地方呢? 另请参阅:人们在现实世界中是否使用匈牙利命名约定?

17
您对存储过程的命名约定是什么?[关闭]
按照目前的情况,这个问题不适合我们的问答形式。我们希望答案得到事实,参考或专业知识的支持,但是这个问题可能会引起辩论,争论,民意调查或扩展讨论。如果您认为此问题可以解决并且可以重新提出,请访问帮助中心以获取指导。 8年前关闭。 我已经看到了各种命名存储过程的规则。 某些人在存储过程名称前加上usp_前缀,另一些人在应用程序名称的缩写前加上前缀,而另一些人则在所有者名称前加上前缀。除非您确实如此,否则不应在SQL Server中使用sp_。 有些人以动词开头proc名称(获取,添加,保存,删除)。其他人则强调实体名称。 在具有数百个存储过程的数据库上,当您认为已经存在一个存储过程时,很难滚动查找合适的存储过程。命名约定可以使存储程序的查找更加容易。 您是否使用命名约定?请描述一下,并说明为什么您偏爱其他选择。 答复摘要: 似乎每个人都提倡命名的一致性,对于每个人来说,使用相同的命名约定可能比使用特定的命名约定更为重要。 前缀:虽然很多人使用usp_或类似名称(但很少使用sp_),但其他许多人则使用数据库或应用程序名称。一个聪明的DBA使用gen,rpt和tsk来区分一般的CRUD程序和用于报告或任务的程序。 动词+名词似乎比名词+动词更受欢迎。有些人为动词使用SQL关键字(“选择”,“插入”,“更新”,“删除”),而其他人则使用诸如Get和Add之类的非SQL动词(或它们的缩写)。有些人在单数名词和复数名词之间进行区分,以指示是否正在检索一个或多个记录。 最后在适当的地方建议添加一个短语。GetCustomerById,GetCustomerBySaleDate。 有些人在名称段之间使用下划线,而有些人则避免使用下划线。app_ Get_Customer与appGetCustomer-我想这是可读性的问题。 可以将大量的sproc隔离到Oracle软件包或Management Studio(SQL Server)解决方案和项目或SQL Server架构中。 应避免使用难以理解的缩写。 为什么选择我做的答案:有很多好的答案。谢谢你们!如您所见,很难只选择一个。我选择的那个引起了我的共鸣。我遵循了他描述的相同路径-尝试使用动词+名词,然后无法找到所有适用于客户的存储过程。 能够找到一个现有的存储过程,或者确定一个存储过程是否存在,这一点非常重要。如果有人无意间创建了另一个名字的重复存储过程,可能会导致严重的问题。 由于我通常在具有数百个存储库的大型应用程序上工作,因此我偏爱最容易找到的命名方法。对于较小的应用程序,我可能会提倡动词+名词,因为它遵循方法名称的通用编码约定。 他还主张使用应用程序名称作为前缀,而不是使用不太有用的usp_。正如一些人指出的那样,有时数据库包含多个应用程序的存储库。因此,使用应用程序名称作为前缀有助于隔离存储过程,并有助于DBA和其他人确定该存储过程用于哪个应用程序。



8
C#类命名约定:是BaseClass还是ClassBase或AbstractClass
建议的命名基类的方法是什么?它是在类型名称前面加上“ Base ”还是“ Abstract ”,还是只是在其后缀“ Base”? 考虑以下: 类型:ViewModel例如MainViewModel,ReportViewModel 基类:BaseViewModel或ViewModelBase或AbstractViewModel 同时考虑: 类型:Product例如VirtualProduct,ExpiringProduct 基类:BaseProduct或ProductBase或AbstractProduct 您认为哪个更标准? class Entity : EntityBase { } 要么 class Entity : BaseEntity { }

3
转到const的命名约定
我正在尝试确定constGolang中的名称是否有命名约定。 我个人倾向于遵循C风格并以大写形式编写它们,但是我在此页面http://golang.org/doc/effective_go.html上未找到任何内容,该页面似乎列出了该语言的一些命名约定。

4
Django应用程式有命名惯例吗?
创建包含多个单词的Django应用程序时,是否存在首选的命名约定?例如,以下哪一项是优选的? my_django_app my-django-app 更新:语法不允许 mydjangoapp 推荐的解决方案 虽然在语法上都允许所有 选项1和3,但是是否有偏好?看看Django通过将应用程序名称和模型名称与下划线组合在一起来创建表名称的方式,我倾向于选择选项1。 有什么想法吗?

5
Java中实用程序类的命名约定
用Java编写实用程序类时,应遵循哪些良好准则? 包装应该是“ util”还是“ utils”?是ClassUtil还是ClassUtils?什么时候将课程称为“助手”或“实用程序”?实用程序还是实用程序?还是混合使用它们? 标准Java库同时使用Utils和Utilities: javax.swing.Utilities javax.print.attribute.AttributeSetUtilities javax.swing.plaf.basic.BasicGraphicsUtils Apache使用了多种Util和Utils,尽管大多数都是Utils: org.apache.commons.modeler.util.DomUtil org.apache.commons.modeler.util.IntrospectionUtils org.apache.commons.io.FileSystemUtils org.apache.lucene.wordnet.AnalyzerUtil org.apache.lucene.util.ArrayUtil org.apache.lucene.xmlparser.DOMUtils Spring使用了很多Helper和Utils类: org.springframework.web.util.UrlPathHelper org.springframework.core.ReflectiveVisitorHelper org.springframework.core.NestedExceptionUtils org.springframework.util.NumberUtils 那么,您如何命名实用程序类?

4
Go中文件名的约定是什么?
我可以在Go中找到命名包的约定:单词之间没有下划线,所有内容都小写。 这个约定也适用于文件名吗? 您是否也像在Java类中那样将一个结构放在一个文件中,然后以该结构命名? 当前,如果我具有结构WebServer,则将其放在文件web_server.go中。

8
命名“ class”和“ id” HTML属性-破折号与下划线[关闭]
已关闭。这个问题是基于观点的。它当前不接受答案。 想改善这个问题吗?更新问题,以便通过编辑此帖子以事实和引用的形式回答。 5年前关闭。 改善这个问题 <div id="example-value">还是<div id="example_value">? 本网站和Twitter使用第一种样式。Facebook和Vimeo-第二个。 您使用哪一个?为什么?


9
在R中命名变量的首选样式是什么?[关闭]
已关闭。这个问题是基于观点的。它当前不接受答案。 想改善这个问题吗?更新问题,以便通过编辑此帖子以事实和引用的形式回答。 4年前关闭。 改善这个问题 您喜欢在R代码中使用哪些命名变量和函数的约定? 据我所知,有几种不同的约定,所有这些约定共鸣共存: 1.使用句点分隔符,例如 stock.prices <- c(12.01, 10.12) col.names <- c('symbol','price') 优点: 在R社区中具有历史悠久的先例,在R核心中普遍存在,并且受到Google的R风格指南的推荐。 缺点: 充斥着面向对象的含义,并且使R新手感到困惑 2.下划线的使用 stock_prices <- c(12.01, 10.12) col_names <- c('symbol','price') 优点: 许多编程语言中的通用约定;已被Hadley Wickham的样式指南青睐,并用于ggplot2和plyr软件包。 缺点: R程序员从不使用过;在Emacs-Speaks-Statistics中恼人地映射到'<-'运算符(可通过'ess-toggle-underscore'更改)。 3.混合使用大写字母(camelCase) stockPrices <- c(12.01, 10.12) colNames <- c('symbol','price') 优点:在几种语言社区中似乎已被广泛采用。 缺点:有最新的先例,但历史上未使用(在R base或其文档中)。 最后,好像还不够令人困惑,我应该指出,《 Google风格指南》主张变量应使用点号,而函数应采用大小写混合。 R包之间缺乏一致的样式在几个层面上都是有问题的。从开发人员的角度来看,这使得维护和扩展他人的代码变得困难(尤其是其样式与您自己的代码不一致)。从R用户的角度来看,不一致的语法通过乘以表示概念的方式(例如,日期强制转换函数asDate(),as.date()或as_date()?)来加深R的学习曲线。日期())。

10
Python名称修饰
在其他语言中,有助于产生更好代码的通用准则总是使所有内容都尽可能隐藏。如果不确定变量是私有变量还是受保护变量,最好使用私有变量。 同样适用于Python吗?我是否应该首先在所有内容上使用两个前导下划线,并且仅在需要时才使它们的隐藏性降低(仅一个下划线)? 如果约定只使用一个下划线,我也想知道其基本原理。 这是我对JBernardo的回答所留下的评论。它解释了为什么我问这个问题,以及为什么我想知道为什么Python与其他语言不同的原因: 我来自可以训练您的语言,使您认为一切都应该仅在需要时公开,而不能再公开了。原因是这将减少依赖关系并使代码更安全地更改。Python反向做事的方式-从公开开始到隐蔽-对我来说很奇怪。

By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.