标签: naming-conventions

假设我有两张桌子:

Table: Color
Columns: Id, ColorName, ColorCode

Table: Shape
Columns: Id, ShapeName, VertexList

我该怎么称呼将颜色映射到形状的表格？

Table: ???
Columns: ColorId, ShapeId

我知道匈牙利语所指的内容 - 将有关变量,参数或类型的信息作为其名称的前缀.每个人似乎都狂热地反对它,尽管在某些情况下它似乎是一个好主意.如果我觉得有用的信息被传授,为什么我不能把它放在那里？

另请参阅:人们是否在现实世界中使用匈牙利命名惯例？

我已经看到了命名存储过程的各种规则.

有些人使用usp_作为sproc名称的前缀,其他人使用应用程序名称的缩写作为前缀,还有其他人使用所有者名称.您不应该在SQL Server中使用sp_,除非您真正的意思.

有些人用动词(Get,Add,Save,Remove)启动proc名称.其他人则强调实体名称.

在具有数百个sprocs的数据库中,当您认为已存在时,可能很难滚动并找到合适的sproc.命名约定可以使定位sproc更容易.

你使用命名约定吗？请描述一下,并解释为什么你喜欢它而不是其他选择.

答复摘要:

• 每个人似乎都提倡命名的一致性,对于每个人来说,使用与使用特定命名约定相同的命名约定可能更为重要.
• 前缀:虽然很多人使用usp_或类似的东西(但很少sp_),但许多其他人使用数据库或应用程序名称.一个聪明的DBA使用gen,rpt和tsk来区分一般的CRUD sprocs和用于报告或任务的那些.
• 动词+名词似乎比Noun + Verb稍微受欢迎.有些人对动词使用SQL关键字(选择,插入,更新,删除),而其他人则使用非SQL动词(或缩写),如Get和Add.有些人区分单数和复数名词,以表明是否正在检索一个或多个记录.
• 在适当的情况下,最后建议使用另一个短语.GetCustomerById,GetCustomerBySaleDate.
• 有些人在名称段之间使用下划线,有些人则避免使用下划线.app_ Get_Customer与appGetCustomer - 我想这是一个可读性的问题.
• 可以将大量的sprocs分隔为Oracle包或Management Studio(SQL Server)解决方案和项目,或SQL Server模式.
• 应该避免使用不可思议的缩写.

为什么我选择我做的答案:有很多好的回答.谢谢你们!如你所见,选择一个是非常困难的.我选择的那个与我产生共鸣.我遵循他描述的相同路径 - 尝试使用Verb + Noun然后无法找到适用于Customer的所有sprocs.

能够定位现有的sproc,或确定是否存在,甚至是非常重要的.如果有人无意中创建了具有其他名称的重复sproc,则可能会出现严重问题.

由于我通常使用包含数百个sprocs的非常大的应用程序,因此我倾向于使用最容易找到的命名方法.对于较小的应用程序,我可能会提倡Verb + Noun,因为它遵循方法名称的一般编码约定.

他还提倡使用app name作为前缀,而不是使用不太有用的usp_.有几个人指出,有时数据库包含多个应用程序的sprocs.因此,使用app name前缀有助于隔离sprocs并帮助DBA和其他人确定sproc用于哪个应用程序.

在我写的一些接口中,我想用多个字符命名泛型类型参数,以使代码更具可读性.

就像是....

Map<Key,Value>

而不是......

Map<K,V>

但是当涉及到方法时,类型参数看起来像java-classes,这也令人困惑.

public void put(Key key, Value value)

这看起来像Key和Value是类.我发现或想到了一些符号,但没有像Sun的惯例或一般的最佳实践.

我猜测或发现的替代品......

Map<KEY,VALUE>
Map<TKey,TValue>

命名约定很重要,主键和外键具有常用和明显的约定(PK_Table和FK_Table_ReferencedTable分别).IX_Table_Column索引的命名也是相当标准的.

UNIQUE约束怎么样？这个约束是否有一个普遍接受的命名约定？我见过UK_TableName_Column,UQ_TableName_Column有人推荐AX_TableName_Column- 我不知道它来自哪里.

我经常使用,UQ但我并不特别喜欢它,我不喜欢捍卫我选择使用它来反对UK倡导者.

我只想看看是否就最流行的命名达成了共识,或者是为什么一个人比其他人更有意义的一个很好的推理.

C中常用的命名约定是什么？我知道至少有两个:

1. 具有lower_case_functions的GNU/linux/K&R
2. ？名称 ？使用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    g_lowerCase or g_lower_case (searchable by g_ prefix)

对控制器和助手使用单数名称有什么不利吗？似乎没有什么依赖于此.它甚至看起来帮助者不必像对应的控制器那样对单数与复数做出相同的选择,至少根据我的有限实验.真的吗？

在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

那么,您如何命名实用程序类？

<div id="example-value">还是<div id="example_value">？

这个网站和Twitter使用的是第一种风格.Facebook和Vimeo--第二个.

你使用哪一个？为什么？

命名基类的推荐方法是什么？它是否在类型名称前加上" Base "或" Abstract ",或者我们只是用"Base"作为后缀？

考虑以下:

type:ViewModel例如MainViewModel,ReportViewModel

基类:BaseViewModel或ViewModelBase或AbstractViewModel

还要考虑:

type:Product例如VirtualProduct,ExpiringProduct

基类:BaseProduct或ProductBase或AbstractProduct

您认为哪个更标准？

class Entity : EntityBase
{
}

要么

class Entity : BaseEntity
{
}