¿Cuáles son algunos buenos hábitos de programador con los que los principiantes pueden comenzar?

Answer 1

Ya se ha dicho innumerables veces, pero hacer que su código sea legible es claramente una de las primeras cosas que debe aprender. Utilizo algunas técnicas para lograr la máxima legibilidad:

• Tener algunas buenas convenciones de codificación.

1. Una función o un método debe comenzar con un verbo, el nombre de la función debe describir la acción. Por ejemplo, prefiera computeSpeedOfCar(…) lugar de speedOfCar(…) para no confundir una función con una variable. No temas ser verboso.
2. Los nombres de variables deben describir las cosas que tienen, no su tipo. Debe describirlo de manera que el lector pueda deducir fácilmente el tipo. Por ejemplo, para un vector de objetos de tipo Car, prefiera cars lugar de vcar .
3. El uso de guiones bajos ( camelCase o snake_case ) para separar las palabras en su función y nombres de variables depende de usted, pero solo elija algo y cúmplalo durante todo el proyecto.
4. Tener una buena manera de diferenciar miembros, variables y argumentos. Personalmente, trato los argumentos de la misma manera que las variables locales (porque dentro de la función no hay una diferencia real), y uso algo que puede diferenciar a los miembros, por ejemplo, un prefijo m_ en C ++, o un subrayado final. El subrayado final es bastante bueno porque facilita la finalización del código.
5. Sangría Si utiliza espacios o tabulaciones, el ancho de los mismos o la convención que utiliza para dar formato a su código, es irrelevante. Sólo apégate a ello. Si llegas a un equipo que ya lo tiene, apégate a él. En tus proyectos personales, prueba varios hasta que encuentres el más cómodo para ti. Pero siempre mantén lo mismo en todo tu proyecto.

• Tener un código bien documentado.

1. Escribir comentarios en el encabezado de la función. Debe mostrar el uso de la función, los significados de los argumentos, el valor de retorno, cualquier TODO s o FIXME s, las excepciones que pueden lanzarse y, si es posible, un ejemplo de uso.
2. Separa tu código en bloques lógicos. Deja líneas vacías. Escribir comentarios sobre bloques lógicos. Un truco para hacerlo correctamente al escribir una nueva función es escribir primero los pasos del algo en los comentarios, uno por línea. Luego, después de cada línea de comentario, escriba el código correspondiente.
3. Mantenga sus comentarios al día!
4. Siempre que necesite cambiar algo en una función, planifíquelo con cuidado: ¿ya se usa en algún lugar? ¿El cambio romperá algo en otra parte del programa? ¿Debo escribir una nueva función? ¿Debo agregar un argumento a la función para esa nueva característica? etc.
5. Escribe código para que sea autoexplicativo. Todos fallamos a veces al escribir comentarios. Si el código es lo suficientemente claro, la falta de comentarios no será tan mala y podrá agregarlos más tarde. Además, cuanto más legible sea el código, más fácil será depurarlo, mejorarlo y compartirlo con amigos o colegas.

Y algunos otros puntos:

• Usar control de fuente

Ya se ha dicho anteriormente, pero use control de código fuente. Git está en el aire, pero prepárate para cambiar a algo más poderoso (y / o más complicado) en los próximos años. Comencé con SourceSafe, luego CVS, luego SVN, luego GIT. No temas el cambio.

• Código simple

No es necesario hacer las cosas simples complicadas. Código sencillo. Mantenlo simple y estúpido (principio KISS). Si funciona sin errores, no es estúpido.

• La optimización temprana es la raíz de todo mal.

Hacer que las cosas funcionen. Si hay un problema en el rendimiento, cronometra tu código. Encuentra los cuellos de botella. Optimizar solo los cuellos de botella. Trate de mantenerlo legible. Explica las técnicas de optimización que usaste en los comentarios.

• Mantenerse humilde

Una buena cualidad de un buen programador es la humildad. Nunca se avergüence de llamar a un colega en busca de ayuda, es mucho mejor que quedarse atascado en su código durante horas. Además, si encuentra un error, verifique su código antes de culpar a sus colegas. Nunca calcule que su forma de pensar un algo es mejor que la de sus colegas. Discuta sobre esto, tal vez encuentre una solución que sea mucho mejor que cualquiera de sus propuestas. Después de todo, usar 2 o 3 cerebros generalmente conduce a mejores resultados que usar solo un cerebro.

• Siempre aprende cosas nuevas

Pruebe nuevas técnicas, nuevos idiomas, nuevos paradigmas, nuevas API, nuevas herramientas. Siempre. Un buen programador sabe cómo evolucionar y seguir el progreso. No te quedes con un idioma en particular. Ten una favorita, pero no la conviertas en una religión.

• Por último, si bien no menos importante

Se apasionado. Si no lo eres, nunca serás mejor que todos los programadores de COBOL que se sientan frente a su mainframe desde los años 50. No los culpo, deben hacer un montón de dinero. Pero si quieres ser un buen programador, el dinero no cuenta, así que sé apasionado. Y, tal vez, el éxito vendrá para que el dinero venga con su pasión.

Answer 2

HAGA QUE LEER SU CÓDIGO

Solía ​​estar muy metido en mí mismo y escribí un código increíblemente complejo sin pensar mucho en cómo lo presenté. Cuando volví a ese mismo código unos meses más tarde, no tenía idea de lo que estaba haciendo.

1) Nombre variables lógicamente

Aquí hay un programa que calcula la velocidad de un automóvil basándose en el tiempo que toma viajar entre dos puntos de control.

int a = 10;
int b = 20;
int c = 10;

int d = c / (ba);

imprimir (d);

Si bien las cosas le pueden parecer claras cuando escribe el código, puedo garantizarle que estará al menos ligeramente confundido cuando vuelva a leerlo en, por ejemplo, 2 o 3 meses. El código que aparece a continuación se ve mucho mejor, es mucho más fácil de depurar y le ahorrará dolores de cabeza y frustración si regresa después de mucho tiempo.

int startTime = 10;
int endTime = 20;
distancia int = 10;

int speed = distance / (endTime – startTime);

velocidad de impresión);

2) Confía en los comentarios, no en tu memoria.

Mismo principio de presentabilidad y olvido. Comente su código para que usted (y otras personas) sepan lo que está haciendo (por supuesto, generalmente no necesita ser tan innecesariamente detallado como lo he estado yo). Obviamente, si su código está escrito con 1) en mente, entonces podrá mantener los comentarios al mínimo, ya que su código ya se explica por sí mismo.

// ¡SPEED-O-MATIC!
// Calcula la velocidad del auto a partir del tiempo que toma viajar entre dos puntos y la distancia entre los puntos.

int startTime = 10;
int endTime = 20;
distancia int = 10;

int speed = distance / (endTime – startTime);

velocidad de impresión);

3) Aprender a usar el control de código fuente.

El control de fuente significa que si lo arruinas, puedes revertir las cosas a un momento en que funcionaron. También significa que puede colaborar con personas de todo el mundo con el mismo código. Esta es una habilidad muy útil, especialmente para los principiantes.

SourceTree es un muy buen punto de partida, ya que en realidad no hay mucha interacción con el terminal. También es gratis.

El amor de

tu mejor amigo peter

Answer 3

Mantendré el mío lo más corto posible, ya que estoy en la posición de ayudar a otro recién llegado. Estas no son cosas que he dominado en absoluto, ni mucho menos; en cambio estas son cosas que estoy aprendiendo yo mismo.

• Aprenda a codificar económicamente: “omitir palabras innecesarias” es la cita clásica para esto. Sin embargo, las palabras innecesarias también implican usar las que son necesarias. Para hacer esto, aprenda en profundidad qué ofrece su idioma elegido.
• Nombre sus variables, método, funciones y otras estructuras de tal manera que los comentarios no sean necesarios para explicar el código. Con la mejor voluntad del mundo, el compilador no revisa los comentarios, por lo que pueden quedar obsoletos muy rápidamente. Ver el punto en los mensajes de confirmación en su lugar.
• Aprenda a crear abstracciones adecuadas para hacer que su código sea más auto documentado. Kevlin Henney tiene conversaciones fantásticas sobre esta y otras ideas mucho más relevantes.
• No se repita: consejos atemporales y antiguos de varias fuentes (Code Complete 2, Pragmatic Programmer). El punto es que, si tiene una función o un conjunto de condiciones, requerido en más de un lugar, no las repita. Represéntelos en un solo lugar y le dará un lugar único para cambiar cuando lo necesite.
• Aprenda múltiples formas de pensar acerca de los problemas, desde lo pequeño a lo grande. Existen múltiples paradigmas de programación, formas de pensar: imperativo, orientado a objetos, funcional y muchos más. Estoy parafraseando a otros cuando sugiero que aprendan uno nuevo cada año.
• Divida sus métodos / funciones en pequeños y ordenados propósitos individuales con nombres claros.
• Me hago eco de las respuestas sobre el control de código fuente y agregaría algo más: si está aprendiendo solo, entre en GitHub lo más pronto posible. Github es una codificación social y tiene mucho que ofrecer además de que es un lugar excelente para guardar tus propios proyectos.
• Aprenda a documentar en cada confirmación: esto es diferente del comentario de código porque los mensajes de confirmación deben estar en línea con lo que cambió en esta versión.

No puedo enfatizar lo suficiente lo útil que es aprender a representar sus conceptos en la representación más simple posible. Leerás tu código muchas veces más que escribirlo. Así que escriba para el lector y sea alérgico a los nombres de funciones / variables que ocultan el significado de su propósito. Esto incluye cosas agradables como nombres de una sola letra o nombres con Obj, Str, Int al frente o al final, una práctica que viene de días pasados ​​donde los entornos eran menos amigables. Al menos para mí, una hoja de código llena de ObjName, ObjAge o StrName es difícil para la mente.

Omito un montón de posibles consejos porque, bueno, harías mucho mejor para leer Programación Pragmática y Código Completo 2 entre muchos otros.

Último artículo: entrar en la lectura. No solo los blogs, aunque a menudo son geniales, sino también libros sobre tu oficio. He conocido a muchos programadores que dicen que no leen, que no tienen tiempo para leer y demás. Me he sentido igual, pero periódicamente presiono para asegurarme de leer algo con la frecuencia suficiente como para ser útil; si no más, me ayuda a cuantificar la profundidad de lo que sé que no sé. Esa es una sensación útil: contrarresta el optimismo que es común a muchos programadores

Answer 4

Algunas cosas vienen a la mente:

1) aprenda a seudocodificar y diseñar procesos antes de comenzar a codificar. Haz un mapa de lo que planeas construir a un alto nivel. Veo a muchos desarrolladores, incluso de nivel superior, que simplemente saltan a la codificación antes de que realicen cualquier trabajo de diseño. ¿Lo que pasa? Unos días después, vuelven al tablero de dibujo para refactorizar cuando se dan cuenta de que no hicieron el trabajo de diseño por adelantado.

2) manejo de errores. Tu código fallará, y fallará a menudo. Cuanto más correctamente su código falle y proporcione comentarios útiles, mejor. En lugar de un simple “error de ruta no encontrada”, no estaría bien si su programa informara “No se encontró la ruta de acceso al registro”. ¿Se ha configurado correctamente el parámetro ERROR_LOG_PATH? ”

3) paso a través de su código en un depurador. El hecho de que su código produzca el resultado final correcto para su caso de uso particular no significa que esté haciendo exactamente lo que desea. Pasar a través de él línea por línea a veces puede ser esclarecedor “oh … ¿por qué está pasando ese bucle 6,000 veces en lugar de salir temprano como debería?”

¡Buena suerte!

Answer 5

Así que, como otros están diciendo …

Haga su código legible. Use la sangría adecuada, divida las líneas de código en bloques de código que comparten un propósito y comente los bloques de código. No coloque todo en una función o clase. Divida las cosas de tal manera que sean reutilizables y no escriban funciones y clases monolíticas que tengan decenas de miles de líneas. Y no copie el código de pegado. Si está haciendo algo más de una vez, escriba una función o una clase que resuma ese procedimiento o idea … siga el principio DRY. Por último, realice la comprobación de errores y proporcione contexto a sus mensajes de error. Nadie quiere leer un error que diga “Algo salió mal” o “¡Error!”.

Answer 6

• Tan pronto como aprenda a hacer algo, encuentre una mejor manera y luego intente automatizarlo.
• No se conforme con un lenguaje o una forma de codificación, se volverá obsoleto
• No busque reglas que den como resultado un buen código, busque un buen código para emular
• El mejor código es la expresión de intención más simple, pequeña y clara que satisface la necesidad; evite agregar opciones que no necesita y que probablemente no necesitará
• Cada nuevo lenguaje informático que aprenda le ayudará a escribir código en todos los demás idiomas. No dude en aprender un nuevo idioma. Deberá usar muchos a la vez para desarrollar cualquier tipo de software, a menos que desee estar atrapado en una capa. ‘hasta que salga de la moda
• No compile software exactamente según la especificación: la especificación es incompleta, engañosa e incorrecta; construir para que surja una aplicación que pueda satisfacer la especificación (piense en una especificación como una lista de capacidades, no en los resultados deseados)
• Si lo diseñas para que el usuario pueda hacer lo que necesita con las interacciones mínimas, tu código también estará al mínimo. Concéntrese en lo que el usuario quiere, no en lo que la computadora hace o hará
• Mire detrás de las abstracciones para ver lo que realmente está sucediendo, evite las abstracciones innecesarias si es posible, así como las capas, las asignaciones y las bibliotecas, sea sencillo y directo

Answer 7

Ya hay una serie de buenos comentarios. Repetiré algunas y luego agregaré una que no he visto todavía.

1. Utilice nombres de funciones y variables significativas.
2. No copie el código, use las funciones.
3. Usa los comentarios sabiamente. (Este es uno de los más difíciles de hacer bien.)
4. Usa control de fuente.
5. NO utilice “números mágicos”. Usa constantes en su lugar.

Voy a explicar esto. Tuve que mantener un programa heredado y me volví loco cuando me topé con cosas como esta (esto es un ejemplo inventado, pero entiendes la idea):

Opciones (5, 2)

El tipo que programó así tenía prisa y tenía todo tipo de números mágicos memorizados, así que no fue un problema para él. Ojalá hubiera hecho algo como esto:

(En un archivo global. En la parte superior del módulo o tal vez en un objeto de utilidad):

displayAsPicklist = 5

defaultNumberOfColumnsDisplayed = 2

y entonces el ejemplo sería:

Opciones (displayAsPicklist, defaultNumberOfColumnsDisplayed)

Answer 8

Ser coherente con el espaciado y la estructura.

Hace que su código sea más fácil de entender.

Dar variables y archivos de nombres lógicos.

Ser lindo y / o divertido es genial. Hasta que no intente explicar su código a alguien y no pueda recordar qué función deben hacer do_it () y función do_it_bettrr ().

Ve también a las reuniones en una tecnología en la que quieras mejorar.

Aprenderás mucho, harás amigos y te sorprenderás de lo que puedes aportar.

Muéstrale a la gente tu trabajo

Sepa que va a crecer como desarrollador y no tome personalmente las críticas constructivas.

No seas demasiado duro contigo mismo

Aprender a codificar es un proceso difícil. Algunas cosas vendrán más fáciles que otras y algunas parecerán mucho más difíciles al principio de lo que realmente son.

Los fracasos son una parte importante del proceso.

Elige un camino de aprendizaje y apégate a él

Decide qué tipo de codificación quieres hacer. Encuentra un currículum a seguir y apégate a él. Mi aprendizaje fue por todas partes mis primeros meses. Significativamente ralentizado mi crecimiento. En una nota similar,

No abandones los proyectos antes de que terminen.

Cuando se pone difícil es cuando puedes aprender más sobre ti mismo y tu oficio.

Answer 9

Muchas respuestas excelentes aquí. Me gustaría agregar un truco que he estado usando durante, 30 años. Cuando cree, abra o comience algo, escriba el código para destruirlo, ciérrelo o deténgalo a continuación. Luego escribe todas las cosas en el medio. Por ejemplo, en ningún lenguaje de codificación particular:

Archivo myFile = Files.open (“importantfile.txt”);
// TODO Use este archivo por la sección 1.2.3 de la especificación
myFile.close ();

O algo como esto:

Buffer myBuffer = Buffers.create (1024);
// TODO Usar este búfer
myBuffer.free ();

Una vez que tengas el principio y el final, vuelve y rellena el centro, donde está el TODO. Asegúrese de que TODO sea lo suficientemente claro acerca de lo que se debe hacer, para que otra persona pueda hacerse cargo de este código si es secuestrado por extraterrestres. Pero no puedo decirle cuántas horas incontables de tiempo de depuración he ahorrado al no tener que buscar fugas de memoria, ni abrir identificadores de archivos, ni conjuntos de conexiones con fugas, porque no hay ninguna en mi código.

Answer 10

Desde su primer programa, escriba de modo que el código explique qué está sucediendo y por qué a otro humano.

El punto de partida es una clara denominación de variables y funciones.

Tomemos un ejemplo simple. Digamos que su código es parte de un sistema de gestión de clientes:

Usted podría escribir

String string = “Mellor”;
función (cadena);

Y esto le dice a la computadora qué hacer bien. Está configurando una cadena a algún valor, y luego pasa eso a una función. El compilador tiene todo lo que necesita saber de usted.

Ahora me llamas para pedir ayuda. Y eso es todo lo que puedo ver. Una cuerda. ¿Para qué? Una función. ¿Haciendo qué?

Necesito saber esto. El compilador no lo hace. Y es por eso que nos disciplinamos para escribir código para los humanos.

En su lugar, codifíquelo así:

Apellido de la cadena = “Mellor”;

visualización (apellido);

Esto lee exactamente lo mismo que el compilador, pero me dice que el propósito de la cadena es que es un apellido. La función promete mostrar lo que le pasamos. Así que este código muestra un apellido. Lo entiendo.

(EDITAR: Se corrigió el error tipográfico detectado en los comentarios. Gracias)

Escriba su primer programa de esta manera, y pondrá toda su forma de pensar acerca de la programación en el camino correcto.

Answer 11

Necesitas aprender:

• Modifique su ciclo de sueño según lo requiera el proyecto.
• Regule su ingesta de alimentos, no por el bien de su peso, que también es importante, sino por una nutrición adecuada.
• Usando un juego de teclado / ratón / monitor / silla adecuado. Prepárate para desechar varios, antes de encontrar la combinación correcta. La ergonomía es más importante para los programadores que la mayoría de las personas, ya que tendemos a olvidar el tiempo.
• El trabajo en equipo, es importante, pero el vuelo en solitario es lo que rescata el día.

Answer 12

Este fue un comentario que hice, pero parece una respuesta válida

¡Usa funciones en lugar de comentarios!

carSpeed ​​(startTime, startTime, distance): velocidad {
distancia de retorno / (endTime – startTime)
}

Lo que significa entonces más tarde:

diffSpeed ​​= abs (carSpeed ​​(…) -carSpeed ​​(…))

Por supuesto, continuando así, ¡terminaría con `carDiffSpeed ​​/ 6`!

Es por eso que las estructuras y los objetos pueden ser útiles también 🙂

Posible buen código se ve así:

si machineReady (m) {
brewCofee ();
}más{
tareas = machineGetFixes (m)
askUser (tareas)
}

Pero lo que veo es:

si (Pin1 y 0x010 == 0x010) {
Pin1 | = 0x042; // Establecer los bits 1 y 6. BIT_START y BIT_READY (página 46)
}más{
para (; i; i- -) {
readReg (& buff, SENTINELLE, 4096) // Crea un búfer de 4k y el registro de lectura establece el bit para obtener más. Bloqueando
copyTarnsformStd (& buff, TY PE_BREW_TASK, true); // Escribe una versión convertida de búfer que represente tareas para arreglar brewer. No debe ser amortiguado
}
}

Incluso si eres un junior, los chicos a tu lado primero pensarán “qué noob, él hace una función para todo” y luego “¡Su código es muy fácil de entender, gran pieza!”.

Answer 13

No trates de ser listo, desperdicia tu tiempo más tarde. Hay un viejo proverbio que dice que la depuración es dos veces más difícil que codificar, de modo que si codificas algo de la manera más inteligente posible, por definición no serás lo suficientemente inteligente como para depurarlo. Esto suena como una broma pero realmente no lo es. Mantenga las cosas tan simples y legibles como pueda. Tengo un código que se ejecuta en cientos de sitios para clientes muy exigentes que ha combinado los tiempos de funcionamiento de 24 × 7 de muchas décadas solo porque mantengo las cosas lo más simples posible. Puede ir muy lejos con listas, colas, tablas hash y el árbol binario ocasional en el lado de la estructura de datos y si-luego-lo demás, ‘while’ y ‘for’ en el lado del flujo de control.

Answer 14

Para los novatos, creo que estos son fáciles de seguir y sin jerga técnica.

1. siempre sea coherente con sus sangrías para clasificar cada bloque de código juntos. Facilita la lectura de su código, por parte de futuros programadores.
2. Decide cuántos espacios representa cada pestaña y apégate a ella. Mi preferencia es tener 4 espacios para representar una pestaña. Cuando su código es largo y muchas personas están programando en el mismo código, es muy complicado tener una longitud de pestañas inconsistente entre todos los programadores.
3. Espacie sus códigos para que su programa parezca más fácil de leer. Nuevamente, cuando otra persona debe leer su código en el futuro, hace que leer su código sea menos frustrante.
4. Evite escribir códigos que no sean necesarios. Por ejemplo, no declare variables que no se usan en absoluto en el código. No importe bibliotecas / bibliotecas de terceros en su código que no se utilizarán. Una vez más, es confuso para alguien que busque su código en el futuro y se pregunte si estas bibliotecas no utilizadas afectarán su programa o no si se eliminan.
5. Para los programadores principiantes, es posible que no tenga experiencia en escribir códigos consulares, por lo que su codificación puede parecer larga. Siempre vuelva a leer su código para ver si puede limpiarlo más corto. Sin embargo, no intente ser demasiado inteligente para crear un código complicado, ya que los futuros programadores que manejan su código pueden no entenderlo rápidamente.

Mi consejo anterior es principalmente sobre la sostenibilidad del código. Lo que usted codifique ahora será respaldado y desarrollado por otra persona en el futuro. Así que siempre piensa en codificar responsablemente.

Answer 15

El hábito más importante del que lamento no adherirme antes sería leer la documentación de una herramienta o software en particular antes de saltar al código.

Por lo general, la documentación en un marco web o una biblioteca puede decirle exactamente lo que necesita saber, pero como principiante es fácil pasar por alto lo que está buscando y comenzar a sentirse perdido. Leer un poco de la documentación preliminar de inicio y explorar las clases y métodos relacionados puede ser de gran ayuda cuando comienza e incluso más tarde, si necesita algo más y ahora tiene una idea de si la biblioteca o la herramienta lo admite o dónde encontrarlo. .

Answer 16

Me gustaría añadir algunos:

1. Presta atención a los detalles (tanto como puedas). Confíe en las personas que saben lo que están haciendo mientras usan sus bibliotecas / tutoriales; Pero al mismo tiempo, no solo ten fe en ellos, ¡ plantea algunas dudas !
2. Pasa tiempo leyendo libros, especialmente filosofía 🙂
3. Piensa (todo) en funciones y formas de abstracción.

Answer 17

Si eres nuevo en el mundo de la programación, te recomiendo que comiences a aprender a tocar la escritura. Si aún no eres un tipógrafo, te hará codificar muy rápido … Puede parecer que no es tan importante como lo es en realidad, pero créeme, amigo mío, serás más productivo de lo habitual.

Y luego, si no sabes con qué lenguaje de programación, te sugiero que comiences a aprender Python, es un lenguaje de programación fácil orientado a objetos que te permitirá tener una idea concreta sobre este paradigma.

Que tengas un gran día.

Answer 18

Todas las grandes respuestas, como Gerente de Ingeniería para un equipo de IQ súper alto para un producto altamente visible, lo único en lo que siempre tenemos que trabajar es escribir códigos de prueba y pruebas de unidad. No utilizamos TDD, pero sí esperamos que los desarrolladores escriban pruebas unitarias, sorprendiendo a cuántos nos llegan con años de experiencia y sabemos poco sobre la cobertura adecuada de las pruebas.

Answer 19

Centrarse en las mejores prácticas. Siempre geek en estos y revisar sus conceptos básicos. Lo básico te ayuda a ser un muy buen programador. Simplemente no los descuides.