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

Question

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

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

Answer 1

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

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

Answer 2

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

Answer 3

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

Answer 4

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

Answer 5

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

Answer 6

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

Answer 7

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

Answer 8

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

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

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

Answer 9

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

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 

Answer 10

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

Answer 11

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

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

Answer 12

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

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

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

Answer 13

Я вызываю большую часть своего 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?

Answer 14

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

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

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

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

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

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

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

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

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

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

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

Answer 15

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

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

Answer 16

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

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

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

Answer 17

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