Estándar de codificación

Comentarios.
Debido a restricciones de tiempo o programadores entusiastas que desean resultados
inmediatos para su código, comentar el código a menudo queda atrás. Los programadores
que trabajan en equipo han encontrado que es mejor dejar comentarios, ya que la
codificación generalmente sigue los ciclos, o más de una persona puede trabajar en un
módulo en particular. Sin embargo, algunos comentarios pueden disminuir el costo de la
transferencia de conocimiento entre los desarrolladores que trabajan en el mismo módulo.
En los primeros días de la computación, una práctica de comentar fue dejar una breve
descripción de lo siguiente:
Nombre del módulo
Propósito del Módulo
Descripción del módulo
Autor original
Modificaciones
Autores que modificaron el código con una descripción de por qué se modificó.
La "descripción del módulo" debe ser lo más breve posible, pero sin sacrificar la claridad y
la exhaustividad.
Sin embargo, los dos últimos elementos han quedado obsoletos en gran medida por la
llegada de los sistemas de control de revisiones. Las modificaciones y su autoría se pueden
rastrear de forma confiable mediante el uso de dichas herramientas en lugar de mediante
comentarios.
Además, si se está utilizando una lógica complicada, es una buena práctica dejar un
"bloque" de comentarios cerca de esa parte para que otro programador pueda comprender
qué está sucediendo exactamente.
Las pruebas unitarias pueden ser otra forma de mostrar cómo se pretende utilizar el código.
Convenciones de nomenclatura o Naming conventions

El uso de convenciones de nomenclatura adecuadas se considera una buena práctica. A

veces los programadores tienden a usar X1, Y1, etc. como variables y se olvidan de
reemplazarlos con otros significativos, causando confusión.
Para evitar esta pérdida de tiempo, generalmente se considera una buena práctica usar
nombres descriptivos en el código, ya que se trata de datos reales.
Ejemplo: Una variable para tomar peso como un parámetro para un camión puede
denominarse TrkWeight o TruckWeightKilograms, siendo la TruckWeightKilograms la
más preferible, ya que es reconocible al instante.

Mantener el código simple

El código que escribe un programador debe ser simple. La lógica complicada para lograr
algo simple debe mantenerse al mínimo, ya que el código podría ser modificado por otro
programador en el futuro. La lógica que un programador implementó puede no tener
perfecto sentido para otro. Por lo tanto, siempre mantenga el código lo más simple posible.
Por ejemplo, considere estas líneas equivalentes de código C:

y
El primer enfoque, que se usa mucho más comúnmente es considerablemente más grande
que el tercero. En particular, consume 5 veces más espacio vertical de la pantalla (líneas) y
97 caracteres frente a 52 (aunque las herramientas de edición pueden reducir la diferencia
en la escritura real). Es discutible, sin embargo, que es "más simple". El primero tiene un
explícito if / then else, con un valor de retorno explícito obviamente conectado a cada uno;
Incluso un programador novato no debería tener dificultades para entenderlo. El segundo
simplemente descarta los tirantes, reduciendo el tamaño "vertical" a la mitad con pocos
cambios en la complejidad conceptual. En la mayoría de los idiomas, las declaraciones de
"devolución" también se podrían agregar a las líneas anteriores, llevando el tamaño
"vertical" a solo una línea más que la tercera forma.

Portabilidad
El código del programa no debe contener valores "literales" (literales) que se refieran a
parámetros ambientales, como rutas de archivos absolutas, nombres de archivos, nombres
de usuarios, nombres de host, direcciones IP, URL, puertos UDP / TCP. De lo contrario, la
aplicación no se ejecutará en un host que tenga un diseño diferente al previsto. Un
programador cuidadoso puede parametrizar dichas variables y configurarlas para el entorno
de alojamiento fuera de la aplicación propiamente dicha (por ejemplo, en archivos de
propiedades, en un servidor de aplicaciones o incluso en una base de datos). Compara el
mantra de un "único punto de definición" (SPOD).
Como extensión, los recursos como los archivos XML también deben contener variables en
lugar de valores literales, de lo contrario, la aplicación no será portátil a otro entorno sin
editar los archivos XML. Por ejemplo, con las aplicaciones J2EE que se ejecutan en un
servidor de aplicaciones, dichos parámetros ambientales se pueden definir en el alcance de
la JVM y la aplicación debe obtener los valores desde allí.

Directrices de construcción en breve

Una visión general de todo lo anterior:
Saber lo que el bloque de código debe realizar
Mantener las convenciones de nomenclatura que son uniformes en todo.
Indique una breve descripción de para qué es una variable (refiérase a comentar)
Corregir los errores a medida que se producen.
Mantenga su código simple
 CLASIFICACIÓN DE ERRORES.
Los errores en un programa o algoritmo se pueden clasificar en distintos tipos. Atendiendo
a los efectos que ocasionan se podría hablar de errores que impiden la ejecución de un
programa y errores que no impiden la ejecución de un programa. Atendiendo al momento
en que se producen podríamos hablar de errores de compilación y errores de ejecución. Lo
vemos en forma de esquemas:

Atendiendo a los efectos que ocasionan:

Atendiendo al momento en que se producen:

Cuando una vez tenemos escrito el código del programa y ordenamos su ejecución, se
produce una “lectura de interpretación” previa llamada compilación. Recordemos que el
ordenador no interpreta directamente las órdenes que le damos sino que necesita una
traducción. Si durante esa traducción se detecta un problema el programa no comienza a
ejecutarse. Lo más habitual es que se detecten fallos de sintaxis, ciertos procesos no válidos
e incluso errores lógicos tipo bucle infinito en algunas circunstancias. Si el programa no
compila estamos obligados a realizar las correcciones oportunas antes de poder ejecutarlo.
Durante la ejecución del programa pueden producirse errores previsibles porque se derivan
del código o imprevisibles por ser su origen externo (entradas incorrectas de usuario,
problemas con ficheros, etc.).
Un error de ejecución puede ser gestionado (vía detección o vía lógica) pero uno de
compilación no.
Atendiendo a la naturaleza del error los clasificaremos en:

Y según el tratamiento que reciben:

Por su facilidad de detección tendríamos:

Hay errores cuya clasificación no es sencilla. Por ejemplo, si al usuario se le pide un número entero durante la
ejecución del programa, pero introduce uno real, se puede producir un error de ejecución por proceso no
válido. Sin embargo, el trasfondo del error es lógico: el programa no está preparado para reaccionar ante una
situación que es posible. A estos errores los llamaremos errores de fondo lógico.