¿Existe una mejor estrategia que confiar en el compilador para detectar errores?

He estado programando en C y C ++ durante algún tiempo, aunque diría que estoy lejos de ser un experto. Durante algún tiempo, he estado usando varias estrategias para desarrollar mi código, como pruebas unitarias, diseño basado en pruebas, revisiones de código, etc.

Cuando escribí mis primeros programas en BASIC, escribí largos bloques antes de encontrar que no se ejecutarían y que era una pesadilla para depurar. Entonces aprendí a escribir un poco y luego probarlo.

En estos días, a menudo me encuentro escribiendo repetidamente un pequeño código y luego usando el compilador para encontrar todos los errores. Eso está bien si detecta un error tipográfico, pero cuando comienzas a ajustar los tipos de parámetros, etc. solo para compilarlo, puedes arruinar el diseño. También parece que el compilador se está arrastrando al proceso de diseño cuando solo debe usarse para verificar la sintaxis.

Aquí existe el peligro de depender demasiado del compilador para mejorar mis programas. ¿Hay mejores estrategias que esta?

Recuerdo vagamente hace algún tiempo un artículo sobre una compañía que desarrollaba un tipo de compilador de C donde un archivo de encabezado adicional también especificaba los prototipos. La idea era que las inconsistencias en la definición de API serían más fáciles de detectar si tuviera que definirlo dos veces de diferentes maneras.

No ajuste las cosas para que se compile. Ajusta las cosas para que sean correctas . Si fue "diseñado" para que los tipos de parámetros no coincidan, entonces el diseñador no tiene idea de lo que están haciendo.

Si no desea confiar en el compilador, mejore su conocimiento del idioma. Estudie la estructura de definiciones y declaraciones, y verifique lo que escribe en busca de errores antes de compilar. Y use revisiones de código.

Esa idea de prototipos adicionales suena mal. Si lo diseñas incorrectamente una vez, ¿qué impide que el segundo diseño se diseñe incorrectamente? Y al usar diferentes formatos / paradigmas / etc. para la misma cosa, es probable que confundas a las personas. Me aseguraría de que todos entiendan el formato primario para que pueda concentrarse en hacer el diseño correcto la primera vez, en lugar de duplicar el trabajo de diseño para detectar errores. Como todo lo demás, los diseños deben ser refactorizados, pero no creo que hacerlo dos veces tenga mucho sentido.

Honestamente, creo que tu objetivo SIEMPRE debe ser escribir un programa que se compile por primera vez. Me doy cuenta de que esto es difícil y probablemente no sucederá con frecuencia, pero aún así debería ser su objetivo. Piense en el software como una pieza de hardware. Hazte creer que es poco costoso recompilar tu código (como refabricar una placa). Un cumplidor no es un depurador y no debe tratarse como tal.

El compilador no puede encontrar todos los errores, por lo que no tiene sentido fingir que sí. Todo lo que puede encontrar son los errores de sintaxis y los errores tipográficos. Es lo suficientemente bueno para eso que lo dejo hacer esa parte del trabajo (aunque en estos días el entorno atrapa el 99% de los mismos antes de que llegue a compilar), pero sé perfectamente que no son todos los errores.

La única vez que confío en ese tipo de información para decirme qué escribir es cuando recibo cosas como esta diciéndome que no puede convertir automáticamente un doble en flotante, si a dónde envía los datos espera flotantes (y desde lo que estoy haciendo actualmente es jugar con la biblioteca XNA que hace exactamente esto) y la fuente devuelve dobles (como es el caso de la biblioteca matemática C #), entonces simplemente tiene que convertir.

El compilador es una herramienta. Como con todas las herramientas, se puede abusar de ellas.

Cuando comienzas por primera vez con un lenguaje, no hay nada de malo en usar el compilador a ciegas para probar tu programa. Así es como funciona el aprendizaje, adivina y comprueba. Sin embargo, eso no significa que deba continuar codificando así.

Le conviene entender el idioma lo suficientemente bien como para poder compilar su programa en su cabeza. Entonces pasarás menos tiempo esperando que el compilador termine.

Digo que probablemente sea mejor que el programa esté siempre dentro de unas pocas líneas / bloques de código de compilación.

La mayoría de los IDE modernos detectan muchos problemas de compilación y creo que también me he vuelto bastante dependiente de esto.

¿Tal vez volver a los archivos de texto y compiladores de línea de comandos?