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

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

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

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

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

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

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

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

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

Возможно, это правда, но ни один из них не обращается к причинам, специфическим для языка 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 г. ), что когда он был задуман, на большинстве клавиатур не было строчных букв! Документация по языку просто отражала технологии того времени.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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