Convenciones y Buenas Prácticas en

Programación
Lucio Marcelo Quispe Ortega
¿Qué son las Convenciones y Buenas Prácticas?
● Son guías o conjunto de directrices (no oficiales, ni estandarizadas) que
recomiendan estilos de programación, prácticas y métodos para cada
aspecto de un lenguaje de programación.
○ Las convenciones pueden ser genéricas o para un lenguaje en específico.
● Nos permiten adquirir buenos hábitos en la programación, lo cual nos
llevará a obtener software de calidad y que sea más fácil de mantener.
○ OJO! Conocer varios lenguajes de programación o escribir miles de líneas código no
te hacen buen programador si es que no aplicaste buenas prácticas en
programación, simplemente porque tu código no será un código limpio.
Pero, ¿Qué es Código limpio?
Definiciones tomadas del libro Código Limpio.

“Me gusta que mi código sea elegante y eficaz. La lógica debe ser directa para
evitar errores ocultos, las dependencias deben de ser mí­nimas para facilitar
el mantenimiento… El código limpio hace bien una cosa.”

Bjarne Stroustrup, creador de C++.

Pero, ¿Qué es Código limpio?
Definiciones tomadas del libro Código Limpio.

“El código limpio se puede leer y mejorar por parte de un programador que
no sea su autor original. Tiene pruebas de unidad y de aceptación. Tiene
nombres con sentido. Ofrece una y no varias formas de hacer algo.”

Dave Thomas, fundador de OTI.

Pero, ¿Qué es Código limpio?
Definiciones tomadas del libro Código Limpio.

“…El código limpio siempre parece que ha sido escrito por alguien a quien le
importa. No hay nada evidente que hacer para mejorarlo.”

Michael Feathers, autor de Working Effectively with Legacy Code.

¿Por qué usar Convenciones?
Las convenciones de código son importantes para los programadores por
múltiples razones entre ellas, las más destacadas:

● Mejoran la lectura del código fuente para ti y los demás. Casi ningún software es mantenido de
por vida por su autor original.
● Facilita el mantenimiento del software. El 80% del tiempo de vida y costo de un software está
en su mantenimiento.
● Mejoran la legibilidad del software. Lo cual permite a los ingenieros comprender el código
rápidamente.
● Un software es como cualquier otro producto, y por esta misma razón debes procurar que
como cualquier otro producto, este cumpla con los estándares de calidad adecuados.
La regla del Boy Scout
“Intenta dejar este mundo un poco mejor de como lo encontraste.”

Lord Robert Stephenson Smith Baden-Powell

“Siempre deja el lugar de acampamento más limpio que como lo

encontraste”

Robert C. Martin, autor del Libro Código Limpio

La regla del Boy Scout
“Deja el código mejor de cómo lo encontraste.”

● Esta idea principal nos indica que debemos ser colaboradores en el

instante de que tomamos parte del código.
● Si abres un archivo para revisarlo y ves que no está cumpliendo algunos
requisitos, no importa quién fue el autor original, toma un poco de tu
tiempo y la molestia de mejorarlo; agregando o borrando comentarios,
renombrando variables o funciones, formateando el código, etc.
¿Qué incluyen las convenciones?
Las convenciones de código incluyen:

● Organización de archivos
● Uso de sangría (Identación)
● Comentarios
● Declaraciones
● Convenciones de nombre
Organización de archivos
● Un archivo consta de secciones que deben ser separadas por líneas en
blanco y comentarios opcionales que identifiquen cada sección.
● Archivos con más de 2000 líneas son engorrosos y deben ser evitados.
● Los archivos fuente deberán tener el siguiente orden:
a. Comentarios de inicio
b. Sentencias de importación de paquetes
c. Declaración de clases y/o interfaces
Comentarios de inicio
● Todo código fuente debe tener comentarios de inicio que señale el
nombre de la clase, versión, y también una breve descripción del
propósito de la clase en el programa.

1. /*
2. * ClassName
3. *
4. * Version Alpha 0.0.12
5. *
6. * This class is...
7. *
8. */
Sentencias de importación de paquetes
● La primera línea no-comentario de un archivo de fuente es la sentencia
de package, posterior a esto, las sentencias de import.

1. package components
2.
3. import javax.swing.JFrame;
4. import javax.swing.JPanel;
Declaración de clases y/o interfaces
● Se divide en:
○ Comentario para documentar la clase o interface
○ La sentencia class o interface
○ Variables de clase:
■ Variables públicas (public)
■ Variables protegidas (protected)
■ Variables privadas (private)
○ Constructores
○ Métodos
Declaración de clases y/o interfaces
/**
* Clase Automovil
*
* Descripción
* @author marcelo
*/
public class Automovil {
public String Color;
protected int Capacidad;
protected String Traccion;
private int Altura;
private int Largo;

public Automovil() {
this.Color = "";
this.Capacidad = 0;
this.Traccion = "";
this.Altura = 0;
this.Largo = 0;
}

@Override
public String toString() {
return "Automovil{" + "Color=" + Color + ", Altura=" + Altura + ", Largo=" + Largo + '}';
}
}
Identación
● Se deben utilizar cuatro espacios por cada unidad de indentado. La
construcción exacta del indentado es de espacios no tabulaciones.
● Longitud de línea
○ Evitar más de 80 caracteres por línea, ya que no son bien manejados por muchas
terminales y herramientas.
● Ajustes de líneas
○ Cuando una expresión no quepa en una sola línea, debe ser cortada de acuerdo a los
siguientes principios:
■ Cortar después de una coma.
■ Cortar antes de un operador.
■ Alinear la nueva línea con la primera expresión del nivel anterior.
■ Si las reglas anteriores llevan a un código confuso, indente con 8 espacios después
de la primera línea.
Identación
Ejemplos:
myFunction(longExpression1, longExpression2, longExpression3,
longExpression4, longExpression5);

LongName1 = LongName2 * (longName3 + longName4 - longName5)

+ 4 * longName6;

private static void myMethodWithAVeryLongName (int arg1,

Object arg2, String arg3, int arg4, int arg5,
Object arg6) {
/*...*/
}
Identación
1. //No usar esta indentacion
2. if ((condition1 && condition2)
3. || (condition3 && condition4)
4. ||!(condition5 && condition6)) { // Malos cortes
5. doSomethingAboutIt(); // Hace esta linea facil de olvidar
6. }
7.
8. //Usar esta indentacion en su lugar
9. if ((condition1 && condition2)
10. || (condition3 && condition4)
11. ||!(condition5 && condition6)) {
12. doSomethingAboutIt();
13. }
14.
15. //O usar esta
16. if ((condition1 && condition2) || (condition3 && condition4)
17. ||!(condition5 && condition6)) {
18. doSomethingAboutIt();
19. }
Comentarios
● Los comentarios podrían ser usados para obtener descripciones del
código y proveer una información adicional que no es fácilmente
deducible con el propio código.
● Los comentarios deben contener sólo información que es relevante para
el lector y el entendimiento del programa.
● Por ejemplo, la información sobre el paquete correspondiente en que se
construye o el directorio en el que se encuentra el archivo no debe ser
parte de un comentario.
Formato de comentarios de implementación
Los programas pueden tener cuatro estilos de implementación de
comentarios: bloque, una línea, remolque y de fin de línea.

● Comentarios de bloque
○ Los comentarios de bloque son usados para la descripción de archivos, clases, métodos, y
estructuras de datos.

1. /*
2. * Here is a block comment.
3. */
Formato de comentarios de implementación
Los programas pueden tener cuatro estilos de implementación de
comentarios: bloque, una línea, remolque y de fin de línea.

● Comentarios de una sola línea

○ Comentarios cortos pueden ser incluidos en una sola línea indentados de tal manera que
se encuentre al mismo nivel del código que describen.

1. if (condition ) {
2. /* Handle the condition. */
3. …
4. }
Formato de comentarios de implementación
Los programas pueden tener cuatro estilos de implementación de
comentarios: bloque, una línea, remolque y de fin de línea.

● Comentarios de remolque
○ Comentarios muy cortos pueden aparecer en la misma línea del código que describen,
pero debe ser indentado de tal manera de que este se encuentre lejos del código.

1. if (a == 2) {
2. return TRUE; /* special case */
3. } else {
4. return isprime (a); /* works only for odd a */
5. }
Formato de comentarios de implementación
Los programas pueden tener cuatro estilos de implementación de
comentarios: bloque, una línea, remolque y de fin de línea.

● Comentarios de fin línea

○ El delimitador de comentarios // puede convertir en comentario una línea. Puede
comentar una línea completa o solo parte de ella.
1. if (foo > 1) {
2. // Do a double-flip.
3. }
4. else
5. return false; // Explain why here.
6.
7. //if (bar > 1) {
8. // // Do a triple-flip.
9. // …
10. //}
Formato de comentarios de implementación
Los programas pueden tener cuatro estilos de implementación de
comentarios: bloque, una línea, remolque y de fin de línea.

● Comentarios de documento
○ Los comentarios de documentado describen clases, interfaces, constructores, métodos y
archivos. Cada comentario de documentado es creado dentro de los delimitadores
/**...*/..
○ Son utilizados para los IDEs puedan interpretar la documentación del código: Descripción
de clases y paso de parámetros por ejemplo.

1. /**
2. * @param name the component name
3. * @return the component
4. */
Declaraciones
● Número de declaraciones por línea
○ Se recomienda una declaración por línea, ya que facilita la adición de comentarios.

Correcto:

1. int level; // indentation level

2. int size; // size of table

Incorrecto:

3. int level, size ;

Declaraciones
● Ubicación
○ No esperar a declarar variables antes de su primer uso. Excepcionalmente en el bucle for.

1. for (int i = 0; i < maxLoops; i++) {

2. /*...*/
3. }

○ Evitar declarar variables que tengan el mismo nombre que algún atributo de la clase que
la contiene.
1. private int count;
2.
3. public int counter(){
4. int count = 0;
5. /*...*/
6. }
Declaraciones
● Inicialización
○ Tratar de inicializar las variables locales o propiedades de clase

1. class Taxi extends Vehiculo {

2.
3. private String Licencia;
4. private String Conductor;
5.
6. Taxi(int licencia, int conductor) {
7. Licencia = licencia;
8. Conductor = conductor;
9. }
10. int emptyMethod() {}
11. /*...*/
12. }
Convenciones de nombre
● Muchas de las convenciones de nombre tienen como objetivo la correcta
"Capitalización" a la hora de declarar los nombres de paquetes, clases,
métodos, variables, constantes...
● Al utilizar la palabra "Capitalización" se intenta referir a la utilización de
mayúsculas y minúsculas a la hora de crear un nombre identificador para
los elementos anteriormente mencionados.
Convenciones de nombre
● Pascal case
○ Se refiere a utilizar mayúsculas en la inicial de cada palabra y el resto de las letras
tendrán que ser minúsculas sin excepción alguna.

1. public class MyClass {

2.
3. }
Convenciones de nombre
● Camel case
○ Se refiere a utilizar mayúsculas o minúsculas en la letra inicial de cada palabra.
■ Existen dos tipos: UpperCamelCase y lowerCamelCase.

1. public class Vehiculo {

2. private int NroChasis;
3. public setNroChasis (int nroChasis) {
4. this.NroChasis = nroChasis;
5. }
6. }
Convenciones de nombre
● Upper case
○ Se refiere a utilizar mayúsculas en todo el conjunto.
■ Se utiliza para definir constantes

1. final int MYCONSTANT = 2;

Convenciones de nombre
● Lower case
○ Se refiere a utilizar minúsculas en todo el conjunto.
■ Se utiliza para definir nombres de paquetes

1. package mypackage;
Convenciones de nombre
● snake_case
○ Se refiere a utilizar guiones bajos (_) para separar las palabras del nombre.
■ De uso muy común en Python.

1. def get_my_class(arg1, arg2, arg3):