Вы находитесь на странице: 1из 17

Estándares de Formato Transact-SQL

(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í.

De hecho, debido a la naturaleza volátil de las discusiones sobre el


formateo, intentaré refrenarme por completo de mis opiniones y, en cambio,
centrarme en los problemas en sí y no en su resolución. Las decisiones finales
sobre cómo formatear su código dependen de usted. Lo que planeo proporcionar
aquí son las preguntas que debe hacerse a medida que planea su estrategia de
formato. También proporciono ejemplos que demuestran diferentes formas en que
puede formatear su código.

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:

 ¿Cómo debe clasificar Transact-SQL en términos de palabras clave, tipos


de datos, objetos definidos por el usuario, etc.? Por ejemplo, ¿todas las
palabras reservadas deben tratarse como una categoría o prefiere tratar los
tipos de datos de manera diferente a otras palabras clave? ¿Qué pasa con
los objetos definidos por el usuario, como tablas y vistas? Algunas fuentes
dividen esta categoría en escalares (columnas, parámetros, variables) y
objetos de esquema (tablas, vistas, procedimientos almacenados). Otros no
hacen distinciones y tratan todos los elementos T-SQL como una sola
categoría.
 ¿Qué reglas de caso aplicarás a cada categoría? Por ejemplo, ¿las
palabras clave deben estar en mayúsculas y los tipos de datos en
minúsculas? ¿Debería usar un caso de camello (palabras compuestas con
un capital inicial) para objetos definidos por el usuario, como los nombres
de tablas?

Veamos algunos ejemplos que demuestran diferentes estrategias de


capitalización. En la primera declaración, todas las palabras reservadas de T-SQL
están en mayúsculas, pero los nombres de objetos definidos por el usuario, como
tablas y columnas son mayúsculas, con la primera letra en mayúscula:

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

En el siguiente ejemplo, todas las palabras reservadas están en minúsculas, y los


nombres de los objetos definidos por el usuario son mayúsculas y minúsculas:

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

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:

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

La clave para una estrategia de capitalización debe ser la legibilidad. No existe un


derecho real o incorrecto, siempre y cuando los estándares se apliquen de forma
coherente en toda la organización (y usted sea coherente con la recopilación de
los identificadores utilizados en las bases de datos de destino).

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.

Veamos algunos ejemplos que demuestran algunos de estos problemas. En el


primer ejemplo, se utiliza un comodín en la lista SELECCIONAR, en lugar de los
nombres de columna:

SELECT * FROM ProductDocs

Ahora compare este ejemplo con el siguiente ejemplo, que especifica los nombres
de columna en la lista SELECCIONAR:

SELECT DocID, DocTitle FROM AdventureWorks.dbo.ProductDocs

Claramente, no hay duda de qué columnas deben recuperarse. Incluso si se


agregan nuevas columnas a la tabla, el código seguirá funcionando. Observe
también en este ejemplo que el nombre de la tabla se califica con la base de datos
y los nombres de esquema. Una vez más, debe decidir cómo manejar este tipo de
problemas. Ahora eche un vistazo a un ejemplo que incluye una cláusula ORDER
BY. En este caso, la cláusula usa un número entero para referirse a la columna
DocTitle, la segunda columna en la lista SELECCIONAR:

SELECT DocID, DocTitle


FROM AdventureWorks.dbo.ProductDocs
ORDER BY 2 DESC

La mayoría de las guías de mejores prácticas recomiendan no usar el número


entero de esta manera, pero al igual que el uso del comodín en la lista
SELECCIONAR, todavía se hace. En el siguiente ejemplo, la cláusula ORDER BY
especifica el nombre de la columna:

SELECT DocID, DocTitle


FROM AdventureWorks.dbo.ProductDocs
ORDER BY DocTitle DESC
Como puede ver en este ejemplo, la lista SELECCIONAR incluye los nombres de
columna, en lugar de un comodín, el nombre de la tabla se califica con los
nombres de la base de datos y el esquema, y la cláusula ORDER BY contiene el
nombre de la columna. Sus estándares deben ser muy específicos sobre todos
estos tipos de problemas y no asumir nada.

Ahora echemos un vistazo a otro tema. En el siguiente ejemplo, una declaración


INSERT agrega datos a la tabla ProductDocs sin especificar los nombres de
columna:

INSERT dbo.ProductDocs
VALUES ('Test1.doc', 'C:\Files\Test.doc')

Dependiendo de la definición de la tabla, a menudo puede insertar datos sin


especificar las columnas. Sin embargo, si la definición de la tabla debería cambiar,
esta declaración fallaría. Por esa razón, las pautas de mejores prácticas a menudo
especifican que los nombres de las columnas deben incluirse, como en el
siguiente ejemplo:

INSERT dbo.ProductDocs (DocTitle, DocFileName)


VALUES ('Test2.doc', 'C:\Files\Test.doc')

Observe en los últimos dos ejemplos que el nombre de la tabla se ha calificado


solo con el nombre del esquema. De nuevo, esta es una decisión que deberá
tomar cuando defina sus políticas sobre la llamada a objetos.

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:

 ¿Implementarás una estrategia diferente para diferentes tipos de alias? Por


ejemplo, ¿los alias de tablas deben tratarse igual que los alias de
columnas? ¿Deberían tratarse todos los alias de columna por igual, o
deberían tratarse las columnas calculadas de manera diferente a las
columnas renombradas?
 ¿Qué tipos de nombres de alias están permitidos? ¿Se pueden usar letras
individuales para los alias de tablas? ¿Se pueden usar abreviaturas para
cualquier tipo de alias? ¿Deben los alias de columna seguir las mismas
convenciones de denominación que las utilizadas para los nombres de
objetos?
 ¿Debe usarse siempre la palabra clave AS? ¿Nunca usado?
En el siguiente ejemplo, el alias de columna (FullName) es una palabra
compuesta, pero los alias de la tabla son letras individuales:

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

Observe el uso de la palabra clave AS en los dos últimos ejemplos. En el primer


ejemplo se utiliza AS. En el segundo ejemplo, no lo es. Nuevamente, sus
estándares de formato deben especificar si se incluye la palabra clave AS.

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:

 ¿Deben las comas ser tratadas de manera diferente en diferentes


circunstancias? Por ejemplo, ¿deberían tratarse las columnas en una lista
SELECT igual que las columnas en una cláusula ORDER BY? ¿Qué pasa
con las comas utilizadas en una lista de parámetros?
 Para los nombres de objetos que se separan en varias líneas, como ocurre
a veces en el caso de una lista SELECT, ¿deberían las comas terminar la
línea o comenzar la línea?
 ¿Deben usarse espacios o tabulaciones antes o después de las comas?

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

Observe que en la lista SELECCIONAR las comas se colocan al final de los


nombres de columna. Sin embargo, en la cláusula ORDER BY, los nombres de las
columnas están en una línea, por lo que la coma aparece después del primer
nombre de la columna, seguido de un espacio. Otro enfoque que puede tomar es
preceder a los nombres de columna en la lista SELECCIONAR con una coma,
como en el siguiente ejemplo:

SELECT FirstName
,MiddleName
,LastName
,City
,StateProvinceName
FROM HumanResources.vEmployee
WHERE JobTitle LIKE 'Production Technician%'
ORDER BY StateProvinceName, City

En este caso, la coma se coloca directamente delante de los nombres de columna


en la lista SELECCIONAR. Sin embargo, también puede optar por agregar un
número fijo de espacios después de cada columna:

SELECT FirstName
, MiddleName
, LastName
, City
, StateProvinceName
FROM HumanResources.vEmployee
WHERE JobTitle LIKE 'Production Technician%'
ORDER BY StateProvinceName, City

Ahora echemos un vistazo a un ejemplo en el que la cláusula ORDER BY se trata


como la lista SELECT:

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

En este caso, los parámetros de la función se tratan como las definiciones de


columna. Sin lugar a dudas, propondrá sus propias estrategias sobre cómo
manejar problemas como las funciones y las columnas. Sin embargo, sea cual sea
la estrategia que implemente, debe tener en cuenta las diversas formas en que se
usan las comas. Y parte de esas consideraciones dependerá de cómo espacie y
alinee los diversos elementos en sus declaraciones.

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?

Ahora veamos algunos ejemplos que demuestran diferentes estrategias de


espaciado. En el primer ejemplo, cada cláusula comienza en una línea separada:

SELECT FirstName, MiddleName, LastName, City, StateProvinceName


FROM HumanResources.vEmployee
WHERE JobTitle LIKE 'Production Technician%'
ORDER BY StateProvinceName, City

Compare este ejemplo con el siguiente, en cada cláusula y cada conjunto de


argumentos de cláusula comienza en líneas separadas:

SELECT
FirstName, MiddleName, LastName, City, StateProvinceName
FROM
HumanResources.vEmployee
WHERE
JobTitle LIKE 'Production Technician%'
ORDER BY
StateProvinceName, City

En ambos casos, el código se puede leer fácilmente porque son declaraciones


muy simples. Sin embargo, cuanto más complejas sean sus declaraciones, más
importante será tener estándares de formato que puedan lidiar con estas
complejidades. Por ejemplo, si sus cláusulas no encajan en una sola línea, debe
determinar cómo manejará los ajustes de línea, como la lista SELECT en el
siguiente ejemplo:

SELECT FirstName, MiddleName, LastName,


City, StateProvinceName
FROM HumanResources.vEmployee
WHERE JobTitle LIKE 'Production Technician%'
ORDER BY StateProvinceName, City
Observe que la lista SELECT ahora abarca dos líneas y que la segunda línea está
sangrada. Sin embargo, en lugar de adoptar este enfoque, puede separar los
elementos de la lista SELECT y la cláusula ORDER BY en líneas separadas:

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:

SELECT FirstName, MiddleName, LastName, City, StateProvinceName


FROM HumanResources.vEmployee
WHERE JobTitle LIKE 'Production Technician%'
ORDER BY StateProvinceName, City

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

Como puede ver, todas las columnas y nombres de tablas se


alinean. Además, en este caso, las pestañas se utilizan en lugar de espacios para
sangrar los elementos. El uso de pestañas en lugar de espacios puede ser
inicialmente más fácil, pero cuando comienza a mover el código y cortar y pegar,
los espacios parecen ser más efectivos. Pero, de nuevo, esta es una llamada de
juicio, una que tienes que hacer tú mismo. Mientras tanto, eche un vistazo al
siguiente ejemplo, que incluye una unión en la cláusula FROM:

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

En este ejemplo, la palabra clave JOIN comienza una nueva línea,


siguiendo la tabla unida. La cláusula ON sigue en otra línea nueva y tiene
sangría. Sin embargo, es posible que adopte una estrategia diferente cuando
trabaje con uniones, como en la siguiente declaración:

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

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

Al configurar sus estándares de formato, también debe tener en cuenta las


consultas relacionadas con XML. Por ejemplo, la siguiente declaración de
selección utiliza el método de consulta XML () para recuperar el nombre del
candidato del trabajo:

SELECT JobCandidateID, EmployeeID, Resume.query(


'declare namespace ns=
"http://schemas.microsoft.com/sqlserver/2004/07/adventure-works/Resume";
data(/ns:Resume/ns:Name/ns:Name.Last)') AS CandidateName
FROM HumanResources.JobCandidate
WHERE EmployeeID IS NOT NULL

Observe cómo el argumento del método se diferencia del resto de la lista


SELECT. Observe también que el espacio de nombres se ajusta a una segunda
línea. Otro enfoque que puede tomar es aislar aún más el argumento del método:

SELECT JobCandidateID, EmployeeID,


Resume.query
(
'declare namespace ns=
"http://schemas.microsoft.com/sqlserver/2004/07/adventure-works/Resume";
data(/ns:Resume/ns:Name/ns:Name.Last)'
) AS CandidateName
FROM HumanResources.JobCandidate
WHERE EmployeeID IS NOT NULL

XML puede ser complicado cuando se trata de implementar estándares de formato


porque los elementos de XQuery pueden llegar a ser bastante largos,
especialmente cuando se hace referencia al espacio de nombres, como en los
ejemplos anteriores.

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:

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

Como puede ver, el paréntesis de apertura está en una línea separada, el


paréntesis de cierre está en su propia línea y todo lo que está en medio está
sangrado. Sin embargo, los paréntesis y los elementos que encierran pueden
tratarse de diversas maneras. Por ejemplo, la siguiente instrucción CREATE
TABLE, la nueva línea viene después de abrir paréntesis y después de cerrar
paréntesis:

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

Otro problema es cómo manejar bloques de código como IF / ELSE. En el


siguiente ejemplo, cada palabra clave que comienza o termina un bloque está en
su propia línea:

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:

DECLARE @c varchar(10), @d varchar(10)


SET @c = 'one'
SET @d = 'two'
IF (@c = @d) OR (@c = 'two')
BEGIN
PRINT 'The first condition is correct.'
END
ELSE
BEGIN
PRINT 'The first condition is incorrect.'
END

Otra consideración es cómo manejar expresiones, como la expresión booleana


después de la palabra clave IF. En el ejemplo anterior, la expresión está en la
misma línea que la palabra clave IF. Sin embargo, también puede separar los
elementos de expresión, como se muestra en el siguiente ejemplo:

DECLARE @e varchar(10), @f varchar(10)


SET @e = 'one'
SET @f = 'two'
IF (
(@e = @f)
OR
(@e = 'two')
) BEGIN
PRINT 'The first condition is correct.'
END
ELSE BEGIN
PRINT 'The first condition is incorrect.'
END

Note también que el primer BEGIN viene al final de la expresión booleana y el


segundo BEGIN está en la misma línea que ELSE. Nuevamente, debe decidir
cómo desea manejar cada uno de estos elementos al definir sus
estándares. Ahora veamos un ejemplo de instrucción SELECT que incluye una
subconsulta:

SELECT cnt.FirstName, cnt.LastName, emp.SickLeaveHours,


(SELECT AVG(SickLeaveHours)
FROM HumanResources.Employee) AS AvgSickLeave
FROM HumanResources.Employee emp
JOIN Person.Contact cnt
ON emp.ContactID = cnt.ContactID
WHERE emp.EmployeeID = 1

Como puede ver, la subconsulta es un elemento en la lista SELECCIONAR y es lo


suficientemente larga como para requerir dos líneas. También puede optar por
separar la subconsulta aún más:

SELECT cnt.FirstName, cnt.LastName, emp.SickLeaveHours,


(
SELECT AVG(SickLeaveHours)
FROM HumanResources.Employee
) AS AvgSickLeave
FROM HumanResources.Employee emp
JOIN Person.Contact cnt
ON emp.ContactID = cnt.ContactID
WHERE emp.EmployeeID = 1

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:

 ¿Los comentarios siempre deben incluirse en los archivos de código y en la


declaración T-SQL?
 Si se utilizan comentarios de apertura en un archivo de código, ¿deberían
estandarizarse? Por ejemplo, ¿deberían estar siempre en el mismo formato
e incluir la misma información, como el nombre del desarrollador, el historial
de revisiones y el propósito del código?
 ¿Debería usar solo un tipo de comentario en su código? Por ejemplo,
¿debería usar la convención de barra / asterisco (/ *… * /), en lugar de la
convención de doble guión (-)?

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:

 ¿Debería usar diferentes estándares de nombres para diferentes tipos de


objetos? Por ejemplo, ¿debería diferenciar entre tablas, columnas,
procedimientos almacenados, funciones, vistas, restricciones, índices, etc.?
 Si implementa estándares de nombres basados en el tipo de objeto,
¿cuáles serán los estándares? Por ejemplo, ¿todos los nombres de
procedimientos almacenados deben basarse en una acción? ¿Deberían las
restricciones de la clave primaria estar basadas en nombres de columna?
 ¿Debería estandarizar nombres para diferentes tipos o agrupaciones de
objetos dentro de una base de datos? Por ejemplo, ¿todas las tablas
relacionadas con el marketing deben tener el prefijo "Mkt"? ¿Todos los
nombres de columna que especifican un valor entero de identificación
deben terminar en "ID"? ¿Deberían las tablas puente de muchos a muchos
reflejar los nombres de las tablas que están enlazando?
 ¿Los nombres de tablas y vistas deben ser singulares o plurales, como
BookTitle versus BookTitles? ¿Qué pasa con los sustantivos que tienen una
forma plural, como personas versus persona?
 ¿Los nombres de los objetos deben tener un prefijo o un sufijo? ¿Debería el
uso de prefijos o sufijos estar basado en el tipo de objeto? Por ejemplo,
¿usaría “usp_” para prefijar los nombres de procedimientos almacenados
definidos por el usuario, o “pk_” para prefijar los nombres de restricciones
de clave primaria? ¿Deben prefijarse algunos tipos de objetos y no otros?
 ¿Se pueden usar guiones bajos (_) u otros caracteres especiales en los
nombres de objetos? ¿Qué pasa con las palabras
clave? Espacios? ¿Debería haber una política de que no se use un nombre
que no pueda llamarse sin incluir ese nombre entre paréntesis?
 ¿Deberían usarse abreviaturas para nombres de objetos? ¿Qué hay de
letras individuales?

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.

Вам также может понравиться