Czy istnieje dobry powód, aby używać wielkich liter w słowach kluczowych SQL? [Zamknięte]

Domyślnie wydaje się, że są to wielkie litery, ale czy naprawdę jest jakiś powód, aby używać wielkich liter w słowach kluczowych? Zacząłem używać wielkich liter, ponieważ próbowałem dopasować to, co daje mi SQL Server, za każdym razem, gdy próbowałem coś utworzyć, na przykład nową procedurę składowaną. Ale potem poczułem się okropnie z powodu mojego małego (piątego) palca, który zawsze musi przytrzymywać Shiftprzycisk, więc przestałem używać wielkich liter. Czy jest jakiś powód, dla którego powinienem wracać do wielkich liter?

Edycja : Dzięki za odpowiedzi. Nie programowałem jeszcze w czasach, gdy COBOL był królem, więc nie byłem tego świadomy. Od teraz będę trzymał się małych liter.

To tylko kwestia stylu, prawdopodobnie pochodzącego z czasów, gdy redaktorzy nie kolorowali kodu.

Kiedyś wolałem wszystkie wielkie litery, ale teraz skłaniam się ku mniejszym.

OSOBIŚCIE NIE LUBIĘ, ŻE MÓJ SQL na mnie krzyczy. PRZYPOMINA MI BASIC LUB COBOL.

Dlatego wolę małe litery w języku T-SQL z nazwami obiektów bazy danych MixedCase.

Jest dużo łatwiejszy do odczytania, a literały i komentarze wyróżniają się.

SQL JEST STARY. KRZYCZY GÓRNA LITERA. WYGLĄDA DZIWNIE I MOŻE BYĆ Brzydki.

Chociaż prawdopodobnie jest to prawda, żadna z nich nie dotyczy szczególnych powodów dla języka SQL, dla których słowa kluczowe składające się z dużych liter są dobrą konwencją.

W przeciwieństwie do wielu nowszych języków, SQL ma dużą liczbę słów kluczowych i polega na zdolności czytelnika do odróżnienia słów kluczowych od identyfikatorów w celu mentalnego przeanalizowania składni.

Zatem bezpośrednia odpowiedź na twoje pytanie jest bardziej odpowiedzią na pytanie „dlaczego czytelnik kodu SQL korzysta tak bardzo ze słów kluczowych pisanych wielkimi literami, skoro nie jest to tak prawdziwe w przypadku większości współczesnych języków?”:

• Poleganie na zachowaniu słów kluczowych w głowie jest rozsądne w przypadku wielu współczesnych języków, ale nierozsądne w przypadku SQL ; zawiera zbyt wiele słów kluczowych i zbyt wiele wariantów.

• Poleganie na znakach interpunkcyjnych jest rozsądne w przypadku większości współczesnych języków, ale nierozsądne w przypadku języka SQL ; ma ich za mało, zamiast tego zależy od dokładnej kolejności słów kluczowych, aby wskazać składnię.

• Poleganie na automatycznych podświetlaczach do rozróżniania słów kluczowych jest rozsądne we współczesnych językach w zwykłych przypadkach, ale ignoruje rzeczywistość tego, co podświetlacze mogą osiągnąć w SQL . Większość z nich nie obejmuje wszystkich słów kluczowych ze wszystkich wariantów SQL, a mimo to SQL jest często i rutynowo czytany w kontekstach, w których zakreślacz nie pomoże.

Oto niektóre z powodów, specyficznych dla języka SQL, dla których czytelnik kodu SQL najlepiej jest obsłużyć poprzez ujednolicenie słów kluczowych na duże litery i używanie tylko wielkich liter (tj. Małych lub mieszanych) dla identyfikatorów.

Podświetlanie może czasami pomóc. Ale tylko wtedy, gdy zakreślacz wie, że masz SQL; i bardzo często mamy SQL w kontekście, w którym edytor / program formatujący nie może wiedzieć, że ma do czynienia z SQL. Przykłady obejmują zapytania w wierszu, dokumentację programisty i ciągi tekstowe w kodzie innego języka. To samo nie dotyczy języków takich jak Python czy C ++; tak, ich kod czasami pojawia się w tych miejscach, ale nie jest to rutynowo wykonywane tak, jak w przypadku kodu SQL.

Ponadto czytelnik będzie często używał zakreślacza, który zna tylko podzbiór słów kluczowych używanych w konkretnej implementacji SQL. Wiele mniej popularnych słów kluczowych nie zostanie wyróżnionych, z wyjątkiem takiego, który dokładnie zna Twój wariant SQL. Tak więc czytelnik, nawet jeśli używa zakreślacza, nadal potrzebuje bardziej bezpośredniego sposobu rozróżniania słów kluczowych w każdej średnio złożonej instrukcji SQL.

W związku z tym czytelnik często - a autor nie może wiedzieć z wyprzedzeniem, kiedy to nastąpi - będzie potrzebował pomocy z treści samej instrukcji SQL, aby wiedzieć, co jest zamierzone przez autora jako słowo kluczowe, a co ma służyć jako identyfikator. Tak więc sama treść SQL musi rozróżniać słowa kluczowe dla czytelnika , a użycie słów kluczowych pisanych wielkimi literami jest konwencjonalnym i użytecznym sposobem na zrobienie tego.

Przykłady Gordona Bella nie są dokładnie poprawne; ogólnie podświetlane są tylko słowa kluczowe, a nie całe zapytanie. Jego drugi przykład wyglądałby tak:

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

Jest to o wiele łatwiejsze do odczytania, ponieważ słowa kluczowe bardziej się wyróżniają. Nawet przy podświetlaniu składni uważam, że przykład bez wielkiej litery jest znacznie trudniejszy do odczytania.

W mojej firmie posuwamy się nieco dalej w zakresie naszego formatowania 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

BYŁ CZAS, W KTÓRYM WIĘKSZOŚĆ LUDZI NIE MIAŁ MOŻLIWOŚCI KODOWANIA CZEGOKOLWIEK WIĘKSZYMI LITERAMI, PONIEWAŻ NIE WYKONANO JESZCZE ODPOWIEDNIE KODOWANIE (ASCII). DOSTĘPNYCH BYŁO TYLKO SZEŚĆ BITÓW . JEŚLI SQL JESZCZE JESZCZE JESZCZE NIE BYŁA POCZĄTKOWĄ PRAKTYKĄ W PROGRAMOWANIU, WIELKIE LITERY NIE BYŁY.

NALEŻY PAMIĘTAĆ, ŻE NIEKTÓRE LUDZIE TWIERDZĄ, ŻE BAZA DANYCH BĘDZIE POCZUĆ PILNOŚĆ I SZYBCIEJ WYDAJE TWOJE PYTANIA.

Mniej niż 10% liter w czytanym tekście to duże litery. Stąd nasze mózgi chętniej rozpoznają małe litery niż duże. Badania wykazały, że czytanie tekstu pisanego wielkimi literami zajmuje więcej czasu. Oto tylko jeden przykład:

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

Myślę, że powyższy przykład podkreśla, że ​​nawet gdy mówisz o jednym lub dwóch słowach, robi to różnicę.

To dlatego, że SQL jest tak starym językiem ( 1974 ), że kiedy został wymyślony, większość klawiatur nie miała małych liter! Dokumentacja językowa po prostu odzwierciedlała technologię tamtych czasów.

Badania dowiodły, że WIELKIE LITERY są trudniejsze do odczytania, do tego stopnia, że ​​Federalna Administracja Autostrad USA nakazała stosowanie znaków o różnej wielkości w swoim podręczniku dotyczącym jednolitych urządzeń kontroli ruchu, który stanowi:

Litery nazw miejsc, ulic i autostrad na konwencjonalnych drogowskazach drogowych powinny być kombinacją małych liter z początkowymi dużymi literami.

New York Post opublikował również:

Badania wykazały, że trudniej jest odczytać napisy z wielkimi literami, a dodatkowe milisekundy spędzone na gapieniu się z dala od drogi zwiększają prawdopodobieństwo wypadków, szczególnie wśród starszych kierowców.

Nie ma dobrego powodu, aby używać wielkich liter i są dobre powody, aby tego nie robić.

Osobiście nie cierpię używania wielkich liter w słowach kluczowych SQL. W dzisiejszych czasach jest mi trudniej czytać i absurdalnie.

Język SQL jest definiowany jako niewrażliwy na wielkość liter. Zdejmij palec z klawisza Shift!

Wielkie litery mogą zapewnić poprawę widoczności słów kluczowych, ale można to skompensować podświetleniem kodu i wcięciami.
Używamy małych liter, ponieważ edytor zapytań i inne narzędzia robią cuda podczas edycji kodu t-sql i nie widzimy potrzeby torturowania małego palca.

Małpa widzisz, małpa robi dla mnie. Dopasowywanie wzorców - jeśli zrobię to tak, jak widziałem, struktura klauzul układa się mentalnie łatwiej.

Wielkie litery są mniej czytelne. Kontury wszystkich słów mają kształt pudełek; nie ma zstępujących ani wznoszących się. Małe litery FTW!

Uważam, że jest bardziej czytelny. To samo dotyczy nowej linii na początku każdej klauzuli i wcięć między klauzulami.

Wypróbuj produkt do formatowania (używam SQL Prompt / SQL Refactor z Red Gate). Możesz ustawić, jak chcesz, aby wielkie litery działały, a Twój kod zawsze będzie konsekwentnie sformatowany. Odpocznij i pozwól komputerowi wykonać pracę za Ciebie.

Jednym z powodów, dla których nadal używasz wielkich liter, jest to, że gdy Ty (lub ktoś inny) przeglądasz kod w czymś takim jak notatnik, ułatwia to czytanie. tzn. można łatwo odróżnić "słowa kluczowe" od nazw tabel, SP, UDF itp

Inne niż zgodność ze względu na zgodność, nie. Chociaż jest to bardzo subiektywny temat, wolę używać mieszanych wielkości liter dla wszystkich SQL. SQL jest znacznie łatwiejszy do odczytania i nic nie jest stracone w nowoczesnych IDE, w których słowa kluczowe i tak są kodowane kolorami.

Funkcja Intellisense / autouzupełnianie w programie Microsoft SQL Server Management Studio umożliwia stosowanie wielkich lub małych liter w słowach zastrzeżonych, ale wywołania funkcji z wielkich liter, takie jak MAX (), SUM ().

Mimo to parser nadal umożliwia przetwarzanie małych liter max () i sum ().

Oznacza to ambiwalencję w odniesieniu do charakteru egzekucji, a zatem jest to po prostu kwestia osobistych preferencji.

Nie podoba mi się wszystko, co jest napisane wielkimi literami (i jeszcze bardziej nienawidzę ich wpisywać), ale nie mogłem się przekonać, żebym wystąpił przeciwko społeczności. Jak zwykle Vim i powiązane z nim pakiety są rozwiązaniem wielu problemów:

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

Po prostu wpisz jak zwykle, a słowa kluczowe będą automatycznie włączane do wielkich liter podczas wpisywania. Nie użyłem wszystkich niejasnych zaklęć SQL, ale jeszcze mnie to nie zawiodło.

Większość kodu MySQL wywołuję z poziomu PHP, a całą edycję PHP wykonuję w vimie (lub w tym przypadku w VIM ;-). Teraz jestem pewien, że istnieją wtyczki do podświetlania kodu mySQL w PHP, ale nie znalazłem go i nie mam czasu, aby go szukać. Dlatego wolę mieć wszystko na allcapsach. Znajduję to:

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 );

Pomaga mi znacznie lepiej odróżnić PHP od 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 );

Poza tym z jakiegoś powodu nienawidzę mieszać nasadek z wielbłądem, jak na przykład:

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

To IDmnie irytuje. Czy zamiast tego powinno być id? czy iD?