|
|
1
24
作为大型开发团队的一员,我的经验是,您可以继续定义您喜欢的任何标准,但问题实际上是强制执行这些标准,或者使开发人员能够非常容易地实现这些标准。 作为开发人员,我们有时会创建一些有用的东西,然后说稍后将对其进行格式化,但以后再也不会出现这种情况。 最初,我们使用了SQL提示符(非常好),但后来切换到 ApexSQL Refactor ,因为这是一个免费的工具。 |
|
|
2
20
我的观点是,只要你能很容易地阅读源代码,格式是次要的。只要实现这一目标,就可以采用许多良好的布局样式。
仅供参考,以下是我将如何介绍您提供的示例,只是我的布局偏好。特别值得注意的是
一个提示,给自己一份 SQL Prompt 从…起 Red Gate . 您可以自定义工具以使用所需的布局首选项,然后您商店中的编码人员都可以使用它来确保每个人都采用相同的编码标准。 |
|
|
3
19
我来晚了,但我只想添加我喜欢的格式样式,我一定是从书本和手册中学到的:它很紧凑。这是样品
这个
和
现在,让我第一个承认这种风格有它的问题。8个空格的缩进表示
但不管出于什么原因,我仍然觉得它比其他选择更容易阅读。
最后,我将使用这种格式样式完成我最近的一个更复杂的创作。几乎所有你在一次旅行中遇到的事情
|
|
|
4
7
迟到了,但我要参加比赛。写起来要花更长的时间,但我发现垂直对齐的模式会出现,一旦你习惯了,它就会变得非常可读。
|
|
|
5
6
美好的作为Python程序员,以下是我的首选项:
当代码可以更紧凑、可读性更高时,我通常更喜欢更紧凑的形式。能够在一个完整的屏幕中容纳更多的代码可以提高生产率。
最终,这将是在代码审查期间做出的判断。
对于
这种格式的原因是,如果SQL对块结构使用缩进(如Python),则不需要括号。因此,如果使用缩进,则括号对布局的影响最小。这是通过将它们放置在行的末尾来实现的。 |
|
|
6
6
|
|
|
7
6
我正在用C#编写一个开源SQL格式化程序(仅在现阶段使用SQL Server),因此我完成了上面的查询。 它采用了与OP类似的策略,即每个“部分”下都有缩进的子元素。在需要的地方,我在节之间添加空白以帮助清晰,在没有连接或最小Where条件时不会添加这些空白。 结果:
|
|
|
8
4
根据约翰的建议,我建议采用以下风格:
优势:
|
|
|
9
3
我倾向于使用与您类似的布局,尽管我甚至更进一步,例如:
也许一开始它看起来有点过头了,但鉴于SQL的声明性,以这种方式使用表格给出了最干净、最系统的布局。 你可能会在这里得到各种各样的答案。最终,这取决于个人或团队同意的偏好。 |
|
10
2
保持8个字符的缩进是IMHO可读性的关键。 |
|
|
11
2
我还倾向于将括号放在新行上,与上面的行对齐,然后在下一行缩进,尽管对于简短的语句,我可能只是将括号放在原始行上。例如:
对于
|
|
|
12
2
common table expressions (CTEs)还没有。下面将其与我使用的其他一些样式合并:
关于CTE格式的几点:
除了CTE格式之外,还有几点:
我发现与其他领域相比,我更喜欢我的CTE风格。没有尝试过与问题中提出的样式更相似的样式。也许有一天我会做,看看我有多喜欢。我可能会被诅咒在一个选择的环境中,尽管这是一个有趣的诅咒。 |
|
13
1
如果我是白手起家或者没有约定,那么我倾向于遵循你在问题中给出的约定,除了我更喜欢用大写字母作为关键词(只是个人对可读性的偏好)。 我认为SQL格式和其他代码格式约定一样,重要的一点是要有一个约定,而不是约定是什么(当然是在常识范围内!) |
|
|
14
1
是的,我可以看到以某种严格定义的方式布局sql的价值,但是命名约定和您的意图肯定要重要得多。比这重要10倍。
只有我的0.02美元价值 |
|
|
15
1
我喜欢:
在较小的查看区域中获取更多代码。 |
|
|
16
1
这条线有很多优点。我一直试图说服人们使用的一个标准是在每列前面的同一行上放置逗号。像这样:
反对:
我喜欢这种做法的原因是,如果有必要,您可以注释掉一行,并且在运行它时不会出现逗号问题,因为相应的逗号也被注释掉了。我知道我在线程中看到另一个用户也这样做了,但并没有真正指出这一点。这不是给谈话带来的巨大启示,而是我的两分钱。 谢谢 |
|
|
17
1
我完全同意您在项目中和总体上标准化SQL格式的努力。 我也非常同意你的格式选择。我已经提出了几乎相同的一个,除了我还缩进了'join'语句,还有'on'语句一个缩进。 很像你在关键词上使用小写的事实——谁想要那些冲你喊出来的。我还更喜欢小写的表别名,这有助于提高可读性 非常像使用小缩进的事实(4)。我赞成(3)。 我拒绝使用“内部”和“外部”这两个术语,因为它们是不必要的。 下面是如何格式化select语句:
|
|
|
18
1
我意识到这次辩论已经很晚了,但我想谈谈我的想法。我绝对赞成在行首加逗号。就像你说的 Adam Ralph ,注释掉一个字段更容易,而且我还发现,在一开始就不小心漏掉一个逗号更难,虽然这听起来不是什么大问题。过去我花了几个小时试图追踪冗长的T-SQL过程中的意外语法错误,我不小心漏掉了一行末尾的逗号(我相信你们中的一些人可能也这样做了)。我也赞成尽可能多地使用别名。 不过,总的来说,我意识到这完全取决于个人偏好,对某些人有效的东西对其他人无效。只要您能够轻松阅读代码,并且每个开发人员在整个过程中都表现出一定的风格一致性,我认为这是最重要的。 |
|
|
19
1
请评论是否可以做得更好。
|
|
|
20
1
我的答案将与
plugin-help-general-options 网页在线。
我认为展示可用的SQLInForm选项会很有用,而不是漫无目的地谈论我的偏好。下面还列出了我的一些偏好。在我文章的末尾是原始文章中使用的格式化SQL代码(
下面是我的一些偏好注释的概述,考虑到SELECT语句。我会添加所有13个部分的截图;但是这有很多截图,我鼓励你使用免费版——截图,测试格式控制。我将很快测试专业版;但从选项来看,它看起来真的很有用,而且只需20美元。
SQL代码原始查询格式。
转换首选格式(选项2:使用换行符连接)
希望这有帮助。 |
|
|
21
0
我喜欢我的SQL被格式化成这样,尽管只要其意图易于阅读,大多数格式都可以工作。我真的很讨厌看到在查询设计器中创建语句,然后就这样离开了。如果我正在编辑其他人的程序/视图/函数/触发器等,我将尝试保持已经使用的格式(除非它真的很糟糕,否则我将重新格式化整个内容)。 Select语句
更新语句
|
|
|
22
0
我喜欢的风格:
|
|
|
23
0
我用所有的大写来表示动作词、连接词或从句,它们更突出。连接与内部连接相同,因此内部连接不需要写出来,假设在需要时写外部连接或左连接。我的别名也使用小写字母。前面常见的原因如果注释掉最后一列,则上面会出现逗号,查询失败。 |
|
|
24
0
我知道这会造成混乱的差异,因为一个额外的表可能会导致我重新缩进许多行代码,但为了便于阅读,我喜欢它。 |
|
|
25
0
试图使所有团队遵循相同的格式模式是最困难的。我会遵循任何形式,如果其他人都遵循同样的方式,但它从来不是同一个故事。 重写前面文章中提到的一个复杂查询:
|
|
|
26
0
This is my personal SQL style guide
. 它是基于其他几个,但有几个主要的风格特征-小写的关键字,没有无关的关键字(例如。
示例SQL如下所示:
|
|
27
-1
作为一个例子,下面我将如何格式化这个问题中的查询作为一个例子:
和“学生”查询:
|
|
|
28
-5
看来你们中的大多数人仍在使用仅支持800x600的显示器。我的显示器可以显示1920x1080,所以我想把右边的空间都用光。 这个怎么样:
|
|
ttruhcheva · 如何在Power BI中创建灵活的数据标签? 4 年前 |
|
|
M.Walko · 在降价中更改ATX标题的字体大小 8 年前 |
|
|
Adam Waring · Bootstrap 4容器的文本包装 8 年前 |
|
|
Jamie Wilson · 打印文本文件(Python) 8 年前 |
|
|
new2Ubuntu · 在Python3中打印格式化的浮点列表 8 年前 |
|
|
Reilly Ford · 使用导航栏+页面选项卡格式化问题 8 年前 |