Есть ли веская причина использовать заглавные буквы для ключевых слов SQL?
По умолчанию используется верхний регистр, но действительно ли есть причина использовать верхний регистр для ключевых слов? Я начал использовать верхний регистр, потому что просто пытался сопоставить то, что SQL Server дает мне всякий раз, когда я пытался создать что-то, например новую хранимую процедуру. Но потом я почувствовал себя ужасно из-за моего детского (5-го) пальца, который всегда должен удерживать кнопку Shift, поэтому я перестал использовать верхний регистр. Есть ли причина, по которой я должен вернуться к верхнему регистру?
Редактировать: Спасибо за ответы, ребята. Я еще не программировал в те дни, когда КОБОЛ был королем, поэтому я не знал об этом. С этого момента я буду придерживаться строчных букв.
Мне все равно нужно включить CAPS LOCK, когда я хочу писать ключевые слова, а затем выключить, когда я не пишу ключевые слова, и снова включить CAPS LOCK и так далее, и так далее. Это просто хлопот.
CAPS, что ... О, вы имеете в виду мою третью клавишу Ctrl?
IIRC, самое забавное, что если вы проверите процедуры sp_ в MSSQL, они все в нижнем регистре.
@Benjol, не все из них, но определенно многие из них, такие как sp_who. Хорошая идея хотя бы попытаться быть последовательным в sproc такой же, чего Microsoft не во многих «случаях». Каламбур, предназначенный. ржу не могу
Такие языки, как COBOL или SQL, содержат много ключевых слов, они более текстовые, чем другие языки программирования. Вот почему я предпочитаю писать символы верхнего регистра при использовании ключевых слов, чтобы отличать их от обычных слов (например, имен базы данных, таблиц или полей). На мой взгляд, SELECT someCol, anotherCol FROM someTable WHERE name = 'kathy' ORDER BY name ASC гораздо читабельнее, чем select someCol, anotherCol from someTable where id = 'kathy' order by id asc. Большинство современных языков программирования минимизируют количество ключевых слов и не обязательно содержат ключевое слово для каждой операции, которую вы можете вообразить.
SQL берет свое начало с древних времен, когда люди писали кобол и фортран в верхнем регистре. Стандарт ISO SQL-92 даже определил поддержку ключевых слов в нижнем регистре как необязательную.
В MS SQL Server и PostgreSQL, если вы используете имена столбцов в верхнем регистре, вы должны адресовать их в своем коде двойными кавычками (в PostgreSQL) и скобками (в SQL Server), поэтому я предпочитаю использовать все underlined lowercase, чтобы избавиться от скобок и двойные кавычки.
Ответы 17
Это просто вопрос стиля, вероятно, возникший в те времена, когда редакторы не раскрашивали код.
Раньше я предпочитал верхний регистр, но теперь я склоняюсь ко всему нижнему.
+1 Думаю, я был не единственным, кто использовал все нижние строки для ключевых слов.
Я бы предположил, что это восходит к тем временам, когда редакторы не раскрашивали код.
Я почти уверен, что это восходит к тем временам, когда многие машины не поддерживали строчные символы.
Я предполагаю, что это восходит к временам до появления цветных мониторов;)
Верхний регистр может улучшить видимость ключевых слов, но вы можете компенсировать это за счет выделения кода и отступов. Мы используем нижний регистр, потому что редактор запросов и другие инструменты творит чудеса при редактировании кода t-sql, и мы не видим необходимости мучить мизинец.
Является ли редактор запросов и t-sql единственными местами, где кто-нибудь будет читать ваш код SQL? Откуда вы знаете?
Обезьяна видит, обезьяна делает для меня. Сопоставление с образцом - если я делаю это так, как я видел, структура предложений выстраивается мысленно легче.
Я считаю это более читаемым. То же самое с новой строкой в начале каждого предложения и отступом между предложениями.
Попробуйте продукт для форматирования (я использую SQL Prompt / SQL Refactor от Red Gate). Вы можете установить, как вы хотите использовать заглавные буквы, и ваш код всегда будет иметь единообразный формат. Дайте отдых вашему мизинцу и позвольте компьютеру делать всю работу за вас.
Этот совет игнорирует многие контексты, в которых читается SQL. Совершенно непрактично читать код, уже написанный кем-то другим; если подобный инструмент нужен только для того, чтобы сделать плохо отформатированный SQL-код читаемым, это аргумент в пользу соглашения, подобного тому, о котором идет речь в этом вопросе.
но этот подход хорош, если вам нужны стандарты во всей организации. Если вам нужны стандарты, мнение не имеет значения
За исключением соответствия ради соответствия, нет. Хотя это очень субъективная тема, я предпочитаю использовать смешанный регистр для всего SQL. SQL намного легче читать, и ничего не потеряно в современных IDE, где все ключевые слова в любом случае имеют цветовую кодировку.
Поскольку во многих других ответах здесь представлены причины, я не думаю, что ваш ответ правильный: есть причины являются «кроме соответствия ради соответствия».
... тогда какие они? Хотя всегда открыт для новой информации, честно говоря, я никогда о ней не знал.
Я уже дал много причин, так что теперь вы в курсе.
Ни одна из этих причин не является уважительной, это личные предпочтения. Не стесняйтесь поступать так, как диктуют ваши личные предпочтения, но не характеризуйте предпочтения как правило или передовую практику.
Одна из причин для продолжения использования заглавных букв заключается в том, что когда вы (или кто-то другой) просматриваете код в чем-то вроде блокнота, это упрощает чтение. то есть вы можете легко различать "ключевые слова" и названия таблиц, SP, udf и т. д.
ЛИЧНО МНЕ НЕ НРАВИТСЯ, ЧТО МОЙ SQL КРИЧИТ НА МЕНЯ. ЭТО НАПОМИНАЕТ МЕНЯ ОБ ОСНОВНОМ ИЛИ КОБОЛЕ.
Поэтому я предпочитаю строчные буквы T-SQL с именами объектов базы данных MixedCase.
Его гораздо легче читать, а литералы и комментарии выделяются.
Это так вопрос вкуса. По моему опыту, количество криков не слишком велико - я предпочитаю ключевые слова в верхнем регистре, потому что их намного легче читать, а литералы и комментарии выделяются.
+1 за "Я НЕ НРАВИТСЯ, ЧТО МОЙ 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
Да, мне это тоже нравится.
Проблема в том, что ... Если вы используете прописные буквы при запуске специальных команд в командной строке, вы всегда будете вдвое медленнее, чем тот, кто не использует их, если вам когда-либо придется запускать специальные команды в производственной среде, когда имеет значение. Поэтому я пишу все это в нижнем регистре, а затем «украшаю» перед регистрацией, когда кто-то жалуется, что не может его прочитать, потому что не знает, как запустить средство выделения синтаксиса. И я не знаю, как вы, но 3 раза в год, когда мне приходится запускать специальные команды на производственной скорости, действительно имеет значение, поэтому 50% рабочих дней, которые я практиковал в написании тестовых запросов во всех нижних регистрах, действительно окупаются.
А в базе данных моей компании (созданной где-то в 90-х) все имена таблиц, столбцы, индексы, хранимые процедуры и т. д. Написаны с заглавной буквы, поэтому мы используем ключевые слова SQL в нижнем регистре. ;)
Ничего себе 1/2 быстрее. Я так не думаю!
Заглавные буквы менее читабельны. Контур всех слов имеет форму прямоугольников; нет ни спусковых, ни восходящих устройств. Строчная FTW!
Причина, по которой вы указываете, поддерживает позицию, заключающуюся в том, что верхний регистр помогает отличить ключевые слова от остальных.
@bignose Если SQL читается как человеческий язык, зачем нам прописные буквы? Нам не нужно ЗАГЛАВНЫМИ буквами наши глаголы ИЛИ предлоги В человеческом языке. Представьте себе, ЕСЛИ КАЖДОЕ предложение выглядело ТАК КАК это. Я считаю это менее читаемым, чем обычное письмо. Слова в верхнем регистре в этих двух предложениях заставляют мой мозг останавливаться и произносить их медленнее, чем остальная часть предложения, замедляя мое чтение и делая текст менее естественным.
Человеческий язык очень прощает двусмысленность синтаксиса. Компьютерных языков нет, поэтому эту двусмысленность нужно свести к минимуму. Синтаксис SQL здесь не помогает, поэтому нам, людям, нужно использовать доступные инструменты; В синтаксисе SQL немного, поэтому мы разработали соглашение о написании ключевых слов с заглавной буквы.
В прочитанном тексте менее 10% букв написаны заглавными буквами. Следовательно, наш мозг более склонен распознавать строчные буквы, чем прописные. Исследования показали, что чтение прописных букв занимает больше времени. Вот только один пример:
http://www.guardian.co.uk/media/mind-your-language/2010/oct/04/new-york-street-signs-capitals
Приведенный выше пример, я думаю, подчеркивает, что даже когда вы говорите всего лишь об одном или двух словах, это имеет значение.
Мы не говорим о чтении романа, написанного заглавными буквами; мы говорим о нескольких ключевых словах, которые являются лишь частью текста.
Вы упускаете суть. Дело не в том, сколько слов мы читаем, а в том, что наш мозг обучен делать быстро. Дорожный знак, например, конечно, не роман, но они пришли к такому же выводу. Когда мы учимся читать, мы начинаем читать каждую букву, но в конце концов наш мозг начинает распознавать слово как группу шаблонов. Лучше, если эти шаблоны будут последовательными. Помните, что прописные буквы часто отличаются от строчных букв, а не только их увеличенная версия.
Но ключевых слов очень мало, и они появляются снова и снова; поэтому распознавание должно быть одинаково быстрым для всех, кто использовал SQL в течение любого времени.
Правда, это точно не что-то тяжелое и быстрое. Но есть всего несколько очень распространенных ключевых слов. Есть большой набор, которого нет, и часто люди расширяют эту практику использования верхнего регистра до вещей, которые являются встроенными функциями, но не обязательно ключевыми словами синтаксического языка. На практике я все еще использую небольшую горстку ключевых слов, таких как SELECT / WHERE / GROUP BY, которые указывают на начало основного раздела запроса. Но все остальные ключевые слова, такие как встроенные функции, такие как cast, rank, я пишу в нижнем регистре.
Функция intellisense / автозаполнение в Microsoft SQL Server Management Studio позволяет использовать верхний или нижний регистр для зарезервированных слов, но вызывает функции верхнего регистра, такие как MAX (), SUM ().
Даже в этом случае синтаксический анализатор по-прежнему позволяет обрабатывать строчные версии max () и sum ().
Это подразумевает двойственное отношение к природе казни и, следовательно, является просто вопросом личных предпочтений.
Да, и в SSMS «Параметры -> Текстовый редактор -> Transact-SQL -> Intellisense» вы можете установить значение по умолчанию «Нижний регистр», если хотите.
Я вызываю большую часть моего кода 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?
Нет, нет, нет, camelCase предназначен для имен переменных, а не столбцов. Используйте правильный регистр для имен столбцов ... InsertDate, AlterDate, ...
Стандарт SQL требует, чтобы реализации игнорировали регистр в идентификаторах (он переводит их в верхний регистр). Таким образом, ваш код не должен зависеть от различий в регистрах идентификаторов, и обычный способ сделать это - сделать идентификаторы all_lower_case.
@bignose Я не большой поклонник подчеркивания, так как оно уменьшает wpm
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, вы, кажется, утверждаете, что читателю не нужны менее известные ключевые слова, чтобы помечать их как ключевые слова. Нет, такие слова не привлекают внимание именно потому что - нельзя ожидать, что читатель узнает, что это ключевые слова; поэтому их нужно выделять как ключевые слова, как и любые другие.
Возможно, я слишком невежественен в отношении SQL, хотя я много лет программировал с SQL, но до сих пор я считаю, что всегда почти сразу обнаруживал ключевые слова, которых я не знал, потому что они приводили к необычной конструкции SQL, по крайней мере для тех, кто знай их.
Это потому, что SQL - настолько старый язык (1974 г.), что когда он был задуман, на большинстве клавиатур не было строчных букв! Документация по языку просто отражала технологии того времени.
Исследования доказали, что ВСЕ ЗАГЛАВНЫЕ буквы сложнее читать, настолько, что Федеральное управление автомобильных дорог США обязало использовать знаки со смешанным регистром в своем Руководстве по унифицированным устройствам управления движением, в котором говорится:
The lettering for names of places, streets, and highways on conventional road guide signs shall be a combination of lowercase letters with initial uppercase letters.
Газета New York Post также опубликовала:
Studies have shown that it is harder to read all-caps signs, and those extra milliseconds spent staring away from the road have been shown to increase the likelihood of accidents, particularly among older drivers.
Нет веских причин использовать прописные буквы, и нет веских причин не делать этого.
Я лично не люблю использовать заглавные буквы для ключевых слов SQL. Мне труднее читать и читать абсурд в наши дни.
Язык SQL определяется как нечувствительный к регистру. Уберите палец с этой клавиши переключения передач!
Я думаю, что преобладание веских причин, представленных в других ответах, говорит против вашего утверждения «нет веских причин использовать прописные буквы».
@bignose О, есть причины ... Я просто не думаю, что они хорошие. По моему опыту, чем младше программист SQL, тем больше вероятность, что он будет использовать прописные буквы. И наоборот, я никогда не встречал грамотного кодировщика SQL, который использовал бы верхний регистр.
Абсолютно согласен. Преобладание других «ответов» не делает их правильными, а просто делает их преобладающими. ВСЕ ВЕРХНИЙ КОРПУС ЯВЛЯЕТСЯ ПЕРЕМЕЩЕНИЕМ ОТ КОГДА КОМПЬЮТЕРЫ НЕ ИМЕЛИ КОРПУСА НА СВОИХ КЛАВИАТУРАХ ИЛИ В ИХ ПРЕДСТАВЛЕНИЯХ ХАРАКТЕРА. СЕГОДНЯ ЭТО ПРОСТО ГЛУПОЙ.
Да, и изношенная клавиша CAPS LOCK или судорога в пальцах, удерживающая клавиши Shift без надобности.
Я чувствую здесь циркулярную аргументацию. Если причина представлена в пользу различения ключевых слов с помощью регистра, вы отклоняете ее как причину хорошо. Если причина представлена кодировщиком SQL, но не согласна с вашей позицией, вы отклоняете их как не кодировщик SQL компетентный. Я думаю, что на этом основании мы можем отклонить этот аргумент как недействительный.
не уверен, что исследования с заглавными буквами можно использовать в качестве отдельного аргумента здесь. чтение знака lc по сравнению со знаком uc - это другая задача, чем попытка понять код. Вы должны взвесить возможное попадание в чистую читаемость слов с подсказкой о синтаксисе, которую вам дают заглавные буквы. Этот аспект отсутствует в задаче «чтение знаков».
@cpt «синтаксическая подсказка» - это субъективно, и это не так (каламбур) для меня: я кодирую весь свой sql в нижнем регистре. Мне труднее читать заглавные ключевые слова, и я нахожу это довольно неприятным. Если я возглавляю команды, использующие SQL, я требую, чтобы весь SQL был строчными, но это не проблема, потому что прошло много лет с тех пор, как я работал со всеми, кто предпочитает или использует прописные буквы.
Я не люблю все, что написано заглавными буквами (и еще больше ненавижу печатать заглавными буквами), но не мог убедить себя пойти против сообщества. Как обычно, Vim и связанные с ним пакеты являются решением многих проблем:
http://www.vim.org/scripts/script.php?script_id=305
Просто введите как обычно, и ключевые слова будут автоматически заглавными по мере ввода. Я не использовал все непонятные заклинания SQL, но меня это еще не подвело.
Было время, когда у большинства людей не было возможности кодировать что-либо, кроме заглавных букв, потому что соответствующее кодирование (ASCII) еще не было изобретено. БЫЛО ДОСТУПНО ТОЛЬКО ШЕСТЬ БИТОВ. В то время как SQL появляется все больше и больше, НИЖНИЕ БУКВЫ ЕЩЕ НЕ РАСПРОСТРАНЯЛИСЬ ПРИ ПРОГРАММИРОВАНИИ.
ОБРАТИТЕ ВНИМАНИЕ, ЧТО ПРЕТЕНЗИЯ НЕКОТОРЫХ ЛЮДЕЙ ЧТО БАЗА ДАННЫХ ПОЛУЧИТ СРОЧНОСТЬ И УПРАВЛЯЕТ ВАШИ ЗАПРОСЫ БЫСТРЕЕ.
Значит, сегодня это плохая причина.
@BIGNOSE: НЕТ, АБСОЛЮТНО НЕТ!
Думаю, это лучший ответ. К сожалению, я просто ненавижу строчные буквы в ключевых словах SQL, и я не могу найти способ полюбить строчные буквы. Я сумасшедший?
@IharobAlAsimi ДА, ТЫ С ума сошел. ПОЧЕМУ ВЫ ПИШИТЕ АНГЛИЙСКИЙ В НИЖНЕМ РЕГИСТРЕ, НО НЕ СТРУКТУРИВАЕТ АНГЛИЙСКИЙ?
Я согласен насчет срочности. Раньше я использовал все строчные буквы, но недавно я перешел на верхний регистр, и теперь мое приложение работает намного быстрее.
Попробуйте нажать клавишу CAPS LOCK. :)