Esta sección también es realmente un requisito previo para codificar, como señala McConnell: «Establezca convenciones de programación antes de comenzar a programar. Es casi imposible cambiar el código para que coincida con ellos más tarde.»

Como se indica cerca del final de las convenciones de codificación, hay diferentes convenciones para diferentes lenguajes de programación, por lo que puede ser contraproducente aplicar las mismas convenciones en diferentes lenguajes. Es importante tener en cuenta que no existe una convención de codificación en particular para ningún lenguaje de programación. Cada organización tiene un estándar de codificación personalizado para cada tipo de proyecto de software. Por lo tanto, es imperativo que el programador elija o elabore un conjunto particular de directrices de codificación antes de que comience el proyecto de software. Algunas convenciones de codificación son genéricas que pueden no aplicarse a todos los proyectos de software escritos con un lenguaje de programación en particular.

El uso de convenciones de codificación es particularmente importante cuando un proyecto involucra a más de un programador (ha habido proyectos con miles de programadores). Es mucho más fácil para un programador leer código escrito por otra persona si todo el código sigue las mismas convenciones.

Para algunos ejemplos de convenciones de codificación defectuosas, Roedy Green proporciona un artículo largo (irónico) sobre cómo producir código inalcanzable.

Comentarioeditar

Debido a las restricciones de tiempo o a los programadores entusiastas que desean resultados inmediatos para su código, los comentarios del código a menudo pasan a un segundo plano. Los programadores que trabajan en equipo han encontrado que es mejor dejar comentarios, ya que la codificación generalmente sigue 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 desarrolladores que trabajan en el mismo módulo.

En los primeros días de la informática, una práctica de comentarios era dejar una breve descripción de lo siguiente:

1. Nombre del módulo
2. Propósito del módulo
3. Descripción del módulo
4. Autor original
5. Modificaciones
6. 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 claridad y exhaustividad.

Sin embargo, los dos últimos artículos han quedado obsoletos en gran medida por el advenimiento de los sistemas de control de revisiones. Las modificaciones y su autoría se pueden rastrear de manera confiable utilizando tales herramientas en lugar de usar comentarios.

Además, si se está utilizando lógica complicada, es una buena práctica dejar un «bloque» de comentario cerca de esa parte para que otro programador pueda entender qué está sucediendo exactamente.

Las pruebas unitarias pueden ser otra forma de mostrar cómo se pretende utilizar el código.

Convenciones de nomenclatura Edit

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 olvidarse de reemplazarlas por otras significativas, causando confusión.

Generalmente se considera una buena práctica el uso de nombres descriptivos.

Ejemplo: Una variable para tomar el peso como parámetro de un camión puede denominarse Trkweightkilograms o TruckWeightKilograms, siendo preferible la variable TruckWeightKilograms, ya que es reconocible al instante. Consulte Denominación de variables en camelCase.

Mantenga el código simpleeditar

El código que escribe un programador debe ser simple. La lógica complicada para lograr una cosa 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 implementa puede no tener perfecto sentido para otro. Por lo tanto, siempre mantenga el código lo más simple posible.

Por ejemplo, considere estas equivalente líneas de código en C:

if (hours < 24 && minutes < 60 && seconds < 60){ return true;}else{ return false;}

y

if (hours < 24 && minutes < 60 && seconds < 60) return true;else return false;

y

return hours < 24 && minutes < 60 && seconds < 60;

El 1 de enfoque, que es el más comúnmente utilizado, es considerablemente más grande que la 3ra. En particular, consume 5 veces más espacio vertical de 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 if/then else explícito, con un valor de retorno explícito obviamente conectado con cada uno; incluso un programador novato no debería tener dificultad para entenderlo. El segundo simplemente descarta los tirantes, cortando el tamaño «vertical» a la mitad con pocos cambios en la complejidad conceptual. En la mayoría de los idiomas, las instrucciones «return» también se pueden agregar a las líneas anteriores, lo que lleva el tamaño «vertical» a solo una línea más que la 3a forma.

La tercera forma obviamente minimiza el tamaño, pero puede aumentar la complejidad: Deja implícitos los valores «verdadero» y «falso», y mezcla las nociones de» condición «y»valor devuelto». Es probable que sea obvio para la mayoría de los programadores, pero un novato podría no entender inmediatamente que el resultado de evaluar una condición es en realidad un valor (de tipo booleano, o su equivalente en cualquier idioma), y por lo tanto puede ser manipulado o devuelto. En ejemplos más realistas, el 3er formulario podría tener problemas debido a la precedencia del operador, tal vez devolviendo un tipo inesperado, donde los formularios anteriores en algunos idiomas reportarían un error. Por lo tanto, la» simplicidad » no es simplemente una cuestión de longitud, sino de estructura lógica y conceptual; acortar el código puede hacerlo menos o más complejo.

Para programas grandes y de larga duración que utilizan alternativas detalladas podría contribuir a la hinchazón.

La compacidad permite a los programadores ver más código por página, lo que reduce los gestos de desplazamiento y las pulsaciones de teclas. Dada la cantidad de veces que se puede ver el código en el proceso de escritura y mantenimiento, puede suponer un ahorro significativo en las pulsaciones de teclas del programador en la vida útil del código. Esto puede no parecer significativo para un estudiante que aprende a programar por primera vez, pero, al producir y mantener programas grandes, la reducción de cuántas líneas de código hay permite que quepa más código en la pantalla, la simplificación de código menor puede mejorar la productividad y también disminuir la tensión en los dedos, las muñecas y los ojos, que son problemas médicos comunes que sufren los codificadores de producción y los trabajadores de la información.

La codificación Terser acelera la compilación muy ligeramente, ya que es necesario procesar menos símbolos. Además, el tercer enfoque puede permitir que líneas de código similares se comparen más fácilmente, particularmente cuando muchas de estas construcciones pueden aparecer en una pantalla al mismo tiempo.

Por último, los diseños muy cortos pueden utilizar mejor las pantallas de ordenador de pantalla panorámica modernas, dependiendo de la disposición y configuración del monitor. En el pasado, las pantallas se limitaban a 40 u 80 caracteres (tales límites se originaron mucho antes: manuscritos, libros impresos e incluso rollos, durante milenios han utilizado líneas bastante cortas (véase, por ejemplo, la Biblia de Gutenberg). Las pantallas modernas pueden mostrar fácilmente 200 o más caracteres, lo que permite líneas extremadamente largas. La mayoría de los estilos y estándares de codificación modernos no ocupan todo ese ancho. Por lo tanto, si se utiliza una ventana tan ancha como la pantalla, se desperdicia una gran cantidad de espacio disponible. Por otro lado, con múltiples ventanas, o utilizando un IDE u otra herramienta con información variada en paneles laterales, el ancho disponible para el código está en el rango familiar de los sistemas anteriores.

También vale la pena señalar que el sistema visual humano se ve muy afectado por la longitud de la línea; las líneas muy largas aumentan ligeramente la velocidad de lectura, pero reducen la comprensión y se suman a los errores de seguimiento ocular. Algunos estudios sugieren que a las líneas más largas les va mejor en línea que en la impresión, pero esto todavía solo llega a aproximadamente 10 pulgadas, y principalmente para la velocidad bruta de la prosa de lectura.

Portabilidadeditar

El código de programa no debe contener valores «rígidos» (literales) que se refieran a parámetros ambientales, como rutas de archivo absolutas, nombres de archivo, nombres de usuario, 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 tales 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). Compare el mantra de un»punto único 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 aplicaciones J2EE ejecutándose en un servidor de aplicaciones, estos parámetros ambientales se pueden definir en el ámbito de la JVM y la aplicación debe obtener los valores desde allí.

Escalabilidadeditar

Código de diseño con escalabilidad como objetivo de diseño porque muy a menudo en los proyectos de software, siempre se agregan nuevas características a un proyecto que se hace más grande. Por lo tanto, la facilidad de agregar nuevas características a una base de código de software se convierte en un método invaluable para escribir software

Reusabilidadeditar

La reutilización es un objetivo de diseño muy importante en el desarrollo de software. La reutilización reduce los costes de desarrollo y también reduce el tiempo de desarrollo si los componentes o módulos que se reutilizan ya están probados. Muy a menudo, los proyectos de software comienzan con una línea de base existente que contiene el proyecto en su versión anterior y, dependiendo del proyecto, muchos de los módulos y componentes de software existentes se reutilizan, lo que reduce el tiempo de desarrollo y prueba, lo que aumenta la probabilidad de entregar un proyecto de software a tiempo.

Directrices de construccióneditar

Una visión general de todo lo anterior: