Transact-SQL 格式标准(编码样式)
SQL 代码应该如何格式化?
您应该使用哪种缩进?
关键字应该大写吗?
列表应该如何排列?
How should SQL code be formatted?
What sort of indentation should you use?
Should keywords be in upper case?
How should lists be lined up?
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(5)
尽管我意识到这个问题可能由于“主观”而被关闭......我认为这很重要,因为我讨厌落后于其他一些开发人员,他们将所有内容都放在一行中,全部小写。
我希望所有开发人员采用的风格是:
我的意思
是,真的,人们......这太令人讨厌了
Though I realize this question may be closed due to being "subjective"... I think it's important as I hate going behind some other developers who put everything in one line all lowercase.
My style that I like all my devs to adopt is:
Example
I mean, really people... this is nasty
请考虑使用 SSMS 工具包 来格式化您的代码(什么是大写,什么不是)。缩进是一个偏好问题。经验法则是查询“越高”,它的可读性就越高。
这是我如何格式化的示例(与此处显示的示例略有不同)
Please consider using SSMS tools pack to format your code (what is uppercase and not). Indentation is a matter of preference. A rule of thumb would be that 'TALLER' the query, the more readable it is.
Here's an example of how I would format (a little different than the examples shown here)
检查这个
http ://www.simple-talk.com/sql/t-sql-programming/transact-sql-formatting-standards-%28coding-styles%29/
Check this
http://www.simple-talk.com/sql/t-sql-programming/transact-sql-formatting-standards-%28coding-styles%29/
没有硬性规定可以使用任何有关格式的内容。
这些标准通常是特定于组织的,并且按照组织的建议实施。
There is no hard and fast rule to use anything regarding formatting.
The standards are normally organization specific and they are implemented as the organization suggests.
我喜欢下面的布局(一个无意义的查询,只包含一些从一些合理的格式中受益的 SELECT 语句位的示例。)
也总是有一个特定的目标 - 使其尽可能容易调试并识别其中包含的内容。所以:我
的想法是我可以轻松地查看连接条件列表,查看嵌套表(及其别名),查看 CASE 选项,查看自然列表中的按顺序分组。
我通常还可以相当轻松地在一行前加上 -- 来注释掉特定子句,通常只需对 SQL 进行最少的其他修改。我相当不寻常的 JOIN 布局意味着我只需扫描查询的左侧即可查看它是否是等/左/右/交叉连接。当我找到我正在寻找的连接时,我可以扫描所涉及的列(通常是在思考我应该在那里看到哪些列)
一个警告 - 如果语句特别短,例如
我通常不会费心将其分成不同的行。
I favour the following sort of layout (a nonsense query, that just includes a sample of some of the SELECT statement bits that benefit from some sensible formatting.)
There is always a specific goal in mind too- to make it as easy as possible to debug, and identify what is included. So:
The idea being I can easily look through the list of join conditions, see nested tables (and their aliases), look through CASE options, see group by orders in a natural list.
I can also generally fairly easily prefix a line with a -- to comment out a specific clause, with usually minimal other amendments to SQL. My fairly unusual JOIN layout means I can just scan down the left hand side of the query to see whether it's an equi/left/right/cross join. When I find the join I'm looking for, I can then scan down the columns involved (usually while thinking about what columns I should be seeing there)
One caveat - if the statement is particularly short, e.g.
I'd typically not bother separating it on to different lines.