Bien. Estoy escribiendo esto puramente basado en los trucos que he aprendido de los errores que he cometido repetidamente en el pasado.
- Siga los estándares de sangrado de codificación. Se ha estandarizado por una razón.
- Siempre haga comentarios al abrir y cerrar declaraciones de bucle que indiquen la condición. Por ejemplo: while (x.value == 1) {// comienza while bucle para x.value y similarmente, mientras que también lo cierra. Ej .:} // end while while loop para x.value
- Mantenga una sección de comentarios sobre cada función que tenga la lista de variables aprobadas: por valor o por referencia, tipo y valor de retorno, parámetros locales. Y probablemente una línea describiendo brevemente la funcionalidad.
- Si va a implementar cualquier funcionalidad dinámicamente, escriba cada parte del programa como programas modulares separados, pruébelas individualmente y luego integrarlos. La práctica de programación como esta también lo capacitará para escribir el flujo lógico de un programa en un formato más modular.
- Proporcione declaraciones de salida en cada hito definido en el programa para que sea más fácil depurarlo.
- Todo lo que se puede hacer recursivamente, a menudo también se puede hacer de manera iterativa. Siempre verifique ambas formas y elija la ruta que sería el mejor caso para su código.
- El lenguaje de programación es una elección propia. Pero sugeriría lenguajes orientados a objetos si uno está diseñando una manera de manipular bloques de datos. Por ejemplo: registros escolares, registros de oficina, etc. Y utilice lenguajes de procedimiento cuando se trata de diseñar un proceso o un flujo. Como, por ejemplo, el flujo de proceso de un empleado que solicita una licencia, el estudiante que calcula su promedio general acumulado, etc.
- Si su programa utiliza bucles que no sean de contador como While o do-while, es una mejor opción tener una variable que contará el número de ejecuciones del bucle mientras se realiza la prueba. Mi sugerencia: asigne variables con nombres genéricos como test_xx solo para pruebas y elimínelas todas una vez que se realicen las pruebas / depuración. Usualmente uso nombres como ‘test_index’ o ‘test_count’ mientras reviso el mío.
- Intente resolver problemas simples de programación directa todos los días, como un enigma, le sorprenderá la cantidad con la que acelerará la lluvia de ideas la próxima vez. Mi sugerencia: Armstrong, palíndromo (número y cuerda), trillizos pitagóricos, etc. son todos muy buenos programas de calentamiento que pueden abrir muchas ramas de pensamiento.
- Siempre, mientras prueba su programa, siga el siguiente orden:
- Valores seguros (que cumplen con todas las condiciones en su programa)
- Valores de borde – (Todas las combinaciones posibles una por una dependiendo de su programa)
- Casos base: para los cuales el flujo de programación puede ser diferente del que usted especificó.
¡Todo lo mejor! ¡Feliz codificación! 🙂