¿Soy un mal programador si tengo errores comunes (como falta de corchetes de cierre, función mal escrita, etc.) cada vez que escribo un nuevo código y tengo que arreglarlo?

Answer 1

No, no eres un mal programador, simplemente no aprendiste reglas comunes a las que se adhieren la mayoría de los programadores.

Una historia corta:

Cuando estaba aprendiendo, me sucedió todo eso, me volvía loco en ese entonces porque pasaba más tiempo arreglando mis errores de sintaxis que mi mala implementación de solucionar un problema. Estaba viendo un video en YouTube sobre HTML + CSS3 (no soy un desarrollador web, solo me gustaría aprender algunos conceptos básicos de las tecnologías diff), en ese video esta oración ” Tan pronto como abras cualquier tipo de soporte () {} [] siempre cierre de inmediato “se repitió como 15-20 veces. Él dice lo mismo cada vez que abre un soporte. Tengo esa frase guardada y cada vez que estoy codificando digo lo mismo en mi cabeza. Para errores ortográficos, siempre uso regiones (C #) o comentarios resumidos (Java) para recordarme los nombres de las funciones si tengo que usarlo más tarde, también el autocompletado me ayudará a escribir más rápido y recordarme lo que hace.

Algunas reglas comunes:

Cierre de soportes: siempre que abra un soporte, ciérrelo.

Nombres de funciones y lo que hace: comente lo suficiente, breve y claro lo que hace, esta es una buena práctica si está haciendo una biblioteca / dll / plugin / etc.

Divida el problema: muchos programadores no hacen esto, debe dividir el problema que está codificando en pequeñas piezas que, obviamente, arreglan lo que necesita. Ej: obtener el promedio de las calificaciones de un estudiante: 1 función para sumar, 1 para dividir la suma, 1 para recuperar esa información. No es exactamente la mejor práctica con este ejemplo, pero entiendes el punto.

Solo tome un poco de tiempo para corregir sus errores y luego continúe aprendiendo.

Saludos.

Answer 2

No significa que seas un mal programador, pero es algo que me preocuparía después de un tiempo, ya que indica que no estás aprendiendo de los errores. Todos cometen errores, pero los comportamientos comunes de sintaxis generalmente se corrigen con refuerzo negativo.

Si todavía está haciendo esto un año después de trabajar con el mismo idioma, puede indicar que tiene un problema. Puede ser disléxico o tener algún otro problema similar. Pero si está sucediendo por pereza y falta de voluntad para prestar atención a los detalles, es una gran señal de alerta.

Puede parecer entre 5 y 10 minutos, no es gran cosa, pero es un gran problema con el tiempo, ya que pierde el tiempo corrigiendo problemas que no deberían requerir corrección. Estás desacelerando tu velocidad de desarrollo sobre lo que yo consideraría comportamientos subconscientes. Si le faltan llaves y corchetes, ¿qué más le falta que podría ser importante? ¿Te gusta pensar que agregaste líneas de código en tu mente pero nunca lo hiciste en el teclado?

Hace muchos años, antes de que los IDE carecieran de inserción de llaves automáticas, tuve una verificación del desarrollador en un fragmento de código sin compilarlo primero como una verificación de cordura. Resulta que habían olvidado un punto y coma al final de una línea. No es gran cosa, ¿verdad? Bueno, esa falta de atención al detalle por la falta de ahorrar cinco minutos para hacer una verificación de compilación le costó a todo el proyecto medio día de pruebas perdidas.

Nuestro proyecto realizó compilaciones automatizadas en confirmaciones de código y había dos programadas por día que no pudimos cambiar. 6am y 1pm. Si hubo un cambio de código desde la última compilación, pasaría al siguiente ciclo programado. Pero una compilación que falló resultó en ninguna implementación y los evaluadores tuvieron que esperar hasta que se solucionó el problema y la próxima compilación. Todo el proceso estuvo fuera de nuestro control.

Nuestro equipo tenía una regla: “No rompas la construcción”. Puede enviar código con errores pero no rompa la compilación. El desarrollador, para un solo personaje y lo que pensaban que no era gran cosa, introdujo el código sin asegurarse de que al menos fuera edificable. Entonces, alrededor de 30 personas perdieron medio día esperando la próxima versión y explicando por qué a la gerencia que siempre estaba buscando informes de estado y quería saber por qué se detenían las pruebas.

Baste decir que el desarrollador antes mencionado nunca hizo un check-in sin supervisión nuevamente. Fueron degradados efectivamente sobre un punto y coma.

Eso fue en los viejos tiempos. Hoy, con IDEs modernos, lo que usted describe nunca debería suceder.

No rompas la construcción. Localmente o automatizado.

Answer 3

No, probablemente eres más como un desarrollador de Python, pero aún no lo sabes 🙂

Es broma, nadie puede decir que eres un mal desarrollador solo porque olvidaste poner algunos corchetes o algo similar. Esos no son los puntos clave que se pueden usar al definir a alguien como un buen desarrollador o no. Y más, esos son solo dolores de cabeza. En su mayoría, los nuevos IDE o las nuevas características de los IDE antiguos están cubriendo este problema con una advertencia o cierran automáticamente los corchetes abiertos (este es solo un ejemplo).

¿Por qué estás matando tu precioso tiempo con esta idea? En cambio, puedes hacer cosas más valiosas e importantes.

Por otro lado, creo que su problema es pensar rápidamente. Estás tratando de hacer tu trabajo lo antes posible, pero al hacerlo, te estás olvidando de algunas cosas menos importantes.

Si yo fuera usted, nunca pensaría que esto me está convirtiendo en un mal desarrollador o no, y me centraría profundamente en la lógica de mi programa.

Answer 4

Esta es mi opinión.
Aún no eres un mal programador, pero estás en camino de serlo. Hiciste un buen trabajo al descubrir “¿Cuáles son tus deficiencias?” . Ahora concéntrate en cómo solucionarlos.
Puede haber algunos cambios en su patrón de escritura (siempre escribo el corchete de apertura con el corchete de cierre, luego vuelvo y escribo el resto de la materia). Puede ser que pueda desarrollar un complemento para el editor que está utilizando, que señalará estos errores tan pronto como los hagas. Es posible que ya haya un complemento en su lugar. Nadie te está deteniendo para pasar a un editor diferente también.

Answer 5

Estás bien, todo el mundo hace “esto” (tiene un problema similar). Ayuda, quizás busque una herramienta de “código bonito” que pueda ayudarlo con sus problemas sintácticos más comunes.

Por cierto, ¿hay otras áreas en SW Dev que puedas contribuir y que te causen menos dolor (suponiendo que te estés castigando un poco por esto)? Hay muchas tareas que se requieren para desarrollar cualquier SW y especializarse en una parte en la que disfrutas y destacas, podría ayudarte a percibirte a ti mismo.

Este último punto me recuerda, bueno, a mí. Tengo un tipo de personalidad en el que soy extremadamente duro conmigo mismo y tiendo a revisar problemas (en mi mente) que no son problemas en absoluto. ¿Estás haciendo tu mejor trabajo? ¿Estás resolviendo problemas? ¿Podría el hecho de que usted sea duro con la sintaxis ser el resultado de lo mismo?

Los mejores deseos (de todos nosotros) …

Answer 6

No, pero necesitas un mejor editor de código. Ahora mismo.

Un buen editor de código o IDE debería poder corregir o resaltar errores menores, como paréntesis faltantes o errores ortográficos. Si su editor no admite esta función, simplemente bótela y busque una nueva. La vida es demasiado corta como para desperdiciarla en tonterías tan tontas.

Si no sabe por dónde empezar, pruebe Sublime Text o Atom. También necesitaría instalar complementos para los lenguajes de programación que elija. Dicha característica llamada “linter” o “autocompletar”, en caso de que no sepa qué palabra clave de búsqueda debe usarse.

Answer 7

Vamos, los errores sintácticos son comunes. No tiene que preocuparse por el nombre de la función mal escrita mientras llama.
Pero un pequeño corchete cambia toda la lógica y te golpearás la cabeza para descubrir dónde exactamente salieron las cosas mal.

Aunque ahora está tardando entre 5 y 10 minutos, pero si continúas con esto, te verás como un mal programador, que sabe cómo construir cosas pero no sabe cómo hacer una figura.

Answer 8

No, los errores tipográficos y perezosos no están relacionados con tus habilidades de programación reales. Claro, es una pena que pierda tiempo, pero ese es un problema diferente.