Comparado con la mayoría de las personas en este sitio, soy un novato. Quería obtener algunos consejos de los profesionales sobre cómo evitar cometer errores estúpidos en tu código.Dejar de pasar por alto detalles menores
¿Hay alguien más que tuvo el problema cuando estaban empezando por perder algunos detalles que causaban grandes problemas? ¿Hay algún hábito o comportamiento que te haya ayudado a superar esto?
Aquí es una lista de errores comunes, y/o sugerencias para evitarlos:
Peer revisión de código y pruebas unitarias. Solo la experiencia te ayudará a dejar de cometer los errores, pero estas cosas te ayudarán a aprender sobre los errores que estás cometiendo al principio.
Encontré escribir código o algoritmos en papel, o al menos en mi cabeza antes de comenzar a codificar. Hace que el problema sea un poco más claro en tu mente y no solo disparas y comienzas a codificar cuando quizás puedas cometer errores tontos y estar demasiado ansioso.
Como la mayoría de las otras habilidades adquiridas, la práctica hace al maestro. Sigue entrenando.
Todos cometemos errores estúpidos, porque somos humanos.
Soy un novato, pero he trabajado con varios profesionales experimentados que cometen los mismos errores tontos que yo hago. Estos son los errores que aprenderá y podrá corregir casi de inmediato.
Aparte de eso, lo mejor que puedo recomendar es buscar errores después de cada pequeño fragmento de código que se escribe. Se siente genial cuando puedes generar cientos de líneas de código por hora, pero pronto caerás cuando tengas mil errores y mil líneas para verificar.
Comentario bien.
Distribuya bien su código.
Tiene nombres de variables significativos.
Es como con todo lo demás que hará en la vida. Desde quemarse en la freidora de una tienda local de comida rápida hasta convertirse en emprendedor en su tercera startup.
Hacer errores, aprenden de ellos, y mejormismo - no los ignore.
Además, acepte que ocasionalmente cometerá el tonto error de vez en cuando, probablemente por el resto de su vida, y no se preocupe demasiado; solo asegúrese de vigilarlos, corregirlos cuando los vea, y su la experiencia crecerá para eventualmente minimizar su número y severidad. – Rob
Me parece que si me leído a través de los diferenciales sobre todo mi código justo antes de comprometerse a control de versiones, estoy casi garantizada encontrar algunos errores. Doble ese efecto (al menos) si tengo a alguien más revisando el código previo a la entrada.
Todavía soy bastante nuevo en el control de fuente, y todavía leo cuidadosamente todas las diferencias antes de comprometerme. Me he preguntado si esto no es realista, si inevitablemente me relajaré un poco a medida que me vaya acostumbrando. Me alegra saber que no estoy solo al encontrar que la práctica vale la pena. – harpo
Casi siempre reviso mis diferencias antes de registrar cualquier cosa, aunque eso es más para asegurarme de que escribiré un mensaje de registro preciso. Aún así, me ayudó a encontrar (y corregir) errores antes. –
Depende de su flujo de trabajo y sistema SCM/RCS/VCS. Utilizo Mercurial, un DVCS, así que hago muchos commits atómicos, quizás cada pocos minutos (normalmente trabajo en Python, así que eso sería un puñado de cambios), así que es realmente reciente qué cambios creo que he hecho. ¡Comprométase temprano, comprométase seguido! –
voy a añadir otro voto a "la práctica hace al maestro", pero con un ligero admendment:
perfecta práctica hace al maestro - un dicho relacionado es "la práctica hace permanente" por lo que en otras palabras, asegúrese de que lo estás practicando se ofrecen buenos hábitos de codificación que reducen los errores:
y así sucesivamente. También recomiendo echar un vistazo a los buenos proyectos de código abierto y ver cómo organizan y administran el código. Los buenos ejemplos son aún más importantes para aprender que los errores de otras personas :-)
El buen juicio proviene de la experiencia.
La experiencia proviene del mal juicio.
Esto puede sonar demasiado simplista, pero trato de seguir este mantra. Intento no cometer los mismos errores que he cometido antes.
Práctica - cuanto más código que escriba, más experiencia que ganará
la reutilización de código - código que se ha utilizado mucho es menos probable que contenga defectos
codificación defensiva - minimizar la creación de Código de riesgo, evite los efectos de borde
Pruebas: consulte la prueba de la unidad TDD (no pruebas unitarias tradicionales), que significa documentar el comportamiento esperado del código y crear el código que lo prueba. Más código significa más experiencia, más automatización, mayor confianza
Estás haciendo un buen comienzo, reconociendo que no lo tienes todo resuelto. Ninguno de nosotros lo hace.
Asegúrese de comprender el dominio, eso eliminará algunos errores de inmediato. Sepa lo que está resolviendo, y luego trate de desarrollar la solución.
Tienen un enfoque para el desarrollo. Utilizo un enfoque de prueba primero, pero no es la única manera.Eso me proporciona un comprobador incorporado que todavía estoy en curso. Utilizo mis compañeros para intercambiar ideas, he usado programación de pares antes y encontré valor en eso.
Si desarrolla un sistema para minimizar los errores "tontos", descubrirá que desaparecerán. Tal vez una lista de verificación funcionaría. El proceso de software personal fomenta ese enfoque. Pruébalo y ve si funciona.
Me gusta escribir mis ideas antes de comprometerlas con el código. Me gusta que mis compañeros me muestren por qué no tengo razón en mi forma de pensar primero. Si no pueden, estoy razonablemente seguro de haber eliminado algunos posibles obstáculos.
¡MUCHO de esto vendrá de la experiencia, esencialmente del tiempo haciendo lo que haces y aprendiendo de tus errores!
Me parece que si tengo algún problema en particular para tratar de solucionar un error o pensar en un problema, tomaré un respiro de 5 minutos. Para cuando tengo algo para beber o simplemente me relajo y vuelvo al problema, tiendo a estar más concentrado y menos estresado.
Generalmente, GRANDES errores provienen de bucear y escribir software antes de pensarlo. Yo empleo 2 programadores y esto es lo que insisto en que hagan. Eso hace una gran diferencia.
Dibuje la pantalla que está diseñando en papel y determine cómo funcionan las cosas tanto como sea posible antes de la codificación. Muéstralo a tu jefe/cliente/a otra persona. Explícaselo a ellos. Haz que lo critiquen.
Nunca empieces a escribir código hasta que lo hayas pensado como UML. No es necesario ser un experto en UML, pero los diagramas de clases, mostrando:
Hará una enorme diferencia al no pensar en absoluto.
Mantenga sus funciones pequeñas, nunca más de 30 líneas, a menudo menos. Esto lo ayudará a estructurar su código.
¡Siempre tenga la actitud "Keep It Simple" !! Tienes menos posibilidades de cometer errores si mantienes las cosas simples.
Evitar la tentación de empezar a escribir código antes de entender completamente el problema. Si solo comprende parte del problema, es probable que dedique tiempo a volver a trabajar el diseño más adelante. Obtenga la imagen más clara en su mente o en papel, luego comience a codificar.
O entérate bien hablando con alguien, preferiblemente mientras escribes y/o dibujas en una pizarra. –
Para mí, cuando miraba el código solía poner una especie de lista de cosas por hacer en un método que detallaba lo que tenía que hacer en cada etapa para completar el trabajo. Por ejemplo, si tuviera un método que era conseguir un nombre de clientes que escribiría algo así ..
cadena pública GetName (int custID) {
// Create local variables
// Get the connection string from the config file
// Create Try Catch Finally block
// Create SQL parameters
.... etc
}
no dejaría éstos en como comentarios, pero los eliminaría como hice la tarea. Ya no lo hago para ser honesto y dudo que tengas que hacerlo por mucho tiempo.
Además, recomendaría que si está tratando de aprender algo nuevo, haga un proyecto "real" y no solo ejemplos de un libro o sitio web (incluso si es solo una pequeña aplicación, hágalo funcionar) La lectura de un libro sobre el código no es un sustituto para quedarse atascado en.
Todos cometemos errores. Los genios son los que simplemente los mantienen en la tabla de cortar.
Practique, haga frecuentes revisiones de código (es decir, frecuente), mantenga un extenso historial de versiones y asegúrese de saber dónde encontrar a alguien que haya aprendido cómo mantener sus errores mejor ocultos.
Mi único consejo que no se ha mencionado ya, y eso me ayuda sobre una base regular, es la siguiente: antes Hago cualquier c significativa Hange, ya sea código o documentación, siempre tomaré un descanso de 10-15 minutos antes de finalizar el cambio. Por lo general, teniendo la pausa me deja volver refrescado y - más importante - no como invertidos en el cambio, y la mayoría de mis cosas planos se convierten salta a la vista a causa de ella. Esto suele ser más útil cuando eres la única persona que trabaja en algo; de lo contrario, puedes obtener una Revisión por pares que generalmente es superior.
herramientas de análisis estático son muy útiles. Findbugs también proporciona información sobre por qué ciertas prácticas son dañinas para sus programas.
Patrones - desarrollar o pedir prestado y los patrones de uso en su trabajo. Algunos patrones de ejemplo: el uso constante de los nombres de variables, la ubicación consistente para los contadores que se incrementan, la colocación consistente de los informes de errores, etc.
Un aspecto fundamental de la utilización de patrones es efectivamente su aspecto visual. Una mala práctica que me sorprende por su uso común es la colocación de llaves abiertas al final de una línea en lugar de al comienzo de la siguiente línea. Por ejemplo, esta es una buena práctica:
void MyMethod(String some_input)
{
if (some_input == null)
{
some_input = "";
}
}
El mismo método escrito para utilizar una práctica común, pero mal se vería así:
void MyMethod(String some_input) {
if (some_input == null) {
some_input = "";
}
}
Si hay un aparato ortopédico falta alguna parte, es mucho tiempo para encontrar ¡eso!
Creo que los patrones se refieren a patrones de diseño, no al estilo de codificación. –
Personalmente, si prefiero el estilo de extremo de línea debido a la compacidad adicional, sin embargo, reconozco que es más fácil de abusar que el nuevo estilo de línea. El final de línea requiere que el codificador se adhiera rigurosamente a un régimen de sangría, pero si eso puede garantizarse, es marginalmente más eficiente. IMHO YMMV :) – Cruachan
Solo porque no uses una práctica en particular, eso no significa que la práctica sea mala. –
La mayoría de las respuestas aquí son bastante general, pero hay una serie de cosas que se pueden hacer prácticas en el desarrollo de código para hacer menos probable errores. Precisamente, lo que son será diferente entre los idiomas, pero, por ejemplo, una fuente común de errores está bloqueada en las declaraciones: en muchos idiomas, para no insistir en el código del corchete si se trata de una sola línea, p.
if fred==bill dosomethingtofred() else dosomethingtobill();
Esto a menudo dará lugar a errores, especialmente si el código se edita posteriormente. Tampoco he puesto entre corchetes la prueba aquí, ya que de nuevo es permisible en algunos idiomas y es un generador potencial de errores.Yo lo haré siempre, sin excepción, estructure una declaración if en su totalidad distribuida en todo el linage, p.
if (fred==bill) {
dosomethingtobill();
}
else {
dosomethingtofred();
}
(nota personalmente prefiero extremo de la línea {. Algunas personas con buenos ojos en él y en un ambiente de cooperación es probable que sea mejor utilizar el nuevo estilo de línea, sin embargo, yo trabajo como consultor de la escritura principalmente código que se mantiene por mí mismo y me adhiero rigurosamente a las normas de sangrado, por lo que la compacidad adicional del código vale la pena)
Técnicas similares se pueden aplicar en la mayoría de los idiomas en una amplia gama de construcciones de código. Le sugiero que examine cuidadosamente dónde está cometiendo los estúpidos errores, luego considere qué estructuras de código le impedirían hacerlo y luego úselos cada vez más adelante. Yo mismo tengo una gama bastante amplia de estos constructos construidos durante varios años (para otro ejemplo, todos mis sql se presentan de la misma manera). Además de reducir errores estúpidos, esto también tiene la ventaja adicional de que puedo volver al código después de varios años y recuperar la funcionalidad muy rápidamente.
Haga todo lo posible para comprender sus errores. Escriba lo que salió mal, todo lo que intentó corregir el error y lo que finalmente funcionó. Utilizo este método para obligarme a reducir la velocidad y dejar de adivinar a ciegas. Si haces esto lo suficiente, desarrollarás un hábito de trabajo orientado a los detalles que debería disminuir tus errores.
Creo en una cosa simple.
Código una vez, código correcto.
Y para obtener eso (para mí de todos modos), necesito visualizar completamente el problema mentalmente antes de hacer cualquier cosa. Si no entiendo completamente un problema, dudo mucho de continuar.
Dicho esto, a veces hay que cruzar la línea, y solo ver qué pasa al otro lado sin saber.
No tenga miedo de hacer preguntas si no entiende algo. La mayoría de los errores más grandes que he visto han sido el resultado de alguien que no entiende el requisito a fondo y no hace más preguntas para asegurarse de que el programa está haciendo lo que se pretende. O alguien que usa el código que no entiende y no solicita una explicación y luego no entiende por qué no funcionará en sus circunstancias específicas. Luego hay personas que no entienden su modelo de datos lo suficientemente bien como para determinar si sus consultas arrojaron la respuesta correcta, no es suficiente para que se ejecute, necesita devolver los datos correctos. Una vez más, no hicieron preguntas para obtener una mejor comprensión. Me senté en las reuniones y observé a la gente asentir con la cabeza y estar de acuerdo con algo, y sabían que iban a hacer algo incorrecto solo por su lenguaje corporal. Pero es difícil ayudar a alguien que no admite que no entiende.
La experiencia es un escollo que debe evitarse? :-) Es posible que desee volver a escribir su primera oración. – tvanfosson
Modifiqué mi línea de apertura en su lugar. Gracias :) –
Gran lista, voto ++ – ConroyP