¿Hay una buena razón para usar mayúsculas para las palabras clave de SQL? [cerrado]

128

El valor predeterminado parece estar en mayúsculas, pero ¿hay realmente alguna razón para usar mayúsculas para las palabras clave? Comencé a usar mayúsculas porque solo intentaba hacer coincidir lo que SQL Server me da cada vez que intento crear algo, como un nuevo procedimiento almacenado. Pero luego, me sentí muy mal por mi dedo del bebé (quinto), que siempre necesita mantener presionado el Shiftbotón, así que dejé de usar mayúsculas. ¿Alguna razón por la que debería volver a mayúsculas?

Editar : Gracias por las respuestas chicos. Todavía no estaba programando en los días en que COBOL era el rey, así que no estaba al tanto de esto. Me quedaré con minúsculas de ahora en adelante.

Hertanto Lie
fuente
9
Pruebe la tecla BLOQ MAYÚS. :)
MusiGenesis
77
Todavía tengo que activar BLOQ MAYÚS cuando quiero escribir palabras clave y luego desactivarlo cuando no estoy escribiendo palabras clave y activar BLOQ MAYÚS nuevamente y así sucesivamente. Es solo una molestia.
Hertanto Lie
17
MAYÚSCULAS qué ... ¿Te refieres a mi tercera tecla Ctrl?
Dave Sherohman
2
IIRC, lo curioso es que si revisa los procedimientos sp_ ​​en MSSQL, todos están en minúsculas.
Benjol
1
@Benjol, no todos, pero definitivamente muchos de ellos como sp_who. Es una buena idea al menos intentar ser coherente en el mismo procedimiento, que Microsoft no está en muchos "casos". Juego de palabras, previsto. LOL
Gordon Bell

Respuestas:

107

Es solo una cuestión de estilo, probablemente originada en los días en que los editores no hacían la coloración del código.

Solía ​​preferir todas las mayúsculas, pero ahora me estoy inclinando hacia todas las minúsculas.

Trigo Mitch
fuente
66
+1 Supongo que no fui el único que usó todas las bajas para palabras clave.
dance2die
2
Supongo que se remonta a los días en que los editores no hacían el código de color.
Benjol
10
Estoy bastante seguro de que se remonta a los días en que muchas máquinas no admitían caracteres en minúsculas.
Nate CK
1
Supongo que se remonta a los días anteriores a los monitores en color;)
walrii
150

PERSONALMENTE, NO ME GUSTA MI SQL GRITANDO EN MÍ. Me recuerda BÁSICO O COBOL.

Así que prefiero mi minúscula T-SQL con nombres de objetos de base de datos MixedCase.

Es mucho más fácil de leer y destacan los literales y los comentarios.

Gordon Bell
fuente
8
Es tanto una cuestión de gustos. En mi experiencia, la cantidad de gritos no es demasiado grande: prefiero las palabras clave en mayúsculas porque es mucho más fácil de leer y destacan los literales y los comentarios.
Jonathan Leffler
93
+1 para "NO ME GUSTA MI SQL
Gritándome
8
No me gusta ningún lenguaje que me grite, pero eso no lleva a la pregunta de si las mayúsculas son una buena idea en SQL.
bignose
85

SQL ES VIEJO. EL CASO SUPERIOR ESTÁ GRITANDO. Parece extraño y tal vez feo.

Aunque podría decirse que es cierto, ninguno de esos aborda las razones especiales del lenguaje SQL por las cuales las palabras clave en mayúsculas son una buena convención.

A diferencia de muchos lenguajes más nuevos, SQL tiene una gran cantidad de palabras clave y se basa en la capacidad del lector para distinguir las palabras clave de los identificadores para analizar mentalmente la sintaxis.

La respuesta directa a su pregunta, entonces, es más una respuesta a "¿por qué el lector de código SQL se beneficia tanto de las palabras clave mayúsculas, cuando eso no es tan cierto para la mayoría de los lenguajes modernos?":

  • Confiar en mantener las palabras clave en la cabeza es razonable para muchos lenguajes modernos, pero no es razonable para SQL ; tiene demasiadas palabras clave y demasiadas variantes.

  • Confiar en las señales de puntuación es razonable para la mayoría de los lenguajes modernos, pero no es razonable para SQL ; tiene muy pocos, en cambio depende del orden preciso de las palabras clave para indicar la sintaxis.

  • Confiar en los marcadores automáticos para distinguir palabras clave es razonable para los idiomas modernos en los casos habituales, pero ignora la realidad de lo que los marcadores pueden lograr para SQL . La mayoría no cubre todas las palabras clave de todas las variantes de SQL, e independientemente, SQL se lee con frecuencia y de forma rutinaria en contextos en los que un resaltador no ayudará.

Estas son algunas de las razones, específicas de SQL, de que el lector de código SQL se sirve mejor estandarizando en mayúsculas para las palabras clave , y solo usando mayúsculas y minúsculas para identificadores.

Destacar a veces puede ayudar. Pero solo si el resaltador sabe que tienes SQL; y muy a menudo tenemos SQL en un contexto donde el editor / formateador no puede saber razonablemente que se trata de SQL. Los ejemplos incluyen consultas en línea, documentación del programador y cadenas de texto dentro del código de otro idioma. Lo mismo no es cierto con tanta frecuencia para lenguajes como Python o C ++; Sí, su código a veces aparece en esos lugares, pero no se hace de la forma habitual con el código SQL.

Además, el lector comúnmente usará un resaltador que solo conoce un subconjunto de las palabras clave que usa su implementación SQL específica. Muchas de las palabras clave menos comunes no se resaltarán, excepto por una que conozca íntimamente su variante SQL. Entonces, el lector, incluso si está usando un marcador, todavía necesita una forma más directa de distinguir las palabras clave en cualquier declaración SQL moderadamente compleja.

Por lo tanto, el lector con frecuencia, y el escritor no puede saber de antemano cuándo será, necesitará ayuda del contenido de la declaración SQL en sí, para saber qué pretende el escritor como una palabra clave y qué se pretende como un identificador. Por lo tanto, el contenido SQL en sí mismo necesita distinguir las palabras clave para el lector , y el uso de palabras clave en mayúsculas es la forma convencional y útil de hacerlo.

nariz grande
fuente
Siento que la razón cercana de esta pregunta es bastante buena. Su respuesta está bien explicada, pero aún parece un poco basada en la opinión. No siento que SQL tenga tantas palabras clave. De todos modos, después de las 50 palabras clave más frecuentes, ¿con qué frecuencia ves otras? ¿Todavía importa mostrarles mayúsculas? Dado que son poco frecuentes, tienden a llamar la atención de todos modos, ¿no es así? Por supuesto, esas malditas 'palabras clave no reservadas' como sql-server throwmerecen un tratamiento especial, pero las mayúsculas son solo una opción entre muchas.
Frédéric
1
@ Frédéric, parece estar argumentando que el lector no necesita palabras clave menos conocidas para ser marcadas como palabras clave. No, tales palabras no llaman la atención precisamente porque no se puede esperar que el lector sepa que son palabras clave; Es por eso que deben distinguirse como palabras clave como cualquier otra.
bignose
Tal vez soy demasiado ignorante acerca de SQL a pesar de mis muchos años de programación con SQL, pero hasta ahora creo que siempre he visto palabras clave casi inmediatamente que no sabía, porque estaban dando como resultado una construcción SQL inusual, al menos para alguien que no conocerlos.
Frédéric
33

Los ejemplos de Gordon Bell no son exactamente correctos; en general, solo se resaltan las palabras clave, no toda la consulta. Su segundo ejemplo se vería así:

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

Esto me parece mucho más fácil de leer, ya que las palabras clave se destacan más. Incluso con el resaltado de sintaxis, encuentro que el ejemplo no capitalizado es mucho más difícil de leer.

En mi empresa, vamos un poco más lejos con nuestro formato 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
davidtbernal
fuente
1
Sí, así es como me gusta también.
David The Man
66
El problema es ... Si capitaliza cuando ejecuta comandos ad-hoc en un indicador, siempre será 1/2 más rápido que alguien que no los capitaliza si alguna vez tiene que ejecutar comandos ad-hoc en producción cuando importa Así que lo escribo todo en minúscula y luego "lo embellezco" antes del check-in cuando alguien se queja de que no puede leerlo porque no sabe cómo ejecutar un resaltador de sintaxis. Y no sé sobre usted, pero las 3 veces al año que tengo que ejecutar comandos ad-hoc en la velocidad de producción realmente importan, por lo que el 50% de los días hábiles que practiqué escribiendo consultas de prueba en minúscula realmente vale la pena.
77
Y en la base de datos de mi empresa (creada en algún lugar en los años 90) todos los nombres de tablas, columnas, índices, procedimientos almacenados, etc. están en mayúsculas, por lo tanto, elegimos palabras clave SQL en minúsculas. ;)
Andreas
1
Wow 1/2 tan rápido. ¡No lo creo!
Iharob Al Asimi
33

Hubo un tiempo en que la mayoría de la gente no tenía la posibilidad de codificar nada más allá de las letras mayúsculas porque la codificación correspondiente (ASCII) NO FUE INVENTADA. SÓLO SEIS BITS DISPONIBLES . MIENTRAS QUE SQL ES MÁS RECIENTE, LAS LETRAS DE CASO INFERIOR NO FUERON PRÁCTICA COMÚN EN LA PROGRAMACIÓN AÚN.

TENGA EN CUENTA QUE ALGUNAS PERSONAS RECLAMAN QUE LA BASE DE DATOS TENDRÁ UN SENTIDO DE URGENCIA Y EJECUTARÁ SUS CONSULTAS MÁS RÁPIDO.

Lukas Eder
fuente
Entonces, no es una buena razón hoy entonces.
bignose
1
@BIGNOSE: ¡NO, ABSOLUTAMENTE NO!
Lukas Eder
1
Creo que esta es la mejor respuesta. Lamentablemente, odio las minúsculas en las palabras clave SQL y no puedo encontrar una manera de gustar las minúsculas, ¿estoy loco?
Iharob Al Asimi
@IharobAlAsimi SÍ, ESTÁS LOCO. ¿POR QUÉ ESCRIBES INGLÉS EN CASO INFERIOR, PERO MOT ESTRUCTURADO EN INGLÉS?
Lukas Eder
24

Menos del 10% de las letras en el texto que leemos son mayúsculas. Por lo tanto, nuestros cerebros están más interesados ​​en reconocer las letras minúsculas que las mayúsculas. Los estudios han demostrado que lleva más tiempo leer el texto en mayúsculas. Aquí hay solo un ejemplo:

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

Creo que el ejemplo anterior enfatiza que incluso cuando se habla de solo una o dos palabras, hace la diferencia.

AaronLS
fuente
55
No estamos hablando de leer una novela en mayúsculas; estamos hablando de un puñado de palabras clave que son solo una parte del texto.
Casey
66
Te estás perdiendo el punto. No se trata de cuántas palabras estamos leyendo, se trata de lo que nuestro cerebro ha sido entrenado para hacer rápidamente. Un cartel de la calle, por ejemplo, ciertamente no es una novela, pero han llegado a la misma conclusión. Cuando aprendemos a leer, comenzamos a leer cada letra, pero finalmente nuestro cerebro comienza a reconocer una palabra como un grupo de patrones. Es mejor si esos patrones son consistentes. Recuerde que las letras mayúsculas suelen ser un patrón diferente de las minúsculas, y no solo una versión más grande.
AaronLS
1
Pero hay muy pocas palabras clave y aparecen una y otra vez; Por lo tanto, el reconocimiento debe ser igualmente rápido para cualquier persona que haya estado utilizando SQL durante cualquier cantidad de tiempo.
Casey
3
Es cierto que definitivamente no es algo duro y rápido. Pero solo hay unas pocas palabras clave que son muy comunes. Hay un gran conjunto que no lo es, y a menudo las personas amplían esta práctica de mayúsculas y minúsculas a cosas que son funciones integradas pero no necesariamente palabras clave de lenguaje sintáctico. En la práctica, todavía supero un puñado de palabras clave como SELECT / WHERE / GROUP BY que indican el inicio de una sección principal de una consulta. Pero todas las demás palabras clave, como funciones integradas como cast, rankminúsculas.
AaronLS
19

¡Es porque SQL es un lenguaje tan antiguo ( 1974 ) que cuando fue concebido, la mayoría de los teclados no tenían letras minúsculas! La documentación del lenguaje simplemente reflejaba la tecnología de la época.

La investigación ha demostrado que ALL CAPS es más difícil de leer, tanto que la Administración Federal de Carreteras de EE. UU. Ha ordenado el uso de letreros con mayúsculas y minúsculas en su Manual sobre dispositivos de control de tráfico uniforme, que establece:

Las letras de los nombres de lugares, calles y autopistas en las señales de guía de carreteras convencionales deben ser una combinación de letras minúsculas con letras mayúsculas iniciales.

The New York Post también publicó:

Los estudios han demostrado que es más difícil leer los signos de mayúsculas, y se ha demostrado que esos milisegundos adicionales gastados mirando lejos de la carretera aumentan la probabilidad de accidentes, especialmente entre los conductores mayores.

No hay buenas razones para usar letras mayúsculas, y buenas razones para no hacerlo.

Yo personalmente odio usar mayúsculas para las palabras clave de SQL. Me resulta más difícil de leer y absurdo en estos tiempos.

El lenguaje SQL se define como insensible a mayúsculas y minúsculas. ¡Quita el dedo de esa tecla de mayúsculas!

Bohemio
fuente
3
Creo que la prevalencia de buenas razones presentadas en otras respuestas habla en contra de su afirmación "no hay una buena razón para usar letras mayúsculas".
bignose
77
@bignose Oh, hay razones ... Simplemente no creo que sean buenas. En mi experiencia, cuanto más joven sea el programador de SQL, más probabilidades tendrá de usar mayúsculas. Por el contrario, nunca he conocido un codificador SQL competente que utilice mayúsculas.
Bohemio
3
Totalmente de acuerdo. La prevalencia de otras "respuestas" no las hace correctas, solo las hace preventivas. TODO EL CASO SUPERIOR ES UNA RESUELTA DE CUANDO LAS COMPUTADORAS NO TENÍAN CASO EN SUS TECLADOS O EN SUS REPRESENTACIONES DE CARÁCTER. Es solo tonto hoy.
Charles Bretana
Sí, y usando la tecla BLOQ MAYÚS o apretando los dedos manteniendo presionadas las teclas Mayús innecesariamente.
Gordon Bell
9
Huelo razonamiento circular aquí. Si la razón se presenta a favor de discriminar palabras clave con mayúsculas y minúsculas, la descarta como una buena razón. Si la razón es presentada por un codificador de SQL pero no está de acuerdo con su posición, usted los descarta por no ser un codificador de SQL competente . Creo que sobre esa base podemos descartar esto como argumento inválido.
bignose
8

Las mayúsculas pueden proporcionar una ganancia en la visibilidad de palabras clave, pero puede compensar con resaltado de código y sangría.
Usamos minúsculas porque el editor de consultas y otras herramientas hacen maravillas al editar el código t-sql, y no vemos la necesidad de torturar el dedo meñique.

Ovidiu Pacurar
fuente
2
¿El editor de consultas y t-sql son los únicos lugares donde alguien leerá su código SQL? ¿Cómo lo sabes?
bignose
8

Mono, mono, hazlo por mí. Coincidencia de patrones: si lo hago de la forma en que lo he visto, la estructura de las cláusulas se alinea mentalmente más fácilmente.

dkretz
fuente
7

Las mayúsculas son menos legibles. El bosquejo de todas las palabras tiene forma de cuadros; No hay descendientes ni ascendentes. FTW en minúsculas!

Lance Fisher
fuente
3
La razón por la que usted apoya la posición de que las mayúsculas ayudan a distinguir las palabras clave del resto.
bignose
55
@bignose Si SQL se lee como lenguaje humano, ¿por qué necesitamos mayúsculas? No necesitamos poner en mayúscula nuestros verbos O preposiciones en lenguaje humano. Imagínese SI CADA oración se viera así. Me parece menos legible que la escritura normal. Las palabras en mayúsculas en esas dos oraciones hacen que mi cerebro se detenga y las diga más despacio que el resto de la oración, lo que ralentiza mi lectura y hace que el flujo sea menos natural.
Chris Middleton
1
El lenguaje humano es muy indulgente con la ambigüedad en la sintaxis. Los lenguajes de computadora no lo son, es por eso que esas ambigüedades deben minimizarse. La sintaxis SQL no ayuda con eso, por lo que los humanos necesitamos usar las herramientas disponibles; La sintaxis SQL no tiene mucho, por lo que hemos desarrollado la convención de capitalizar palabras clave.
bignose
5

Lo encuentro más legible. Lo mismo para tener una nueva línea para el comienzo de cada cláusula y sangría entre cláusulas.

Mark Bostleman
fuente
2

Pruebe un producto de formateo (uso SQL Prompt / SQL Refactor de Red Gate). Puede configurar cómo desea que funcione la capitalización, y su código siempre tendrá un formato consistente. Descansa el meñique y deja que la computadora haga el trabajo por ti.

gfrizzle
fuente
1
Este consejo ignora los muchos contextos donde se lee SQL. Es totalmente poco práctico para leer el código ya escrito por otra persona; Si se necesita una herramienta como esta solo para hacer que el SQL mal formateado sea legible, ese es un argumento a favor de una convención como la que aborda esta pregunta.
bignose
pero este enfoque es bueno si desea estándares en toda su organización. Si quieres estándares, la opinión no importa
Trubs
2

Una de las razones para continuar usando mayúsculas es cuando usted (u otra persona) está viendo el código en algo como el bloc de notas, lo que hace que sea más fácil de leer. es decir, puede diferenciar fácilmente entre las "palabras clave" y los nombres de tabla, SP, udf, etc.

CPU_BUSY
fuente
1

Aparte de la conformidad por conformidad de conformidad, no. Aunque es un tema muy subjetivo, prefiero usar mayúsculas y minúsculas para todos los SQL. El SQL es mucho más fácil de leer, y no se pierde nada en los IDE modernos donde las palabras clave están codificadas por colores de todos modos.

Charles Bretana
fuente
Como muchas otras respuestas aquí han presentado razones, no creo que su respuesta sea correcta: hay razones "distintas de la conformidad por el bien de la conformidad".
bignose
... entonces, ¿qué son? Aunque siempre abierto a nueva información, francamente, nunca he tenido conocimiento de ninguna.
Charles Bretana
Ya he dado muchas razones , así que ahora lo sabes.
bignose
2
ninguno de esos son motivos válidos, son preferencias personales. Siéntase libre de hacer lo que dicte su preferencia personal, pero no caracterice una preferencia como regla o práctica recomendada.
Charles Bretana
1

Intellisense / autocompletion en Microsoft SQL Server Management Studio permite mayúsculas o minúsculas para palabras reservadas, pero las llamadas en mayúsculas funcionan como MAX (), SUM ().

Aun así, el analizador todavía permite procesar versiones en minúsculas de max () y sum ().

Esto implica una ambivalencia con respecto a la naturaleza de la ejecución y, por lo tanto, es simplemente una cuestión de preferencia personal.

Cuenta
fuente
44
Sí, y en SSMS "Opciones -> Editor de texto -> Transact-SQL -> Intellisense" puede establecer el valor predeterminado en 'Minúsculas' si lo prefiere.
Gordon Bell
0

No me gusta nada escrito en mayúsculas (y odio escribir todo en mayúsculas aún más), pero no podía convencerme de ir en contra de la comunidad. Como de costumbre, Vim y sus paquetes asociados son la solución a tantos problemas:

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

Simplemente escriba de forma normal y se capitalizarán automáticamente las palabras clave a medida que escribe. No he usado todos los encantamientos oscuros de SQL, pero todavía no me ha fallado.

Ferdinand van Wyk
fuente
-2

Llamo a la mayoría de mi código mySQL desde PHP, y hago toda mi edición de PHP dentro de vim (o supongo que en este caso, VIM ;-). Ahora estoy seguro de que existen complementos para resaltar el código mySQL dentro de PHP, pero no lo he encontrado y no tengo tiempo para buscarlo. Por lo tanto, prefiero tener todo en mayúsculas. Encuentro esto:

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

Me ayuda a distinguir entre PHP versus SQL mucho mejor que esto:

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

Además, por alguna razón, odio mezclar allcaps con camel case, así:

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

Eso IDme molesta. ¿Debería ser en su lugar id? o iD?

puk
fuente
3
No, no, no, camelCase es para nombres de variables, no para nombres de columnas. Use el caso apropiado para los nombres de columna ... InsertDate, AlterDate, ...
Gordon Bell
1
El estándar SQL requiere implementaciones para ignorar mayúsculas y minúsculas en los identificadores (los dobla a mayúsculas). Por lo tanto, su código no debe depender de las diferencias entre mayúsculas y minúsculas en los identificadores, y la forma convencional de hacerlo es hacer identificadores all_lower_case.
bignose
3
@bignose No soy un gran admirador del guión bajo ya que disminuye wpm
puk