默认似乎是大写,但是否真的有任何理由对关键字使用大写？我开始使用大写,因为我只是试图匹配SQL Server在我尝试创建内容时给出的内容,例如新的存储过程.但是,我觉得我的宝宝(第5个)手指感觉很糟糕,总是需要按住Shift按钮,所以我停止使用大写.有什么理由我应该回到大写？
编辑:谢谢你们的答案.在COBOL成为国王的时代,我还没有编程,所以我没有意识到这一点.从现在开始我会坚持使用小写字母.
个人而言,我不喜欢我的SQL在我身上.它使我了解基本或COBOL.
所以我更喜欢我的T-SQL小写与数据库对象名称MixedCase.
阅读起来容易得多,文字和评论也很突出.
这只是一种风格问题,可能源于编辑不进行代码着色的日子.
我以前更喜欢所有大写字母,但我现在倾向于所有较低的情况.
SQL IS OLD.大型案例正在出现.它看起来很奇怪,也很容易.
虽然可以说是正确的,但没有一个能解决SQL语言特有的原因,为什么大写关键字是一个很好的约定.
与许多较新的语言不同,SQL具有大量关键字,并依赖于读者区分关键字与标识符的能力,以便在心理上解析语法.
因此,对您的问题的直接回答更像是"为什么SQL代码的读者从大写关键字中受益如此之大,而对于大多数现代语言来说并不如此？":
依赖于将关键字保持在一个人的头脑中对于许多现代语言来说是合理的,但对SQL来说是不合理的 ; 它有太多的关键字和太多的变种.
对于大多数现代语言来说,依赖标点符号是合理的,但对SQL来说是不合理的 ; 它太少了,而是取决于关键字的精确顺序来指示语法.
在通常的情况下,依靠自动荧光笔来区分关键词对于现代语言是合理的,但忽略了荧光笔可以为SQL实现的现实.大多数都没有涵盖SQL的所有变体的所有关键字,并且无论如何,SQL经常在高亮显示器无法帮助的环境中进行常规读取.
这些是特定于SQL的一些原因,SQL代码的读者最好通过标准化关键字的大写字母,并且仅对标识符使用非上限(即较低或混合)的情况.
突出显示有时可以提供帮助.但只有荧光笔知道你有SQL; 我们经常在上下文中使用SQL,编辑器/格式化程序无法合理地知道它正在处理SQL.示例包括内联查询,程序员文档以及另一种语言代码中的文本字符串.对于像Python或C++这样的语言来说,这种情况并不常见; 是的,他们的代码有时会出现在那些地方,但它并不像SQL代码那样按常规方式完成.
此外,读者通常会使用只知道特定SQL实现使用的关键字子集的荧光笔.许多不太常见的关键字不会被突出显示,除非是一个非常了解您的SQL变体的关键字.因此,即使读者使用荧光笔,读者仍需要更直接的方法来区分任何中等复杂的SQL语句中的关键字.
因此,读者经常 - 并且作者不能提前知道 - 将需要来自SQL语句本身的内容的帮助,知道作者关键词的意图以及作为标识符的意图.因此,SQL内容本身需要为阅读器区分关键字,使用大写关键字是执行此操作的常规且有用的方法.
戈登贝尔的例子并不完全正确; 通常,只突出显示关键字,而不是整个查询.他的第二个例子如下:
SELECT name, id, xtype, uid, info, status,
base_schema_ver, replinfo, parent_obj, crdate,
ftcatid, schema_ver, stats_schema_ver, type,
userstat, sysstat, indexdel, refdate, version,
deltrig, instrig, updtrig, seltrig, category, cache
FROM sysobjects
WHERE category = 0
AND xtype IN ('U', 'P', 'FN', 'IF', 'TF')
ORDER BY 1
我发现这更容易阅读,因为关键词更突出.即使语法突出显示,我发现非资本化的例子更难以阅读.
在我的公司,我们的SQL格式更进一步.
SELECT name, id, xtype, uid, info, status,
base_schema_ver, replinfo, parent_obj, crdate,
ftcatid, schema_ver, stats_schema_ver, type,
userstat, sysstat, indexdel, refdate, version,
deltrig, instrig, updtrig, seltrig, category, cache
FROM sysobjects
LEFT JOIN systhingies ON
sysobjects.col1=systhingies.col2
WHERE category = 0
AND xtype IN ('U', 'P', 'FN', 'IF', 'TF')
ORDER BY 1
由于相关的编码(ASCII)没有被发现,所以有一段时间,大多数人都没有能够编写任何超过大写字母的可能性.只有六个位可用.虽然SQL是最新的,但更简洁的案例信函在编程时并不常见.
需要注意的是有些人声称,该数据库将得到一种紧迫感,并运行你的查询速度更快.
我们阅读的文字中只有不到10%的字母是大写的.因此,我们的大脑更倾向于识别小写字母而不是大写字母.研究表明,阅读大写文本需要更长的时间.这只是一个例子:
http://www.guardian.co.uk/media/mind-your-language/2010/oct/04/new-york-street-signs-capitals
我认为上面的例子强调,即使你只谈论一两个词,它也会产生影响.
这是因为SQL是一种古老的语言(1974),当它被构思时,大多数键盘都没有小写字母!语言文档只反映了当时的技术.
没有充分的理由使用大写字母.我个人不喜欢使用大写的SQL关键字.阅读起来比较困难,在这个时代是荒谬的,没必要; SQL语言定义为不区分大小写.
大写可以提供关键字可见性的增益,但您可以使用代码突出显示和缩进进行补偿.
我们使用小写,因为查询编辑器和其他工具在编辑t-sql代码时确实很奇怪,我们认为没有必要折磨小指.
猴子看,猴子为我做.模式匹配 - 如果我按照我所看到的方式进行,则子句的结构在心理上更容易排列.
大写不太可读.所有单词的轮廓形状像盒子; 没有下降器或上升器.小写FTW!
我发现它更具可读性.对于每个子句的开头有一个换行符和在子句之间缩进相同.
京公网安备 11010802040832号 | 京ICP备19059560号-6 