天道酬勤,学无止境

您对存储过程的命名约定是什么? [关闭](What is your naming convention for stored procedures? [closed])

问题

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

某些人在存储过程名称前加上usp_前缀,其他人则在应用程序名称的缩写前加上其他人,在所有者名称前加上前缀。 除非您确实如此,否则不应在SQL Server中使用sp_。

有些人以动词(“获取”,“添加”,“保存”,“删除”)开头过程名称。 其他强调实体名称。

在具有数百个存储过程的数据库上,当您认为已经存在一个存储过程时,很难滚动查找合适的存储过程。 命名约定可以使存储程序的查找更加容易。

您是否使用命名约定? 请描述一下,并说明为什么比其他选择更喜欢它。

答复摘要:

  • 似乎每个人都提倡命名的一致性,对于每个人来说,使用相同的命名约定可能比使用特定的命名约定更为重要。
  • 前缀:虽然许多人使用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和其他人确定该存储过程用于哪个应用程序。

回答1

对于我的上一个项目,我使用了usp_ [Action] [Object] [Process],例如,usp_AddProduct或usp_GetProductList,usp_GetProductDetail。 但是,现在数据库有700个以上的过程,要查找特定对象上的所有过程变得更加困难。 例如,我现在必须搜索50个奇数的Add过程来添加Product,而50个奇数来获取Get等。

因此,在我的新应用程序中,我打算按对象对过程名称进行分组,我还删除了usp,因为我觉得这有点多余,除了告诉我它是一个过程之外,我还可以从名称中扣除程序本身。

新格式如下

[App]_[Object]_[Action][Process]

App_Tags_AddTag
App_Tags_AddTagRelations
App_Product_Add 
App_Product_GetList
App_Product_GetSingle

它有助于对事物进行分组,以便以后查找,尤其是在有大量存储过程的情况下。

关于使用多个对象的地方,我发现大多数实例都有一个主对象和一个辅助对象,因此在普通实例中使用了主对象,而在处理部分中引用了辅助对象,例如App_Product_AddAttribute。

回答2

这是有关SQL Server中sp_前缀问题的一些说明。

以前缀sp_命名的存储过程是存储在Master数据库中的系统存储过程。

如果为您的sproc赋予此前缀,则SQL Server首先在Master数据库中查找它们,然后在上下文数据库中查找它们,从而不必要地浪费了资源。 并且,如果用户创建的存储过程与系统存储过程具有相同的名称,则用户执行的存储过程将不会执行。

sp_前缀表示可从所有数据库访问该sproc,但应在当前数据库的上下文中执行该proc。

这是一个很好的解释,其中包括性能影响的演示。

这是Ant在评论中提供的另一个有用的资源。

回答3

系统匈牙利语(像上面的“ usp”前缀一样)使我不寒而栗。

我们在不同的,结构相似的数据库中共享许多存储过程,因此对于特定于数据库的数据库,我们使用数据库名称本身的前缀。 共享过程没有前缀。 我想使用不同的模式可能是完全摆脱这种有点丑陋的前缀的替代方法。

前缀后面的实际名称与函数命名几乎没有什么不同:通常是动词,例如“添加”,“设置”,“生成”,“计算”,“删除”等,后跟几个更具体的名词,例如“用户” ”,“每日收入”等。

回应蚂蚁的评论:

  1. 表和视图之间的差异与设计数据库模式的人员有关,而与访问或修改其内容的人员无关。 在极少数需要架构细节的情况下,它很容易找到。 对于临时的SELECT查询,它是无关紧要的。 实际上,我认为能够将表和视图相同是一个很大的优势。
  2. 与函数和存储过程不同,表或视图的名称不太可能以动词开头,也不能是一个或多个名词。
  3. 函数需要调用架构前缀。 实际上,函数和存储过程之间的调用语法(无论如何,我们都使用)非常不同。 但是,即使不是,也适用与1.相同的方法:如果我可以将函数和存储过程相同,为什么不呢?
回答4

这些年来,我几乎使用了所有不同的系统。 我终于开发了这个,今天我将继续使用它:

字首 :

  • gen-General:CRUD,主要是
  • rpt-报告:不言自明
  • tsk-任务:通常具有程序逻辑,通过计划的作业运行

动作说明符:

Ins - INSERT
Sel - SELECT
Upd - UPDATE
Del - DELETE

(在过程执行许多操作的情况下,将使用总体目标来选择操作说明符。例如,客户INSERT可能需要进行大量准备工作,但是总体目标是INSERT,因此选择“ Ins”。

目的:

对于gen(CRUD),这是受影响的表或视图名称。 对于rpt(报告),这是报告的简短描述。 对于ts​​k(任务),这是任务的简短描述。

可选的澄清器:

这些是可选的信息位,用于增强对过程的理解。 示例包括“按”,“用于”等。

格式:

[前缀] [动作说明符] [实体] [可选说明符]

过程名称示例:

genInsOrderHeader

genSelCustomerByCustomerID
genSelCustomersBySaleDate

genUpdCommentText

genDelOrderDetailLine

rptSelCustomersByState
rptSelPaymentsByYear

tskQueueAccountsForCollection
回答5

TableName_WhatItDoes

  • Comment_GetByID

  • 客户清单

  • UserPreference_DeleteByUserID

没有前缀或愚蠢的匈牙利胡说八道。 只是与它最相关的表的名称,以及对其作用的快速描述。

上面的一个警告:我个人总是在所有自动生成的CRUD前面加上zCRUD_前缀,这样它就可以排在列表的末尾,而不必查看它。

回答6

在SQL Server中,用sp_存储过程名称是不好的,因为系统存储过程都以sp_开头。 一致的命名(甚至在霍布林域范围内)很有用,因为它可以促进基于数据字典的自动化任务。 前缀在SQL Server 2005中的用处稍差一点,因为它支持架构,该架构可以按以前使用的名称前缀的方式用于各种类型的名称空间。 例如,在星型模式上,可以具有模式和事实模式,并以此约定引用表。

对于存储过程,前缀对于从系统存储过程中识别应用程序存储过程很有用。 up_ vs. sp_使得从数据字典中识别非系统存储过程相对容易。

回答7

我总是将存储过程封装在软件包中(在工作中我使用的是Oracle)。 这将减少单独对象的数量并帮助代码重用。

命名约定只是一个品味问题,您应该在项目开始时就与所有其他开发人员达成一致。

回答8

对于小型数据库,我使用uspTableNameOperationName,例如uspCustomerCreate,uspCustomerDelete等。这便于按“主要”实体进行分组。

对于较大的数据库,请添加架构或子系统名称,例如“接收”,“购买”等,以将它们分组在一起(因为sql server喜欢按字母顺序显示它们)

为了清楚起见,我尝试避免使用名称的缩写(项目中的新手不必怀疑'UNAICFE'的含义,因为该存储过程名为uspUsingNoAbbreviationsIncreasesClarityForEveryone)

回答9

我目前使用的格式如下

符号:

[PREFIX] [APPLICATION] [MODULE] _ [NAME]

例子:

P_CMS_USER_UserInfoGet

我喜欢这种表示法的原因有几个:

  • 从非常简单的Prefix开始,允许编写代码以仅执行以前缀开头的对象(例如,减少SQL注入)
  • 在我们更大的环境中,多个团队正在研究运行相同数据库体系结构的不同应用程序。 应用程序符号指定拥有SP的组。
  • “模块”和“名称”部分仅完成层次结构。 所有名称都应能够与层次结构中的“组/应用程序”,“模块”,“功能”相匹配。
回答10

我一直使用:

usp [表名] [操作] [详细信息]

给定一个名为“ tblUser”的表,它给我:

  • uspUserCreate
  • uspUserSelect
  • uspUserSelectByNetworkID

这些过程按表名和功能按字母顺序排序,因此很容易看出我可以对任何给定表执行的操作。 使用前缀“ usp”可让我知道正在调用的内容(例如)正在编写与其他过程,多个表,函数,视图和服务器进行交互的1000行过程。

在保留SQL Server IDE中的编辑器与Visual Studio一样好的性能之前,我将保留前缀。

回答11

应用程序prefix_ operation prefix_所涉及的数据库对象的描述(减去下划线之间的空格-必须在其中放置空格以使其出现)

我们使用的操作前缀-

  • 获取” –返回记录集
  • ins ” –插入数据
  • upd ” –更新数据
  • del ” –删除数据

例如

wmt_ ins _客户_details

“劳动力管理工具,将详细信息插入客户表”

好处

与同一应用程序相关的所有存储过程均按名称分组。 在该组内,执行相同类型操作(例如,插入,更新等)的存储过程被分组在一起。

这个系统对我们来说运作良好,大约有在我头顶上的一个数据库中有1000个存储过程。

到目前为止,还没有遇到这种方法的任何缺点。

回答12

GetXXX-根据@ID获取XXX

GetAllXXX-获取所有XXX

PutXXX-如果传递的@ID为-1,则插入XXX;否则,插入XXX。 其他更新

DelXXX-根据@ID删除XXX

回答13

我认为usp_命名约定对任何人都没有好处。

过去,我使用Get / Update / Insert / Delete前缀进行CRUD操作,但是现在由于我使用Linq to SQL或EF来完成我的大多数CRUD工作,因此这些都不用了。 由于我的新应用程序中存储的proc很少,因此命名约定不再像以前那样重要了;-)

回答14

对于当前正在处理的应用程序,我们有一个前缀来标识应用程序名称(四个小写字母)。 这样做的原因是我们的应用程序必须能够与旧应用程序在同一数据库中共存,因此前缀是必须的。

如果我们没有遗留的约束,我很确定我们不会使用前缀。

在前缀之后,我们通常以动词开头SP,该动词描述过程的作用,然后是我们要操作的实体的名称。 实体名称的复数形式是允许的-我们试图强调可读性,因此很明显,仅从名称中就可以执行该过程。

我们团队中典型的存储过程名称为:

shopGetCategories
shopUpdateItem
回答15

只要您逻辑上和一致的,我认为前缀到底是什么并不真正重要。 我个人使用

spu_ [动作说明] [流程说明]

其中,动作描述是一小部分典型动作之一,例如获取,设置,存档,插入,删除等。过程描述虽然简短但具有描述性,例如

spu_archiveCollectionData 

或者

spu_setAwardStatus

我用类似的方式命名函数,但以udf_作为前缀

我已经看到人们尝试使用伪匈牙利符号进行过程命名,在我看来,这种命名方式隐藏的内容多于所揭示的内容。 只要我按字母顺序列出我的程序,就可以看到它们按功能分组,那么对我来说,这似乎是有序和不必要的严格之间的最佳结合点

回答16

避免在SQl服务器中使用sp_ *,因为所有系统存储的过程都以sp_开头,因此,系统更加难以找到与名称相对应的对象。

因此,如果您以sp_以外的其他方式开始,那么事情会变得更容易。

因此,我们首先使用Proc_的通用命名。 如果提供了一个大的模式文件,则可以更轻松地确定过程。

除此之外,我们还分配了一个标识功能的前缀。 喜欢

Proc_Poll_Interface, Proc_Inv_Interface等。

这使我们能够找到所有完成POLL和库存等工作的存储过程。

无论如何,前缀系统取决于您的问题域。 但是al表示并做了类似的事情,即使只是为了让人们可以在explorere下拉列表中快速定位存储过程以进行编辑。

其他功能。

Proc_Order_Place
Proc_order_Delete
Proc_Order_Retrieve
Proc_Order_History

我们遵循基于函数的命名方式,因为Procs类似于代码/函数,而不是像表这样的静态对象。 Procs可能与多个表一起使用无济于事。

如果proc执行的功能多于单个名称所能处理的功能,则意味着proc所执行的工作远远超出了必要,并且需要花费更多的时间来拆分它们。

希望能有所帮助。

回答17

我参加了较晚的话题,但是我想在这里输入我的回复:

在我的最后两个项目中,有不同的趋势,例如,在我们使用的一个中:

获取数据:s <表名> _G
删除数据:s <表名> _D
插入数据:s <表名> _I
要更新数据:s <表名> _U

前端也遵循此命名约定,在单词dt之前添加前缀。

例子:

exec sMedicationInfo_G
exec sMedicationInfo_D
exec sMedicationInfo_I
exec sMedicationInfo_U

在我们的应用程序中,借助上述命名约定,我们有了一个容易记住的好名字。

在第二个项目中,我们使用相同的命名约定,但差别很小:

获取数据:sp_ <tablename> G
删除数据:sp_ <表名> D
插入数据:sp_ <tablename> I
更新数据:sp_ <表名> U

例子:

exec sp_MedicationInfoG
exec sp_MedicationInfoD
exec sp_MedicationInfoI
exec sp_MedicationInfoU

受限制的 HTML

  • 允许的HTML标签:<a href hreflang> <em> <strong> <cite> <blockquote cite> <code> <ul type> <ol start type> <li> <dl> <dt> <dd> <h2 id> <h3 id> <h4 id> <h5 id> <h6 id>
  • 自动断行和分段。
  • 网页和电子邮件地址自动转换为链接。

相关推荐
  • 是否存在Angularjs代码/命名约定? [关闭](Exists Angularjs code/naming conventions? [closed])
    问题 关闭。 此问题不符合堆栈溢出准则。 它当前不接受答案。 想要改善这个问题吗? 更新问题,使它成为Stack Overflow的主题。 6年前关闭。 改善这个问题 有谁知道在构建应用程序时是否存在任何官方的或最受欢迎的Angular命名约定参考? Angular具有许多不同类型的组件,例如过滤器,指令,服务等。 您是否同意在应用程序中实现引用命名约定会有意义? 例如:如果我们需要创建新的过滤器,我们应该如何命名它们,例如[Something] Filter或filter [Something]或其他名称? 同样适用于控制器,服务,指令等。 我想知道属于该范围的变量/函数是否应具有特定的前缀或后缀。 在某些情况下,有一种方法可以将它们与功能和其他功能(无角度代码)区分开来。 回答1 查看此GitHub存储库,其中描述了AngularJS应用的最佳做法。 它具有针对不同组件的命名约定。 它并不完整,但是它是由社区驱动的,因此每个人都可以做出贡献。 回答2 如果您是初学者,最好先阅读一些基本教程,然后再学习有关命名约定的知识。 我已经通过以下内容学习了Angular,其中一些非常有效。 教程: http://www.toptal.com/angular-js/a-step-by-step-guide-to-your-first-angularjs-app http:/
  • Python应用程序的最佳项目结构是什么? [关闭](What is the best project structure for a Python application? [closed])
    问题 关门了。 这个问题需要更加集中。 它当前不接受答案。 想要改善这个问题吗? 更新问题,使其仅通过编辑此帖子即可将重点放在一个问题上。 4年前关闭。 改善这个问题 想象一下,您想用Python开发非平凡的最终用户桌面(非Web)应用程序。 构造项目文件夹层次结构的最佳方法是什么? 理想的功能是易于维护,IDE友好,适用于源代码控制分支/合并以及易于生成安装软件包。 特别是: 您将源放在哪里? 您将应用程序启动脚本放在哪里? 您将IDE项目放在哪里? 您将单元/验收测试放在哪里? 您将非Python数据(例如配置文件)放在哪里? 您在哪里将非Python来源(例如C ++)用于pyd / so二进制扩展模块? 回答1 没什么大不了的。 令您快乐的一切都会起作用。 没有很多愚蠢的规则,因为Python项目可以很简单。 /scripts或/bin用于那种命令行界面 /tests为您的测试 /lib用于您的C语言库 /doc获取大多数文档 /apidoc用于Epydoc生成的API文档。 顶级目录可以包含自述文件,配置文件和其他内容。 艰难的选择是是否使用/src树。 像Java或C一样,Python在/src , /lib和/bin之间没有区别。 由于某些人认为顶级/src目录没有意义,因此顶级目录可以是应用程序的顶级体系结构。 /foo /bar /baz 我建议将所有这些都放在
  • 数据库,表和列的命名约定? [关闭](Database, Table and Column Naming Conventions? [closed])
    问题 关门了。 这个问题是基于意见的。 它当前不接受答案。 想要改善这个问题吗? 更新问题,以便可以通过编辑此帖子以事实和引用的形式回答。 7年前关闭。 改善这个问题 每当我设计数据库时,我总是想知道是否有一种在数据库中命名项目的最佳方法。 我经常问自己以下问题: 表名应该是复数吗? 列名应为单数吗? 我应该为表格或列添加前缀吗? 我在命名项目时应该使用大小写吗? 是否有建议的指南来命名数据库中的项目? 回答1 我建议检查Microsoft的SQL Server示例数据库:https://github.com/Microsoft/sql-server-samples/releases/tag/adventureworks AdventureWorks示例使用非常清晰和一致的命名约定,该约定使用模式名称来组织数据库对象。 表的单数名称列的单数名称表前缀的架构名称(例如:SchemeName.TableName) Pascal机壳(又名上驼壳) 回答2 这里的答案很晚,但总之: 复数表格名称:我的偏好是复数单列名称:是前缀表或列: 表格:*通常*最好没有前缀。 列数: 在命名项目时使用任何大小写:表和列均使用PascalCase。 详细说明: (1)你必须要做的。 每次您必须以某种方式执行的事情很少,但也有一些。 使用“ [singularOfTableName] ID
  • 为什么要行家? 有什么好处? [关闭](Why maven? What are the benefits? [closed])
    问题 关门了。 这个问题是基于意见的。 它当前不接受答案。 想要改善这个问题吗? 更新问题,以便可以通过编辑此帖子以事实和引用的形式回答。 4年前关闭。 改善这个问题 与使用ant相比,使用maven的主要好处是什么? 它似乎比有用的工具更令人讨厌。 我将maven 2与普通的Eclipse Java EE(没有m2eclipse)和tomcat一起使用。 Maven的支持者认为 Maven让您轻松获取软件包依赖关系 Maven强制您使用标准目录结构 在我的经验中 弄清软件包的依赖关系并不难。 无论如何,您很少这样做。 在项目设置过程中大概一次,在升级过程中可能再一次。 使用maven,您最终将解决不匹配的依赖项,错误编写的pom,以及无论如何都要进行程序包排除。 缓慢的FIX-COMPILE-DEPLOY-DEBUG周期,这会降低生产率。 这是我的主要抱怨。 进行更改后,您必须等待Maven构建启动并等待其部署。 没有任何热部署。 还是我做错了? 请为我指出正确的方向,我无所不知。 回答1 弄清软件包的依赖关系并不难。 无论如何,您很少这样做。 在项目设置过程中大概一次,在升级过程中可能再一次。 使用maven,您最终将解决不匹配的依赖项,错误编写的pom,以及无论如何都要进行程序包排除。 对于玩具项目来说并不难。 但是我从事的项目确实很多,而且我很高兴能够传递它们
  • C#GUI命名约定的最佳做法? [关闭](Best practices for C# GUI naming conventions? [closed])
    问题 关门了。 这个问题是基于意见的。 它当前不接受答案。 想要改善这个问题吗? 更新问题,以便可以通过编辑此帖子以事实和引用的形式回答。 6年前关闭。 改善这个问题 无论用WinForms还是XAML编写的GUI,在我看到的项目之间似乎都有最广泛的命名约定。 对于一个用于人名的简单TextBox ,我已经看到了各种命名约定: TextBox tbName // Hungarian notation TextBox txtName // Alternative Hungarian TextBox NameTextBox // Not even camelCase TextBox nameTextBox // Field after field with TextBox on the end TextBox TextBoxName // Suggested in an answer... TextBox textBoxName // Suggested in an answer... TextBox uxName // Suggested in an answer... TextBox name // Deceptive since you need name.Text to get the real value TextBox textBox1 // Default name
  • 您对Java中的个人/爱好项目使用什么程序包命名约定?(What package naming convention do you use for personal/hobby projects in Java?)
    问题 我已经熟悉使用域名创建唯一的包名称(即com.stackoverflow.widgets包)的标准Java包命名约定。 但是,对于如何为个人项目选择程序包名称,我从未见过任何建议。 我认为是因为这确实是个人喜好问题。 因此,如何为永远不会投入生产的个人项目选择软件包名称(您可能会在业余时间尝试使用新框架)。 假设您没有一个个人网站,可以使用其域来创建您的包裹结构,您将(或将要)做什么? 您是否具有用于为爱好项目生成新软件包名称的逻辑系统,还是仅使用了简单的mypackage软件包名称(如mypackage ? 由于我只是想知道人们对此有何不同的想法,因此我将其设为社区Wiki。 就我个人而言,我从来没有想过,但是我想今晚与Wicket一起玩耍,结果发现我对如何组织自己的业余项目并不清楚。 对于爱好项目,至少有一个单独的,不同的程序包命名约定(至少在我看来是这样),将是使个人代码和与工作相关的代码清晰区分的一种好方法。 我在考虑一个简单的层次命名约定,以将个人项目的源代码保存在单个根文件夹中: 使用myprojects作为根文件夹追加项目名称添加任何其他子包名称 因此,我的Wicket项目将在myprojects.learningwicket包中,而单元测试将在myprojects.learningwicket.tests包中。 回答1 如果您只是在做个人项目
  • 我应该停止使用Visual Studio的默认名称空间命名约定吗? [关闭](Should I stop fighting Visual Studio's default namespace naming convention? [closed])
    问题 关门了。 这个问题是基于意见的。 它当前不接受答案。 想要改善这个问题吗? 更新问题,以便通过编辑此帖子以事实和引用的形式回答。 12个月前关闭。 改善这个问题 我正在MVVM项目上工作,因此我的项目中有模型,ViewModels,Windows等文件夹。每当我创建一个新类时,Visual Studio都会自动将文件夹名称添加到名称空间名称中,而不仅仅是保留项目-级别名称空间。 因此,将新类添加到ViewModels文件夹将导致命名空间MyProject.ViewModels而不是MyProject 。 当我第一次遇到这个问题时,这让我很烦。 我的类名称非常清楚,有时甚至包含其中的文件夹名称(例如ContactViewModel )。 我很快发现自己手动删除了命名空间上的文件夹名称。 我什至尝试过创建一个自定义类模板(请参阅此问题),但是我无法使其正常工作,因此继续手动进行。 不过,我开始怀疑,是否存在这个约定是出于我没有看到的充分理由。 如果您出于某种原因将许多相同的类名组织到文件夹中,我会发现它很有用,但这似乎不是一个特别常见的情况。 问题: 为什么命名空间名称反映文件夹结构是通用约定? 您遵守这个约定吗? 为什么? 回答1 和您一样-我为此战斗了最长的时间。 然后,我开始考虑为什么创建文件夹。 我发现自己开始创建表示名称空间和程序包的文件夹,而不是任意存储桶。 例如
  • 还有其他人发现命名类和方法是编程中最困难的部分之一吗? [关闭](Anyone else find naming classes and methods one of the most difficult parts in programming? [closed])
    问题 从目前的情况来看,这个问题不适合我们的问答形式。 我们希望答案得到事实,参考或专业知识的支持,但是这个问题可能会引起辩论,争论,民意测验或进一步的讨论。 如果您认为此问题可以解决并且可以重新提出,请访问帮助中心以获取指导。 8年前关闭。 因此,我正在研究该类,该类应通过网络服务向供应商索取帮助文档。 我尝试将其命名为DocumentRetriever , VendorDocRequester , DocGetter ,但它们听起来并不正确。 我最终浏览了dictionary.com半个小时,试图给出一个适当的单词。 用坏名字开始编程就像早上头发非常糟糕,一天的其余部分从那里走下坡路一样。 感觉到我吗? 回答1 您现在正在做的事还不错,我强烈建议您坚持使用当前的语法,即: 上下文+动词+方式 我使用这种方法来命名函数/方法,SQL存储过程等。通过保持这种语法,它将使您的Intellisense /代码窗格更加整洁。 因此,您需要EmployeeGetByID()EmployeeAdd(),EmployeeDeleteByID()。 当您使用语法上更正确的语法(例如GetEmployee(),AddEmployee())时,如果在同一个类中有多个Get,则将变得非常混乱,因为无关的东西将被组合在一起。 我类似于将文件命名为日期,您要说的是2009-01-07.log而不是1-7
  • 在目标C中使用下划线为属性名称加上前缀(Prefixing property names with an underscore in Objective C [duplicate])
    问题 这个问题已经在这里有了答案: 8年前关闭。 以前,我避免在变量名中使用下划线,这可能是我在大学Java时代的后遗症。 因此,当我在目标C中定义属性时,这自然是我要做的。 // In the header @interface Whatever { NSString *myStringProperty } @property (nonatomic, copy) NSString *myStringProperty; // In the implementation @synthesize myStringProperty; 但在几乎每个示例中,它都像 // In the header @interface Whatever { NSString *_myStringProperty } @property (nonatomic, copy) NSString *myStringProperty; // In the implementation @synthesize myStringProperty = _myStringProperty; 我应该克服对下划线的厌恶,因为那是应该做的一种方式,是否有充分的理由使这种样式成为首选? 更新:如今,使用自动属性合成,您可以省去@synthesize,其结果与您使用过的相同 @synthesize myStringProperty =
  • 什么时候写“ ad hoc sql”比存储过程更好?(When is it better to write “ad hoc sql” vs stored procedures [duplicate])
    问题 这个问题已经在这里有了答案: 将SQL保留在存储过程与代码中的优缺点是什么[关闭] (47个答案) 4年前关闭。 我在整个应用程序中都有100%即席sql。 我的一个伙伴建议我将其转换为存储过程,以提高性能和安全性。 这在我脑海中提出了一个问题,除了速度和安全性之外,还有别的理由继续使用即席sql查询吗? 回答1 SQL Server缓存临时查询的执行计划,因此(在扣除第一次调用所花费的时间上),这两种方法在速度方面将是相同的。 通常,使用存储过程意味着获取应用程序所需的部分代码(T-SQL查询)并将其放在不受源代码控制的位置(可以,但通常不是),并且在其他人不知情的情况下可以更改的地方。 将查询放在这样的中心位置可能是件好事,这取决于有多少不同的应用程序需要访问它们代表的数据。 我通常发现将驻留在应用程序代码本身中的应用程序所使用的查询保持在容易得多。 在1990年代中期,传统观点认为,在性能至关重要的情况下,SQL Server中的存储过程是必经之路,而在当时确实如此。 但是,这种CW背后的原因很长一段时间都没有成立。 更新:此外,在关于存储过程的生存能力的辩论中,经常会在防止proc的过程中调用防止SQL注入的需求。 当然,没有人会认为通过字符串串联来组装即席查询是正确的做法(尽管这只会在串联用户输入时使您遭受SQL注入攻击)。 显然,应该对临时查询进行参数设置
  • SQL表别名-好还是坏? [关闭](SQL Table Aliases - Good or Bad? [closed])
    问题 关门了。 这个问题是基于意见的。 它当前不接受答案。 想要改善这个问题吗? 更新问题,以便通过编辑此帖子以事实和引用的形式回答。 7年前关闭。 改善这个问题 在SQL中使用表别名的优缺点是什么? 我个人试图避免使用它们,因为我认为它们会使代码的可读性降低(尤其是在阅读大的where / and语句时),但是我有兴趣听取与此相反的观点。 通常,什么时候使用表别名是个好主意,并且您有任何首选的格式吗? 回答1 当处理高度标准化的模式时,表别名是必不可少的。 例如,由于我不是该数据库的架构师,所以请耐心等待,它需要进行7次连接才能获得完整干净的记录,其中包括一个人的姓名,地址,电话号码和公司隶属关系。 我倾向于使用短单词别名,而不是有些标准的单字符别名,因此上面示例的SQL最终看起来像: select person.FirstName ,person.LastName ,addr.StreetAddress ,addr.City ,addr.State ,addr.Zip ,phone.PhoneNumber ,company.CompanyName from tblPeople person left outer join tblAffiliations affl on affl.personID = person.personID left outer join
  • 用这四种不同的方式输入参数有什么区别? [关闭](What is the difference between entering parameters in these four different ways? [closed])
    问题 关门了。 这个问题需要更加集中。 它当前不接受答案。 想要改善这个问题吗? 更新问题,使其仅通过编辑此帖子即可将重点放在一个问题上。 6年前关闭。 改善这个问题 我经常看到以四种不同的方式添加VBA参数: wks.Cells.Find(“ *”,,,,,xlByRows,xlPrevious)-包含用逗号分隔的值的括号 vls.Add vl-空格后跟值 copyRange.Copy目标:= Cells(countD,2)-空格后跟标签,特殊符号:=和值 wks.Cells.Find(lookFor:=“ *”)-包含标签,特殊符号:=和值的括号 所以似乎有维度: 是否带括号标签:=值或值 我可以一直使用任何方法吗? 什么时候比另一个更合适 回答1 是否带括号 通常,在以下情况下使用括号: 1)将结果分配给变量: 正确的: Set rng = wks.Cells.Find("*", , , , xlByRows, xlPrevious) 不正确: Range("A1:A5").Copy (Destination:=Range("C1")) 2)做某事与结果: wks.Cells.Find("*", , , , xlByRows, xlPrevious).Activate 3)与Call关键字一起使用: 正确的: Call Range("A1:A5").Copy
  • 命名git分支的常用做法有哪些例子? [关闭](What are some examples of commonly used practices for naming git branches? [closed])
    问题 关门了。 这个问题是基于意见的。 它当前不接受答案。 想改善这个问题吗? 更新问题,以便通过编辑此帖子以事实和引用的形式回答。 4年前关闭。 改善这个问题 几个月来,我一直在使用本地git存储库与小组的CVS存储库进行交互。 我已经做出了几乎神经质的分支,幸运的是,其中大多数已经合并回了我的树干。 但是命名已经开始成为一个问题。 如果我有一个用简单标签轻松命名的任务,但是我分三个阶段完成任务,每个阶段都包括自己的分支和合并情况,那么我可以每次重复分支名称,但这会使历史有些混乱。 如果我在名称上更具体,并且每个阶段都有单独的描述,则分支名称开始变得冗长而笨拙。 我确实在这里学习过旧线程,可以开始用名称/命名分支,即主题/任务或类似名称。 我可能会开始这样做,看看它是否有助于使事情井井有条。 命名git分支的最佳做法是什么? 编辑:实际上没有人建议任何命名约定。 处理完分支后,我会删除它们。 由于管理人员不断调整我的工作重点,所以我碰巧遇到了几个问题。 :)作为一个示例,为什么我可能在一个任务上需要多个分支,假设我需要将该任务中的第一个离散里程碑提交到组的CVS存储库。 到那时,由于我与CVS的互动不完善,我将执行该提交,然后终止该分支。 (如果我尝试在那一刻继续使用同一分支,我已经看到与CVS交互的怪异之处。) 回答1 这是我使用的一些分支命名约定及其原因 分支命名约定
  • C ++中的函数名称:是否大写? [关闭](Function names in C++: Capitalize or not? [closed])
    问题 关门了。 这个问题是基于意见的。 它当前不接受答案。 想要改善这个问题吗? 更新问题,以便通过编辑此帖子以事实和引用的形式回答。 5年前关闭。 改善这个问题 C ++中命名函数的约定是什么? 我来自Java环境,因此我通常会这样命名: myFunction(...) { } 我看过C ++中的混合代码, myFunction(....) MyFunction(....) Myfunction(....) 正确的方法是什么? 此外,类方法和非类方法是否都一样? 回答1 没有“正确的方法”。 尽管有一些约定,但它们在语法上都是正确的。 您可以按照Google样式指南进行操作,尽管还有其他方法。 从所说的指南: 常规功能混合使用大小写; 访问器和更改器匹配变量的名称:MyExcitingFunction(),MyExcitingMethod(),my_exciting_member_variable(),set_my_exciting_member_variable()。 回答2 从C ++ 11开始,您可能要使用snake_case或camelCase作为函数名。 这是因为要使一个类在基于范围的for循环中作为范围表达式工作,您必须为该类定义称为begin和end (区分大小写)的函数。 因此,对函数名称使用例如PascalCase意味着如果您需要使基于班级的for类工作
  • 您被迫遵循的最奇怪的编码标准规则是什么? [关闭](What was the strangest coding standard rule that you were forced to follow? [closed])
    问题 从目前的情况来看,这个问题不适合我们的问答形式。 我们希望答案会得到事实,参考或专业知识的支持,但是这个问题可能会引起辩论,争论,民意测验或进一步的讨论。 如果您认为此问题可以解决并且可以重新提出,请访问帮助中心以获取指导。 9年前关闭。 已锁定。 该问题及其答案被锁定,因为该问题是题外话,但具有历史意义。 它目前不接受新的答案或互动。 当我问这个问题时,我几乎总是可以肯定的是,您应该有编码标准。 您曾经被迫遵循的最奇怪的编码标准规则是什么? 最奇怪的是,我的意思是最有趣,最坏,或者很奇怪。 在每个答案中,请提及哪种语言,您的团队规模以及对您和您的团队造成的不良影响。 回答1 当禁止使用多次退货时,我讨厌它。 回答2 反向缩进。 例如: for(int i = 0; i < 10; i++) { myFunc(); } 和: if(something) { // do A } else { // do B } 回答3 也许这不是您所能获得的最奇怪的东西,但是当我不得不在数据库表名的开头加上'tbl'时,我真的非常讨厌 回答4 几乎任何种类的匈牙利符号。 匈牙利符号的问题在于,它经常被误解。 最初的想法是为变量加上前缀,以使含义很清楚。 例如: int appCount = 0; // Number of apples. int pearCount = 0; // Number
  • XML元素是否有标准的命名约定? [关闭](Is there a standard naming convention for XML elements? [closed])
    问题 关闭。 此问题不符合堆栈溢出准则。 它当前不接受答案。 想要改善这个问题吗? 更新问题,使它成为Stack Overflow的主题。 4年前关闭。 改善这个问题 是否存在XML文档的事实上的标准或其他标准? 例如,哪种是编写标签的“最佳”方法? <MyTag /> <myTag /> <mytag /> <my-tag /> <my_tag /> 同样,如果我有一个更好的属性的枚举值 <myTag attribute="value one"/> <myTag attribute="ValueOne"/> <myTag attribute="value-one"/> 回答1 我怀疑最常见的价值观会是驼峰式的-即 <myTag someAttribute="someValue"/> 特别是,如果与代码生成器混合使用,空格会引起一些小故障(即,将xml反序列化为对象),因为没有太多的语言允许枚举使用空格(要求两者之间有映射关系)。 回答2 XML命名规则 XML元素必须遵循以下命名规则: - Element names are case-sensitive - Element names must start with a letter or underscore - Element names cannot start with the letters xml(or XML
  • 表命名难题:单数与复数名称(Table Naming Dilemma: Singular vs. Plural Names [closed])
    问题 关门了。 这个问题是基于意见的。 它当前不接受答案。 想要改善这个问题吗? 更新问题,以便可以通过编辑此帖子以事实和引用的形式回答。 7年前关闭。 改善这个问题 学术界认为表名应该是存储其属性的实体的单数形式。 我不喜欢任何需要在名称两边加上方括号的T-SQL,但是我已经将Users表重命名为单数,永远判罚使用该表的用户有时不得不使用方括号。 我的直觉是,单数形式更正确,但我的直觉是,方括号表示不受欢迎的内容,例如列名中带有空格等。 我应该走还是留? 回答1 就“标准”而言,其他人给出了很好的答案,但我只想补充一下……“用户”(或“用户”)是否可能实际上不是表中数据的完整描述? ? 并不是说您应该对表名和特定性太过疯狂,但是也许像“ Widget_Users”(其中“ Widget”是您的应用程序或网站的名称)之类的东西更合适。 回答2 我有同样的问题,在阅读完所有答案后,我肯定会选择单数,原因如下: 原因1 (概念)。 您可以想到装有“ AppleBag”之类的苹果的包装袋,无论包含0、1还是一百万个苹果都没关系,它始终是同一个包装袋。 表只是容器,表名必须描述它包含的内容,而不是它包含多少数据。 另外,复数概念更多地是关于一种口头语言(实际上是为了确定是否存在一种或多种)。 原因2 。 (方便)。 单数名称比复数名称更容易出现。 对象可以具有不规则的复数
  • 我应如何命名一个将两个表映射在一起的表? [关闭](What should I name a table that maps two tables together? [closed])
    问题 关门了。 这个问题是基于意见的。 它当前不接受答案。 想要改善这个问题吗? 更新问题,以便可以通过编辑此帖子以事实和引用的形式回答。 4年前关闭。 改善这个问题 假设我有两个表: Table: Color Columns: Id, ColorName, ColorCode Table: Shape Columns: Id, ShapeName, VertexList 我该如何称呼将颜色映射为形状的表? Table: ??? Columns: ColorId, ShapeId 回答1 在计算机科学中只有两件难事:缓存无效和命名事物 -菲尔·卡尔顿(Phil Karlton) 为代表many-to-many关系的表命名一个好名字,可以使关系更容易阅读和理解。 有时候,找到一个好名字并非易事,但通常值得花一些时间思考。 例如: Reader和Newspaper 。 Newspaper有很多Readers而Reader有很多Newspapers 您可以将关系称为NewspaperReader但是类似Subscription的名称可能会更好地传达表的含义。 如果您以后想要将表映射到对象,则名称Subscription也比较惯用。 命名many-to-many表的约定是关系中涉及的两个表的名称的串联。 在您的情况下, ColourShape将是明智的默认选择。 就是说,我认为Nick
  • Java中的接口命名(Interface naming in Java [closed])
    问题 从目前的情况来看,这个问题不适合我们的问答形式。 我们希望答案会得到事实,参考或专业知识的支持,但是这个问题可能会引起辩论,争论,民意测验或进一步的讨论。 如果您认为此问题可以解决并且可以重新提出,请访问帮助中心以获取指导。 8年前关闭。 大多数OO语言用大写的I前缀它们的接口名称,为什么Java不这样做呢? 不遵守该公约的理由是什么? 为了说明我的意思,如果我想拥有一个用户界面和一个用户实现,那么在Java中我有两种选择: 类=用户,接口= UserInterface 类= UserImpl,接口=用户 在大多数语言中: 类=用户,接口= IUser 现在,您可能会争辩说,您总是可以为用户实现选择一个最具描述性的名称,并且问题消失了,但是Java将POJO方法推向了事物,并且大多数IOC容器广泛使用DynamicProxies。 这两件事共同意味着一个POJO实现将具有很多接口。 因此,我想我的问题可以归结为: “是否值得遵循更广泛的接口命名约定,尤其是考虑到Java框架的发展方向?” 回答1 我不想在接口上使用前缀: 前缀会损害可读性。 在客户端中使用接口是进行编程的最佳标准方法,因此接口名称应尽可能简短和令人愉快。 实施类应该更丑陋,以阻止其使用。 当从抽象类更改为接口时,带前缀的编码约定意味着重命名该类的所有出现---不好! 回答2 之间真的有区别吗? class
  • git标签有一个标准的命名约定吗? [关闭](Is there a standard naming convention for git tags? [closed])
    问题 关门了。 这个问题是基于意见的。 它当前不接受答案。 想要改善这个问题吗? 更新问题,以便通过编辑此帖子以事实和引用的形式回答。 6年前关闭。 改善这个问题 我已经看到很多项目使用v1.2.3作为git中标签的命名约定。 我也看到了一些用法1.2.3 。 是否有正式认可的样式,或者有使用它们的任何良好论据? 回答1 GitHub著名的Tom Preston-Werner撰写的Semantic Versioning 1.0.0版本有一个子规范可以解决这个问题: 标记规范(SemVerTag) 如果您使用版本控制系统(Git,Mercurial,SVN等)来存储代码,则应使用此子规范。 使用此系统,自动化工具可以检查您的软件包并确定SemVer符合性和发行版本。 在版本控制系统中发布标签时,版本的标签必须为“ vX.YZ”,例如“ v3.1.0” 。 但是,在讨论之后,此内容已被删除,并且在最新版本的SemVer规范(撰写本文时为2.0.0)中不再存在。 后来在同一地方进行的讨论更加深入,并产生了新的“ v1.2.3”是否是语义版本? 被添加到SemVer的master分支的FAQ中,尽管在撰写本文时(超过2年),此更改仍未出现在正式发布的规范中。 回答2 似乎有两个主要的约定(假设您还遵守一些合理的标准来对发行版本身进行编号): v1.2.3 1.2.3 v1.2