Professional Documents
Culture Documents
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.”
“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.”
“…El código limpio siempre parece que ha sido escrito por alguien a quien le
importa. No hay nada evidente que hacer para mejorarlo.”
● 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.”
● 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);
● 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.
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 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:
Incorrecto:
○ 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. 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.