Академический Документы
Профессиональный Документы
Культура Документы
(Estilos de Codificación)
¿Cómo se debe formatear el código SQL? ¿Qué tipo de sangría debes usar? ¿Las palabras
clave deben estar en mayúsculas? ¿Cómo se deben alinear las listas? SQL es uno de esos
lenguajes que se ejecutarán de todas formas, sin embargo, usted trata los espacios en blanco
y las mayúsculas. Sin embargo, la forma en que se presenta el SQL afectará su legibilidad y
el tiempo necesario para revisarlo y comprenderlo. La estandarización del diseño del
código es un tema importante, pero ¿qué estándar debería adoptar? Rob evita una respuesta
directa, pero le dice el tipo de respuestas que tendrá que decidir al crear una estrategia para
formatear el código SQL.
Pocos temas generan tanto debate entre los ingenieros de bases de datos como la
forma en que se debe formatear el código Transact-SQL. Por cada problema
planteado, es probable que reciba el doble de opiniones que personas. Sin
embargo, la estandarización del código T-SQL en una organización es esencial
para facilitar las revisiones de código efectivas y eficientes, solucionar problemas
de las secuencias de comandos T-SQL, apoyar los esfuerzos de desarrollo
conjunto y transferir proyectos de un grupo a otro. Los ingenieros de DB pueden
estar en desacuerdo sobre cómo debería ser el código, pero pocos cuestionarán la
conveniencia de implementar tales estándares.
Sin embargo, como todos saben quiénes participaron en este proceso, no es una
tarea fácil. Y mientras más gente de DB esté involucrada, más hercúleo es el
proyecto. Pero tiene que comenzar en alguna parte, y de eso se trata este artículo:
para brindarle un resumen de los tipos de decisiones que deberá tomar cuando
intente estandarizar el formato de su código. Ya sea que esté trabajando con un
software de embellecimiento, como la función de formato SQL incluida en la
solicitud de SQL de Red Gate o formateando todo su código de forma manual,
debe tener en cuenta una variedad de factores al determinar cómo aplicar estilo a
su script T-SQL.
Una advertencia, sin embargo. Esta no es una discusión acerca de cómo optimizar
su código, maximizar el rendimiento o determinar qué políticas implementar para
abordar problemas como la indexación, el uso de GUID como claves principales, si
se debe almacenar el contenido de BLOB, cómo establecer políticas de seguridad,
etc. Por supuesto, estas son todas consideraciones importantes, pero no son en lo
que nos estamos enfocando aquí.
Caso (Capitalización)
Caso se refiere a la forma en que T-SQL debe o no debe ser capitalizado en su
código. Por ejemplo, algunos desarrolladores prefieren hacer mayúsculas todas
las claves reservadas, otros prefieren minúsculas, y algunas mezclan y
combinan. Es todo una cuestión de preferencia. Al determinar qué estrategias
implementar en relación con el caso, debe tener en cuenta las siguientes
consideraciones:
Aquí hay otro ejemplo. Esta vez, las palabras clave son mayúsculas, los tipos de
datos en minúsculas y los nombres de los objetos camel case:
Referencias de objetos
Cuando hace referencia a un objeto, como una tabla o columna, debe decidir
sobre cuestiones como si se debe calificar el nombre del objeto, si se permiten
comodines, etc. Las siguientes preguntas proporcionan un resumen de los tipos de
detalles que debe tener en cuenta al decidir cómo hacer referencia a objetos:
¿Con cuánta amplitud debes calificar los nombres de objetos? Por ejemplo,
¿debería incluir siempre el nombre del esquema con una tabla, incluso si el
esquema es dbo? ¿Deberías incluir el nombre de la base de datos
también?
¿Los diferentes tipos de código requieren diferentes estrategias de
denominación? Por ejemplo, ¿debería hacer referencia a objetos en un
procedimiento almacenado de manera diferente a cómo haría referencia a
objetos en una declaración de lenguaje de definición de datos (DDL)?
¿Se permite el asterisco (*) comodín en las listas SELECT en lugar de
especificar los nombres de columna? ¿Hay circunstancias en que se
permitiría un comodín? Aunque la mayoría de las pautas recomiendan no
usar el comodín en una lista SELECT, no puede asumir que todos sigan
estas pautas. Por esta razón, debe ser muy específico acerca de este tipo
de decisiones de estilo.
¿Deberían especificarse siempre los nombres de columna en las
instrucciones INSERT y UPDATE? Para algunas de estas afirmaciones, no
es necesario incluir los nombres de las columnas, pero las mejores
prácticas generalmente recomiendan que las incluya. Al igual que con el
uso de comodines en las listas SELECT, debe ser muy específico.
¿Se permite el uso de números de columna en lugar de nombres en sus
declaraciones T-SQL? Por ejemplo, puede usar números de columna en la
cláusula ORDER BY cuando haga referencia a columnas en la lista
SELECT.
Ahora compare este ejemplo con el siguiente ejemplo, que especifica los nombres
de columna en la lista SELECCIONAR:
INSERT dbo.ProductDocs
VALUES ('Test1.doc', 'C:\Files\Test.doc')
Alias
Los alias le permiten asignar nombres temporales a objetos (o asignar nombres a
columnas calculadas) para que sea más fácil trabajar con ellos al escribir y revisar
el código. Al determinar qué estrategias emplear para los alias, debe tener en
cuenta varias consideraciones:
SELECT
(c.FirstName + ' ' + c.LastName) AS FullName,
e.LoginID, e.Title
FROM HumanResources.Employee AS e
INNER JOIN Person.Contact AS c
ON e.ContactID = c.ContactID
ORDER BY c.LastName
En combinaciones complejas, los alias de una sola letra a veces pueden hacer
que el código sea más difícil de seguir porque no siempre es intuitivo qué
columnas están asociadas con qué tablas. El siguiente ejemplo utiliza abreviaturas
más significativas para los alias de tablas:
SELECT
(cnt.FirstName + ' ' + cnt.LastName) FullName,
emp.LoginID, emp.Title
FROM HumanResources.Employee emp
INNER JOIN Person.Contact cnt
ON emp.ContactID = cnt.ContactID
ORDER BY cnt.LastName
Comas
Una de las formas más rápidas de causar estragos entre los desarrolladores de T-
SQL es comenzar una discusión sobre cómo se deben tratar las comas dentro del
código T-SQL, particularmente en una lista SELECT. Aun así, se debe establecer
un estándar, y para hacerlo, debe tener en cuenta varios factores:
Las preguntas son bastante sencillas; una solución acordada no lo es. Eche un
vistazo en línea y verá un sinfín de comentarios dedicados a este problema. Antes
de hacer eso, sin embargo, veamos algunos ejemplos de cómo se pueden tratar
las comas. La siguiente instrucción SELECT incluye dos series que requieren
comas: la lista SELECT y la cláusula ORDER BY:
SELECT FirstName,
MiddleName,
LastName,
City,
StateProvinceName
FROM HumanResources.vEmployee
WHERE JobTitle LIKE 'Production Technician%'
ORDER BY StateProvinceName, City
SELECT FirstName
,MiddleName
,LastName
,City
,StateProvinceName
FROM HumanResources.vEmployee
WHERE JobTitle LIKE 'Production Technician%'
ORDER BY StateProvinceName, City
SELECT FirstName
, MiddleName
, LastName
, City
, StateProvinceName
FROM HumanResources.vEmployee
WHERE JobTitle LIKE 'Production Technician%'
ORDER BY StateProvinceName, City
SELECT FirstName,
MiddleName,
LastName,
City,
StateProvinceName
FROM HumanResources.vEmployee
WHERE JobTitle LIKE 'Production Technician%'
ORDER BY StateProvinceName,
City,
LastName
Como puede ver, hay varios enfoques que puede tomar con comas. Y el uso de
coma no se limita de ninguna manera a las listas SELECT y a las cláusulas
ORDER BY. En las siguientes declaraciones de DDL, las comas se usan para
separar los elementos de la función OBJECT_ID y las definiciones de columna:
IF OBJECT_ID
(
'ProductDocs',
'U'
) IS NOT NULL
DROP TABLE ProductDocs
GO
CREATE TABLE ProductDocs
(
DocID int NOT NULL IDENTITY,
DocTitle nvarchar(50) NOT NULL,
DocFileName nvarchar(400) NOT NULL,
CONSTRAINT PK_ProductDocs_DocID PRIMARY KEY CLUSTERED (DocID ASC)
)
GO
Espaciado y alineación
Todos tienen una opinión acerca de cómo se debe espaciar, sangrar y dividir su
código a través de las líneas. Hay tantas formas de diseñar su código como
personas que lo desarrollan. De hecho, intentar determinar el espaciado y la
alineación de los diversos elementos de T-SQL puede ser una de las tareas más
difíciles en su proceso de estándares, pero cuanto más coherente sea el código en
su organización, mejor. Por ese motivo, debe tener en cuenta una serie de
factores al planificar el diseño de su código:
¿Cuál será la política para las nuevas líneas (saltos de línea)? Por ejemplo,
¿debería haber una nueva línea para cada cláusula? ¿Debería haber una
nueva línea para cada palabra clave de la cláusula y una línea separada
para los argumentos de esa palabra clave? Por ejemplo, ¿debería estar la
cláusula FROM en una línea y el nombre de la tabla en la siguiente línea?
¿Cuál es el número máximo de caracteres permitido en cada
línea? ¿Deberían los anchos de línea proporcionar la impresión del código
sin agregar saltos de línea no planificados?
¿Cómo manejará las cláusulas que exceden el ancho máximo de
línea? ¿Deben sangrarse las líneas posteriores?
¿Cuál es la política general de sangría? Por ejemplo, en una instrucción
SELECT, ¿deberían cada sangría después de la cláusula SELECT estar
sangrada? ¿Deben sangrarse más los argumentos a la cláusula?
¿Usará espacios o tabulaciones para la sangría? Si usas espacios,
¿cuántos espacios por sangría?
¿Cómo manejará las uniones en sus consultas? ¿Las palabras clave JOIN
y ON comenzarán nuevas líneas? ¿Debería cada cláusula en una unión
estar en líneas separadas?
¿Cómo deben manejarse las consultas relacionadas con XML? Por
ejemplo, ¿cómo debe formatear una consulta que incluye un método XML
en la lista SELECT? ¿Qué pasa si el método hace referencia a un espacio
de nombres?
SELECT
FirstName, MiddleName, LastName, City, StateProvinceName
FROM
HumanResources.vEmployee
WHERE
JobTitle LIKE 'Production Technician%'
ORDER BY
StateProvinceName, City
SELECT
FirstName,
MiddleName,
LastName,
City,
StateProvinceName
FROM
HumanResources.vEmployee
WHERE
JobTitle LIKE 'Production Technician%'
ORDER BY
StateProvinceName,
City
Observe también que los elementos que componen cada cláusula tienen tres
espacios con sangría para delinear claramente cada cláusula y sus elementos. De
hecho, existen numerosas estrategias de sangría que puede implementar. Por
ejemplo, en la siguiente instrucción SELECT, cada cláusula después de la
cláusula SELECT está sangrada:
Otro enfoque que puede tomar es sangrar los elementos para que todos
comiencen en el mismo margen, como en el siguiente ejemplo:
SELECT FirstName,
MiddleName,
LastName,
Cityty,
StateProvinceName
FROM HumanResources.vEmployee
WHERE JobTitle LIKE 'Production Technician%'
ORDER BY StateProvinceName, City
Esta vez, las palabras clave UNIR y ENCENDIDO se agregan antes del salto de
línea. Otra estrategia que podría emplear es sangrar la condición de unión
completa, como en el siguiente ejemplo:
SELECT
cnt.FirstName,
cnt.LastName,
emp.LoginID,
emp.Title
FROM
HumanResources.Employee emp
JOIN Person.Contact cnt
ON emp.ContactID = cnt.ContactID
ORDER BY
cnt.LastName
Bloques de código
Para este artículo, uso el término bloque de código a la ligera. En este caso, se
refiere a cualquier tipo de bloque de código, ya sea una construcción TRY /
CATCH, las definiciones de columna entre paréntesis, una expresión booleana
compleja, una subconsulta o cualquier otro grupo de código. Y la forma en que
distribuye los bloques de código está vinculada a las decisiones que toma sobre el
espaciado y la alineación. Al determinar cómo formatear bloques de código, debe
tener en cuenta las siguientes consideraciones:
¿Cómo debe manejar los bloques de código como BEGIN / END, IF / ELSE
o TRY / CATCH? ¿Debería especificar políticas para cada tipo de bloque de
código? ¿Cómo manejarás los elementos en cada bloque? ¿Deben estar
sangrados los elementos internos? ¿Las palabras clave deberían estar en
líneas separadas?
¿Cómo manejará los bloques de código cuando uno está incrustado en
otro? Por ejemplo, si usa los bloques BEGIN / END dentro de su
construcción IF / ELSE, ¿cómo debe tratarse cada elemento? ¿Debería
sangrar los bloques BEGIN / END? ¿Deben colocarse palabras clave como
ELSE y BEGIN en líneas separadas?
¿Cómo deben manejarse las subconsultas en su código T-SQL? ¿Deben
ser tratados de la misma manera, independientemente de donde
ocurran? Por ejemplo, ¿debería una subconsulta en una lista
SELECCIONAR ser tratada de manera diferente a una subconsulta en una
cláusula WHERE? ¿Qué pasa con la sangría? ¿Deben las subconsultas
estar en líneas separadas de otros elementos?
¿Cómo se deben formatear las expresiones en sus sentencias T-
SQL? ¿Deben estar separados de otros elementos en la
declaración? ¿Deberían los operadores condicionales estar en líneas
separadas?
¿Cómo tratarán los paréntesis y llaves en sus declaraciones? ¿Deberían
usarse los saltos de línea y la sangría para separarlos de otros elementos
de declaración? ¿Debería su formato estar basado en cómo se
usan? Después de todo, los paréntesis se utilizan para expresiones,
lenguaje de definición de datos (DDL), parámetros de función y
subconsultas. ¿Deberían ser tratados de manera diferente en cada caso?
Veamos algunos códigos que ayudan a ilustrar estos temas. En la siguiente
declaración CREATE TABLE, el conjunto de paréntesis que encierra la definición
de columna se diferencian del resto de la declaración:
DECLARE @a varchar(10)
DECLARE @b varchar(10)
SET @a = 'one'
SET @b = 'two'
IF ((@a = @b) OR (@a = 'two'))
BEGIN
PRINT 'The first condition is correct.'
END
ELSE
BEGIN
PRINT 'The first condition is incorrect.'
END
En este caso, solo se sangran los contenidos de los bloques BEGIN / END. Sin
embargo, dado que los bloques BEGIN / END están incrustados en los bloques IF
/ ELSE, también puede decidir sangrar las palabras clave BEGIN / END, como se
muestra en el siguiente ejemplo:
Una vez más, todos estos detalles son los tipos de consideraciones que debe
tener en cuenta para que pueda tener un código coherente en toda su
organización.
Comentarios
Los comentarios son bastante autoexplicativos. Si planea usarlos, entonces
debería tener políticas que tomen en cuenta su uso, en cuyo caso debe considerar
lo siguiente:
El siguiente ejemplo muestra los dos tipos de comentarios admitidos por T-SQL y
cómo se pueden usar los comentarios antes o después del código, o dentro del
código:
/*
Retrieves employee data for Production Technicians
Orders data by state, then city
*/
SELECT FirstName, MiddleName, LastName, --retrieve full name
City, StateProvinceName
FROM HumanResources.vEmployee
-- Pull Production Technicians only
WHERE JobTitle LIKE 'Production Technician%'
ORDER BY StateProvinceName, City --order by state, then city
/*
CONFIDENTIAL
*/
Convenciones de nombres
Determinar las convenciones de nomenclatura no es realmente un problema de
formato, per se, pero rara vez entablará discusiones sobre el formato sin
finalmente hablar de cómo nombrar las cosas, así que pensé que plantearía este
problema para que esté en su radar mientras configura su normas Dicho esto,
aquí hay algunas consideraciones a tener en cuenta:
Avanzando
Además de la cantidad de problemas que he mencionado anteriormente, también
debe determinar si debe desarrollar un conjunto de estándares para cada tipo de
declaración. Por ejemplo, las declaraciones de DDL y DML requieren reglas
diferentes. Es posible que sus estándares también quieran cubrir cómo se colocan
las declaraciones dentro de un archivo de código. Por ejemplo, ¿todas las
asignaciones de variables (DECLARAR y CONFIGURAR) en un procedimiento
almacenado deben estar al principio de la definición del procedimiento?
Por supuesto, habrá otros temas que querrá abordar al reunir sus estándares de
formato. Pero las preguntas anteriores deberían, al menos, proporcionarle un
punto de partida. También deben demostrar la amplitud de este compromiso al
tratar de negociar los muchos detalles que deberán decidirse para implementar un
conjunto de políticas que definan cómo debe formatearse el código T-SQL de su
organización.
Sin embargo, tenga en cuenta que, incluso con el mejor esfuerzo, encontrará que
la definición de estándares es un proceso continuo. Debe tratar de bloquear e
implementar sus estilos lo antes posible, pero sepa que inevitablemente se
encontrará con situaciones en las que esos estándares no cubren lo que necesita
o tendrán que ser modificados para cumplir con los requisitos cambiantes. Por ese
motivo, junto con los estándares, también debe implementar un proceso que le
permita implementar los cambios de la manera más rápida y fluida posible. Y debe
tratar de mantener sus documentos de normas lo más actualizados
posible. Mientras tanto, este artículo debe darle una idea de los tipos de
problemas que deberá abordar y la cantidad de decisiones que deberá tomar para
implementar una estrategia de formato integral y efectiva.