Чи є вагомі причини використовувати верхній регістр для ключових слів 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 набагато простіше читати, і нічого не втрачається в сучасних ІДЕ, де ключові слова все одно кольорові.

Інтеліссанс / автодоповнення в студії управління Microsoft SQL Server дозволяє у верхньому або нижньому регістрі для зарезервованих слів, але верхні регістри функціонують як виклики MAX (), SUM ().

Незважаючи на це, парсер все ще дозволяє обробляти малі версії max () та sum ().

Це передбачає неоднозначність щодо характеру страти, а тому є просто питанням особистих уподобань.

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

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

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

Я називаю більшу частину свого 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 );

Також я чомусь ненавиджу змішувати чашки з верблюдами, як-от так:

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?