是否有充分的理由为SQL关键字使用大写?

时间:2008-11-15 02:22:44

标签: sql coding-style capitalization

默认似乎是大写,但是否真的有任何理由对关键字使用大写?我开始使用大写,因为我只是试图匹配SQL Server在我尝试创建内容时给出的内容,例如新的存储过程。但是,我觉得我的宝宝(第5个)手指感觉很糟糕,总是需要按住 Shift 按钮,所以我停止使用大写。有什么理由我应该回到大写?

编辑:谢谢你的回答。在COBOL为王的时候,我还没有编程,所以我没有意识到这一点。从现在开始我会坚持使用小写字母。

17 个答案:

答案 0 :(得分:135)

个人而言,我不喜欢我的SQL问我。它让我了解了基本或合作。

所以我更喜欢带有数据库对象名称MixedCase的T-SQL小写。

阅读起来容易得多,文字和评论也很突出。

答案 1 :(得分:95)

这只是一种风格问题,可能源于编辑不进行代码着色的日子。

我以前更喜欢所有大写字母,但我现在倾向于所有较低的情况。

答案 2 :(得分:71)

SQL IS OLD。大型案例正在破灭。它看起来很奇怪,而且很有可能。

虽然可以说是正确的,但没有一个解决特殊于SQL语言的原因为什么大写关键字是一个很好的约定。

与许多较新的语言不同,SQL具有大量关键字,并且依赖于读者能够区分关键字与标识符以便在心理上解析语法。

然后,对您的问题的直接回答更多地回答“为什么SQL代码的读者从大写关键字中获益如果对大多数现代语言不那么真实?” :

  • 依赖于将关键字保持在一个人的头脑对于许多现代语言来说是合理的,但对于SQL来说是不合理的;它有太多关键字和太多变种。

  • 依赖标点符号对大多数现代语言来说都是合理的,但对SQL来说是不合理的;它太少了,而是取决于关键字的精确顺序来表示语法。

  • 依靠自动荧光笔来区分关键词对于现代语言来说是合理的,但忽略了荧光笔可以为SQL实现的现实。大多数都没有涵盖SQL的所有变体的所有关键字,无论如何,SQL经常被常规读取在荧光笔无法帮助的环境中。

这些是特定于SQL的一些原因,SQL代码的读者最好通过标准化大写关键字,并且只使用not-upper(即更低或混合) )标识符的案例。

突出显示有时可以提供帮助。但只有荧光笔知道你有SQL;我们经常在上下文中使用SQL,编辑器/格式化程序无法合理地知道它正在处理SQL。示例包括内联查询,程序员文档以及另一种语言代码中的文本字符串。对于像Python或C ++这样的语言来说,这种情况并不常见;是的,他们的代码有时会出现在那些地方,但它并不像SQL代码那样按常规方式完成。

此外,读者通常会使用只知道您的特定SQL实现使用的关键字子集的荧光笔。许多不太常见的关键字不会被突出显示,除非是一个非常了解您的SQL变体的关键字。所以读者,即使他们使用荧光笔,仍然需要一些更直接的方法来区分任何中等复杂的SQL语句中的关键字。

因此,读者经常 - 并且作者不能提前知道这将是什么 - 需要来自SQL语句本身的内容的帮助,知道作者作为关键词的意图是什么,以及作为一个关键词的目的是什么标识符。因此 SQL内容本身需要区分读者的关键字,使用大写关键字是传统且有用的方法。

答案 3 :(得分:31)

戈登贝尔的例子并不完全正确;通常,只突出显示关键字,而不是整个查询。他的第二个例子看起来像:

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

答案 4 :(得分:28)

由于相关编码(ASCII)未被发现,因此大多数人都没有能够编写任何超出大写字母的可能性。 ONLY SIX BITS WERE AVAILABLE。 SQL是最新的,较低的案例信函在编程时并不常见。

请注意SOME PEOPLE CLAIM数据库会产生紧急情况并使您的查询更快。

答案 5 :(得分:21)

我们阅读的文字中只有不到10%的字母是大写字母。因此,我们的大脑更倾向于识别小写字母而不是大写字母。研究表明,阅读大写文本需要更长的时间。这只是一个例子:

http://www.guardian.co.uk/media/mind-your-language/2010/oct/04/new-york-street-signs-capitals

我认为上面的例子强调,即使你只谈论一两个词,也会产生影响。

答案 6 :(得分:16)

这是因为SQL是一种古老的语言(1974),在构思时,大多数键盘都没有小写字母!语言文档只反映了当时的技术。

没有充分的理由使用大写字母。我个人不喜欢使用大写的SQL关键字。阅读起来比较困难,在这个时代是荒谬的,没必要; SQL语言被定义为不区分大小写。

答案 7 :(得分:8)

猴子看,猴子为我做。模式匹配 - 如果我按照我所看到的方式进行,则子句的结构在心理上更容易排列。

答案 8 :(得分:8)

大写可以提供关键字可见性的增益,但您可以使用代码突出显示和缩进进行补偿 我们使用小写,因为查询编辑器和其他工具在编辑t-sql代码时确实很奇怪,我们认为没有必要折磨小指。

答案 9 :(得分:7)

大写不太可读。所有单词的轮廓形状像盒子;没有下降器或上升器。小写FTW!

答案 10 :(得分:5)

我觉得它更具可读性。对于每个子句的开头都有换行符和在子句之间缩进相同。

答案 11 :(得分:2)

继续使用大小写的原因之一是当您(或其他人)在记事本中查看代码时,它会使阅读更容易。即,您可以轻松区分“关键字”和表名,SP,udf等

答案 12 :(得分:2)

尝试格式化产品(我使用Red Gate中的SQL Prompt / SQL Refactor)。您可以设置大写的工作方式,并始终对代码进行一致的格式化。休息你的小指,让电脑为你工作。

答案 13 :(得分:1)

除符合标准外,没有。虽然这是一个非常主观的话题,但我更喜欢对所有SQL使用混合大小写。 SQL更容易阅读,并且在现代IDE中没有任何东西丢失,其中关键字都是彩色编码的。

答案 14 :(得分:1)

Microsoft SQL Server Management Studio中的intellisense / autocompletion允许保留字的大写或小写,但大写函数调用如MAX(),SUM()。

即便如此,解析器仍允许处理小写版本的max()和sum()。

这意味着对执行性质的矛盾,因此仅仅是个人偏好的问题。

答案 15 :(得分:0)

我不喜欢用大写字母写的任何内容(并且讨厌更多地输入所有大写字母),但无法说服自己反对社区。像往常一样,Vim及其相关软件包是解决这么多问题的方法:

here

只需按正常方式键入,即可在键入时自动将关键字大写。我没有使用过所有模糊的SQL咒语,但它还没有让我失望。

答案 16 :(得分:-2)

我在PHP中调用了我的大部分mySQL代码,并且我在vim中进行了所有的PHP编辑(或者我想在这种情况下,VIM ;-)。现在我确定有插件可以突出显示PHP中的mySQL代码,但我还没有找到它,而且我没有时间去寻找它。因此,我更喜欢在allcaps中拥有所有内容。我发现了这个:

if ( !$bla ) 
{
   echo "select something from something where something";
}

if ( !$beepboop ) 
{
   echo "create table if not exists loremIpsum;
}

$query = "
CREATE TABLE IF NOT EXISTS HISTORY
(
   ID INT NOT NULL AUTO_INCREMENT,
   INSERTDATE TIMESTAMP DEFAULT NOW(),
   ALTERDATE TIMESTAMP(8) DEFAULT NOW(),
   DELETEDATE TIMESTAMP(8),
   ALTERCOUNT INT DEFAULT 0,
   SELECTCOUNT INT DEFAULT 0,

   PRIMARY KEY(ID),
)ENGINE=InnoDB
";

mysqlQuery( $query, $con );

帮助我区分PHP与SQL比这更好:

if ( !$bla ) 
{
   echo "select something from something where something";
}

if ( !$beepboop ) 
{
   echo "create table if not exists loremIpsum;
}

$query = "
create table if not exists history
(
   id int not null auto_increment,
   insertdate timestamp default now(),
   alterdate timestamp(8) default now(),
   deletedate timestamp(8),
   altercount int default 0,
   selectcount int default 0,

   primary key(id),
)engine=InnoDB
";

mysqlQuery( $query, $con );

另外,出于某种原因,我讨厌将所有帽子与驼峰盒混合在一起,如下所示:

CREATE TABLE IF NOT EXISTS history
(
   ID INT NOT NULL AUTO_INCREMENT,
   insertDate TIMESTAMP DEFAULT NOW(),
   alterDate TIMESTAMP(8) DEFAULT NOW(),
   deleteDate TIMESTAMP(8),
   alterCount INT DEFAULT 0,
   selectCount INT DEFAULT 0,

   PRIMARY KEY(ID),
)ENGINE=InnoDB

ID让我烦恼。它应该是id吗?还是iD