Есть ли веская причина использовать заглавные буквы для ключевых слов SQL? [закрыто]

128

По умолчанию используется верхний регистр, но действительно ли есть причина использовать верхний регистр для ключевых слов? Я начал использовать верхний регистр, потому что просто пытался сопоставить то, что дает мне SQL Server всякий раз, когда я пытался что-то создать, например новую хранимую процедуру. Но потом я почувствовал себя ужасно из-за моего детского (5-го) пальца, который всегда должен удерживать Shiftкнопку, поэтому я перестал использовать верхний регистр. По какой причине я должен вернуться к верхнему регистру?

Изменить : Спасибо за ответы, ребята. Я еще не программировал в те дни, когда COBOL был королем, поэтому я не знал об этом. С этого момента я буду использовать строчные буквы.

Хертанто Ли
источник
9
Попробуйте нажать клавишу CAPS LOCK. :)
MusiGenesis
7
Мне все равно нужно включить CAPS LOCK, когда я хочу писать ключевые слова, а затем выключить, когда я не пишу ключевые слова, и снова включить CAPS LOCK и так далее, и так далее. Это просто хлопот.
Hertanto Lie
17
CAPS, что ... О, вы имеете в виду мою третью клавишу Ctrl?
Дэйв Шерохман,
2
IIRC, самое забавное, что если вы проверите процедуры sp_ в MSSQL, они все в нижнем регистре.
Benjol
1
@Benjol, не все из них, но определенно многие из них, такие как sp_who. Это хорошая идея, по крайней мере, попытаться быть последовательным в одном и том же sproc, чего Microsoft не во многих «случаях». Каламбур, предназначенный. LOL
Gordon Bell

Ответы:

107

Это просто вопрос стиля, вероятно, возникший в те времена, когда редакторы не раскрашивали код.

Раньше я предпочитал верхний регистр, но теперь я склоняюсь ко всему нижнему.

Митч Уит
источник
6
+1 Думаю, я был не единственным, кто использовал все нижние строки для ключевых слов.
dance2die
2
Я бы предположил, что это восходит к тем временам, когда редакторы не раскрашивали код.
Benjol
10
Я почти уверен, что это восходит к тем временам, когда многие машины не поддерживали строчные символы.
Nate CK
1
Думаю, это восходит к дням, когда еще не было цветных мониторов;)
walrii
150

ЛИЧНО МНЕ НЕ НРАВИТСЯ, ЧТО МОЙ SQL КРИЧИТ НА МЕНЯ. ЭТО НАПОМИНАЕТ МЕНЯ ОБ ОСНОВНОМ ИЛИ КОБОЛЕ.

Поэтому я предпочитаю строчные буквы T-SQL с именами объектов базы данных MixedCase.

Его гораздо легче читать, а литералы и комментарии выделяются.

Гордон Белл
источник
8
Это вопрос вкуса. По моему опыту, количество криков не слишком велико - я предпочитаю ключевые слова в верхнем регистре, потому что их намного легче читать, а литералы и комментарии выделяются.
Джонатан Леффлер,
93
+1 за «МНЕ НРАВИТСЯ, ЧТО МОЙ SQL вопит на меня»
dance2die,
8
Я не люблю, когда на меня кричат ​​какой-либо язык, но это не касается вопроса о том, является ли верхний регистр хорошей идеей в SQL.
bignose
86

SQL УСТАРЕЛ. ВЕРХНИЙ ФУТБОЛ КРИЧИТ. ЭТО ВЫГЛЯДИТ СТРАННО И ВОЗМОЖНО УЖАСНО.

Возможно, это правда, но ни один из них не обращается к причинам, специфическим для языка SQL, по которым ключевые слова в верхнем регистре являются хорошим соглашением.

В отличие от многих новых языков, SQL имеет большое количество ключевых слов и полагается на способность читателя отличать ключевые слова от идентификаторов , чтобы мысленно проанализировать синтаксис.

Таким образом, прямой ответ на ваш вопрос - это скорее ответ на вопрос: «Почему читатель кода SQL так сильно выигрывает от ключевых слов в верхнем регистре, если это не так для большинства современных языков?»:

  • Полагаться на то, чтобы держать ключевые слова в голове , разумно для многих современных языков, но неразумно для SQL ; в нем слишком много ключевых слов и слишком много вариантов.

  • Полагаться на знаки препинания разумно для большинства современных языков, но неразумно для SQL ; его слишком мало, вместо этого в зависимости от точного порядка ключевых слов для обозначения синтаксиса.

  • Полагаться на автоматические выделители для различения ключевых слов разумно для современных языков в обычных случаях, но игнорирует реальность того, что маркеры могут достичь для SQL . Большинство из них не охватывает все ключевые слова всех вариантов SQL, и, тем не менее, SQL часто и регулярно читается в контекстах, где подсветка не помогает.

Вот некоторые из причин, специфичных для SQL, по которым читателю кода SQL лучше всего подходит стандартизация верхнего регистра для ключевых слов и использование только не верхнего регистра (т.е. нижнего или смешанного) для идентификаторов.

Иногда может помочь выделение. Но только если выделитель знает, что у вас есть SQL; и у нас очень часто есть SQL в контексте, когда редактор / форматировщик не может разумно знать, что имеет дело с SQL. Примеры включают встроенные запросы, документацию для программистов и текстовые строки в коде на другом языке. То же самое не так часто бывает с такими языками, как Python или C ++; да, их код иногда появляется в этих местах, но обычно это не делается так, как с кодом SQL.

Кроме того, читатель обычно использует маркер, который знает только подмножество ключевых слов, которые использует ваша конкретная реализация SQL. Многие из менее распространенных ключевых слов не будут выделены, за исключением того, кто хорошо знает ваш вариант SQL. Таким образом, читателю, даже если он использует маркер, по-прежнему нужен более прямой способ различения ключевых слов в любом умеренно сложном операторе SQL.

Таким образом, читатель будет часто - а писатель не может заранее знать, когда это будет - нуждаться в помощи со стороны содержимого самого оператора SQL, чтобы узнать, что автор задумал как ключевое слово, а что - как идентификатор. Таким образом, сам контент SQL должен различать ключевые слова для читателя , и использование ключевых слов в верхнем регистре является обычным и полезным способом сделать это.

большой нос
источник
Я считаю, что причина этого вопроса довольно хорошая. Ваш ответ хорошо объяснен, но все же выглядит немного основанным на мнении. Мне не нравится, что в SQL так много ключевых слов. В любом случае, после 50 наиболее часто используемых ключевых слов, как часто вы видите другие? Имеет ли значение показывать им прописные буквы? Поскольку они случаются нечасто, они все равно привлекают внимание, не так ли? Конечно, эти проклятые «незарезервированные ключевые слова», такие как sql-server, throwзаслуживают особого отношения, но прописные буквы - это просто вариант между многими.
Frédéric
1
@ Frédéric, вы, кажется, утверждаете, что читателю не нужно помечать менее известные ключевые слова как ключевые. Нет, такие слова не привлекают внимания именно потому, что нельзя ожидать, что читатель узнает, что это ключевые слова; поэтому их нужно выделять как ключевые слова, как и любые другие.
бигнозный
Может быть, я просто слишком не разбираюсь в SQL, хотя я много лет программировал с SQL, но до сих пор я считаю, что всегда почти сразу обнаруживал ключевые слова, которых я не знал, потому что они приводили к необычной конструкции SQL, по крайней мере для тех, кто знай их.
Фредерик
33

Примеры Гордона Белла не совсем верны; как правило, выделяются только ключевые слова, а не весь запрос. Его второй пример будет выглядеть так:

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
davidtbernal
источник
1
Да, мне это тоже нравится.
David The Man
6
Проблема в том, что ... Если вы используете заглавные буквы при запуске специальных команд в командной строке, вы всегда будете в два раза медленнее, чем тот, кто не использует их, если вам когда-либо придется запускать специальные команды в производственной среде, когда имеет значение. Поэтому я пишу все в нижнем регистре, а затем «украшаю» перед регистрацией, когда кто-то жалуется, что не может прочитать его, потому что не знает, как запустить средство выделения синтаксиса. И я не знаю, как вы, но три раза в год, когда мне приходится запускать специальные команды на производственной скорости, действительно имеет значение, поэтому 50% рабочих дней, которые я практиковал в написании тестовых запросов во всех нижних регистрах, действительно окупаются.
7
И в базе данных моей компании (созданной где-то в 90-х) все имена таблиц, столбцы, индексы, хранимые процедуры и т. Д. Написаны с заглавной буквы, поэтому мы используем ключевые слова SQL в нижнем регистре. ;)
Андреас
1
Ничего себе 1/2 быстрее. Я так не думаю!
Ихароб Аль-Асими
33

Было время, когда у большинства людей не было возможности кодировать что-либо, кроме прописных букв, потому что соответствующее кодирование (ASCII) еще не было изобретено. БЫЛО ДОСТУПНО ТОЛЬКО ШЕСТЬ БИТ . В то время как SQL появляется все больше и больше, НИЖНИЕ БУКВЫ ЕЩЕ НЕ РАСПРОСТРАНЯЛИСЬ ПРИ ПРОГРАММИРОВАНИИ.

ОБРАТИТЕ ВНИМАНИЕ, ЧТО НЕКОТОРЫЕ ЛЮДИ УТВЕРЖДАЮТ, ЧТО БАЗА ДАННЫХ ПОЛУЧИТ СРОЧНОСТЬ И УПРАВЛЯЕТ ВАШИ ЗАПРОСЫ БЫСТРЕЕ.

Лукас Эдер
источник
Значит, сегодня это плохая причина.
bignose 02
1
@BIGNOSE: НЕТ, АБСОЛЮТНО НЕТ!
Лукас Эдер,
1
Думаю, это лучший ответ. К сожалению, я просто ненавижу строчные буквы в ключевых словах SQL и не могу найти способ полюбить строчные буквы. Я сумасшедший?
Ихароб Аль-Асими
@IharobAlAsimi ДА, ТЫ С ума сошел. ПОЧЕМУ ВЫ ПИШИТЕ АНГЛИЙСКИЙ В НИЖНЕМ РЕГИСТРЕ, НО МОНТАЖ НА АНГЛИЙСКОМ СТРУКТУРЕ?
Лукас Эдер
24

Менее 10% букв в читаемом тексте написаны заглавными буквами. Следовательно, наш мозг более склонен распознавать строчные буквы, чем прописные. Исследования показали, что чтение прописных букв занимает больше времени. Вот только один пример:

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

Приведенный выше пример, я думаю, подчеркивает, что даже когда вы говорите об одном или двух словах, это имеет значение.

AaronLS
источник
5
Мы не говорим о чтении романа, написанного заглавными буквами; мы говорим о нескольких ключевых словах, которые являются лишь частью текста.
Кейси
6
Вы упускаете суть. Дело не в том, сколько слов мы читаем, а в том, что наш мозг обучен делать быстро. Дорожный знак, например, конечно, не роман, но они пришли к такому же выводу. Когда мы учимся читать, мы начинаем читать каждую букву, но в конечном итоге наш мозг начинает распознавать слово как группу шаблонов. Лучше, если эти шаблоны будут последовательными. Помните, что прописные буквы часто отличаются от строчных букв, а не только их увеличенная версия.
AaronLS
1
Но ключевых слов очень мало, и они появляются снова и снова; поэтому распознавание должно быть одинаково быстрым для всех, кто использовал SQL в течение любого времени.
Кейси
3
Правда, точно не что-то тяжелое и быстрое. Но есть всего несколько очень распространенных ключевых слов. Есть большой набор, которого нет, и часто люди расширяют эту практику использования верхнего регистра до вещей, которые являются встроенными функциями, но не обязательно ключевыми словами синтаксического языка. На практике я все еще использую небольшую горстку ключевых слов, таких как SELECT / WHERE / GROUP BY, которые указывают на начало основного раздела запроса. Но все другие ключевые слова, такие как встроенные функции , такие как cast, rankя прописные.
AaronLS
19

Это потому, что SQL - такой старый язык ( 1974 г. ), что когда он был задуман, на большинстве клавиатур не было строчных букв! Документация по языку просто отражала технологии того времени.

Исследования доказали, что ВСЕ ЗАГЛАВНЫЕ буквы сложнее читать, настолько, что Федеральное управление автомобильных дорог США обязало использовать знаки с разным регистром в своем Руководстве по унифицированным устройствам управления движением, в котором говорится:

Буквы названий населенных пунктов, улиц и шоссе на обычных дорожных указателях должны быть сочетанием строчных букв с начальными прописными буквами.

The New York Post также опубликовала:

Исследования показали, что труднее читать знаки, написанные заглавными буквами, а дополнительные миллисекунды, проведенные вдали от дороги, увеличивают вероятность несчастных случаев, особенно среди водителей старшего возраста.

Нет веских причин использовать прописные буквы, и нет веских причин не использовать.

Я лично не люблю использовать заглавные буквы для ключевых слов SQL. Мне труднее читать и читать абсурд в наши дни.

В языке SQL регистр не учитывается. Убери палец с этой клавиши переключения передач!

Богемный
источник
3
Я думаю, что преобладание веских причин, представленных в других ответах, говорит против вашего утверждения «нет веских причин использовать прописные буквы».
bignose
7
@bignose О, есть причины ... Я просто не думаю, что они хорошие. По моему опыту, чем младше программист SQL, тем больше вероятность, что он будет использовать прописные буквы. И наоборот, я никогда не встречал грамотного кодировщика SQL, использующего прописные буквы.
Bohemian
3
Абсолютно согласен. Преобладание других «ответов» не делает их правильными, а лишь делает их преобладающими. ВСЕ ВЕРХНИЙ КОРПУС ЯВЛЯЕТСЯ ПЕРЕХОДОМ ОТ КОГДА КОМПЬЮТЕРЫ НЕ ИМЕЛИ ЧЕХЛА НА СВОИХ КЛАВИАТУРАХ ИЛИ В ИХ ПРЕДСТАВЛЕНИЯХ ХАРАКТЕРА. СЕГОДНЯ ЭТО ПРОСТО ГЛУПОЙ.
Чарльз Бретана
Да, и изношенная клавиша CAPS LOCK или судорога в пальцах, удерживая клавиши Shift без необходимости.
Гордон Белл
9
Я чувствую здесь циркулярную аргументацию. Если причина представлена в пользу различения ключевых слов с делом, чем уволить его как не хорошая причина. Если причина представлена ​​кодировщиком SQL, но не согласна с вашей позицией, вы отклоняете его как некомпетентного кодировщика SQL. Я думаю, что на этом основании мы можем отклонить этот аргумент как недействительный.
bignose
8

Верхний регистр может улучшить видимость ключевых слов, но вы можете компенсировать это за счет выделения кода и отступов.
Мы используем нижний регистр, потому что редактор запросов и другие инструменты творит чудеса при редактировании кода t-sql, и мы не видим необходимости мучить мизинец.

Овидиу Пакурар
источник
2
Редактор запросов и t-sql - единственные места, где кто-нибудь будет читать ваш код SQL? Откуда вы знаете?
bignose
8

Обезьяна видит, обезьяна делает для меня. Сопоставление с образцом - если я сделаю это так, как я видел, структура предложений выстроится мысленно легче.

dkretz
источник
7

Заглавные буквы менее читабельны. Очертания всех слов имеют форму прямоугольников; нет ни спусковых, ни восходящих. Строчная FTW!

Лэнс Фишер
источник
3
Причина, по которой вы указываете, поддерживает позицию, что верхний регистр помогает отличить ключевые слова от остальных.
bignose
5
@bignose Если SQL читается как человеческий язык, зачем нам прописные буквы? Нам не нужно ЗАГЛАВАТЬ наши глаголы ИЛИ предлоги В человеческом языке. Представьте, ЕСЛИ КАЖДОЕ предложение выглядело ТАКОЕ это. Я считаю это менее читаемым, чем обычное письмо. Слова в верхнем регистре в этих двух предложениях заставляют мой мозг останавливаться и произносить их медленнее, чем остальная часть предложения, замедляя мое чтение и делая поток менее естественным.
Крис Миддлтон
1
Человеческий язык очень прощает двусмысленность синтаксиса. Компьютерных языков нет, поэтому эту двусмысленность нужно минимизировать. Синтаксис SQL здесь не помогает, поэтому нам, людям, нужно использовать доступные инструменты; В синтаксисе SQL не так уж много, поэтому мы разработали соглашение об использовании ключевых слов с заглавной буквы.
bignose
5

Я считаю его более читаемым. То же самое с новой строкой в ​​начале каждого предложения и отступом между предложениями.

Марк Бостлман
источник
2

Попробуйте продукт для форматирования (я использую SQL Prompt / SQL Refactor от Red Gate). Вы можете установить, как вы хотите использовать заглавные буквы, и ваш код всегда будет одинаково отформатирован. Дайте отдых вашему мизинцу и позвольте компьютеру делать всю работу за вас.

gfrizzle
источник
1
Этот совет игнорирует многие контексты, в которых читается SQL. Совершенно непрактично читать код, уже написанный кем-то другим; если такой инструмент нужен только для того, чтобы сделать плохо отформатированный SQL-код читаемым, это аргумент в пользу соглашения, подобного тому, о котором идет речь в этом вопросе.
bignose
но этот подход хорош, если вам нужны стандарты во всей организации. Если вам нужны стандарты, мнение не имеет значения
Trubs
2

Одна из причин для продолжения использования заглавных букв - когда вы (или кто-то другой) просматриваете код в чем-то вроде блокнота, это упрощает чтение. т.е. вы можете легко отличить «ключевые слова» от имен таблиц, SP, udf и т. д.

CPU_BUSY
источник
1

За исключением соответствия ради соответствия, нет. Хотя это очень субъективная тема, я предпочитаю использовать смешанный регистр для всего SQL. SQL намного легче читать, и ничего не потеряно в современных IDE, где все ключевые слова в любом случае имеют цветовую кодировку.

Чарльз Бретана
источник
Поскольку во многих других ответах здесь представлены причины, я не думаю, что ваш ответ правильный: есть причины, «помимо соответствия ради соответствия».
bignose
... тогда какие они? Хотя всегда открыт для новой информации, честно говоря, я никогда о ней не знал.
Чарльз Бретана
Я уже привел много причин , так что теперь вы знаете.
bignose
2
Ни одна из этих причин не является уважительной, это личные предпочтения. Не стесняйтесь поступать так, как диктуют ваши личные предпочтения, но не характеризуйте предпочтения как правило или передовую практику.
Чарльз Бретана
1

Функция intellisense / автозаполнение в Microsoft SQL Server Management Studio позволяет использовать верхний или нижний регистр для зарезервированных слов, но вызывает функции верхнего регистра, такие как MAX (), SUM ().

Даже в этом случае синтаксический анализатор по-прежнему позволяет обрабатывать строчные версии max () и sum ().

Это подразумевает двойственное отношение к природе казни и, следовательно, является просто вопросом личных предпочтений.

Билл
источник
4
Да, и в SSMS «Параметры -> Текстовый редактор -> Transact-SQL -> Intellisense» вы можете установить по умолчанию «Нижний регистр», если хотите.
Гордон Белл
0

Мне не нравится все, что написано заглавными буквами (и еще больше ненавижу вводить заглавные буквы), но я не мог убедить себя пойти против сообщества. Как обычно, Vim и связанные с ним пакеты являются решением многих проблем:

http://www.vim.org/scripts/script.php?script_id=305

Просто введите как обычно, и ключевые слова будут автоматически заглавными по мере ввода. Я не использовал все непонятные заклинания SQL, но меня это еще не подвело.

Фердинанд ван Вик
источник
-2

Я вызываю большую часть своего кода mySQL из PHP, и я делаю все свое редактирование PHP в vim (или, я полагаю, в этом случае, VIM ;-). Теперь я уверен, что есть плагины для выделения кода mySQL в PHP, но я их не нашел, и у меня нет времени на его поиски. Поэтому я предпочитаю, чтобы все было закрыто крышками. Я нахожу это:

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?

PUK
источник
3
Нет, нет, нет, camelCase предназначен для имен переменных, а не для имен столбцов. Используйте правильный регистр для имен столбцов ... InsertDate, AlterDate, ...
Гордон Белл,
1
Стандарт SQL требует, чтобы реализации игнорировали регистр в идентификаторах (он переводит их в верхний регистр). Таким образом, ваш код не должен зависеть от различий в регистрах идентификаторов, и обычный способ сделать это - создать идентификаторы all_lower_case.
bignose
3
@bignose Я не большой поклонник подчеркивания, так как оно уменьшает wpm
puk