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

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

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

ОТВЕТЫ

Ответ 1

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

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

Ответ 2

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

Итак, я предпочитаю свой строчный регистр T-SQL с именами объектов базы данных MixedCase.

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

Ответ 3

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

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

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

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

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

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

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

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

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

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

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

Ответ 4

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

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

Ответ 5

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

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

Ответ 6

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

Нет веских оснований для использования заглавных букв. Я лично ненавижу использование заглавных букв SQL. Это труднее читать и смешно в этот день и в возрасте и ненужно; язык SQL определяется как нечувствительный к регистру.

Ответ 7

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

Ответ 8

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

Ответ 9

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

Ответ 10

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

Ответ 11

ВРЕМЯ БЫЛО ВРЕМЯ, КОГДА БОЛЬШИЕ ЛЮДИ НЕ ИМЕЛИ ВОЗМОЖНОСТИ ПРИНЯТИЯ НИЧЕГО НЕЗАВИСИМОГО ВЕРХНЕГО БИЗНЕСА, ПОТОМУ ЧТО СООТВЕТСТВУЮЩИЙ ЭНЦИКЛ (ASCII) НЕ ДОЛЖЕН ВХОДИТЬ. ДОСТУПНЫ ТОЛЬКО ШЕСТЫЕ БИТЫ. WHILE SQL - БОЛЬШЕ ПОСЛЕДНИЕ, НИЖНИЕ СЛУЧАИ БУКВЫ НЕ ОБЩАЯ ПРАКТИКА В ПРОГРАММИРОВАНИИ.

Ответ 12

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

Ответ 13

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

Ответ 14

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

Ответ 15

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

Тем не менее, парсер по-прежнему разрешает обрабатывать версии с малым() и sum() в нижнем регистре.

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

Ответ 16

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

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

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

Ответ 17

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

Кроме того, по какой-то причине я ненавижу смешивать allcaps с верблюжьим футляром, например:

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?