¿Cuáles son los consejos para escribir códigos que otros puedan entender fácilmente?

Answer 1

1. Asegúrese de entender el problema al menos antes de comenzar a escribir el código. Mejor si ya sabes cómo resolverlo antes de empezar a escribir.
2. Evita la complejidad innecesaria. Siga el principio KISS Principio KISS – Wikipedia Pero no simplifique demasiado. Está bien usar cualquier cosa con la que el desarrollador promedio esté familiarizado. Si tu equipo es muy hábil puedes subir el listón un poco.
3. Evite trucos y hacks sucios, si realmente necesitan agregar comentarios.
4. Elija nombres largos y significativos para variables, funciones, tipos, clases y archivos.
5. Utilice patrones de diseño conocidos: patrón de diseño de software – Wikipedia No reinvente la rueda.
6. Usa más funciones pero hazlas más cortas.
7. Evite copiar y pegar.
8. Ten un estilo consistente y síguelo. Si trabajas en equipo sigue el estándar de codificación del equipo. Siga las convenciones de codificación para su idioma.
9. Separe el código de alto y bajo nivel, mueva el código de bajo nivel a las funciones.
10. Usar mecanismos de abstracción, evitar abstracciones con fugas.
11. Pida a otros que revisen su código y expliquen sus decisiones.
12. Evite reescribir un código de trabajo solo porque está escrito por otra persona y tiene problemas para entenderlo. Pero refactorizar ese código puede ser una buena idea.
13. Evite la optimización prematura, primero el perfil para asegurarse de dónde está el cuello de botella.
14. Escriba mensajes de confirmación detallados y vincúlelos a tickets / problemas para que otros tengan más contexto si encuentran errores en su código.

Answer 2

Eso depende de muchas cosas, como el idioma que está utilizando. En general creo que los siguientes puntos son válidos:

• Codifique cuidadosamente, con sangría y líneas no largas. Escriba comentarios para facilitar la lectura del código, pero no exagere: 20 líneas de comentarios para una función de 7 líneas no mejoran nada.
• Evite los muros largos de código: ponga líneas que pertenezcan juntas en funciones / procedimientos / métodos / como lo llame su idioma. Estos f / p / m / w deben hacer una sola cosa ; Si descubres que uno de ellos está haciendo varias cosas, divídelo. Lo mismo ocurre con las clases si las usas.
• Use nombres sensibles, consistentes e informativos para variables, funciones, clases … Elija nombres cortos, pero intente evitar las abreviaturas (a menos que pertenezcan a una convención conocida). Ya sea que esté utilizando búsqueda de texto o ctags, los identificadores también son herramientas de navegación de códigos.
• No se repita (“SECO”): si se encuentra escribiendo la misma secuencia de líneas una y otra vez, intente hacer una función a partir de esa secuencia y llame a esa en cada lugar.
• Mantenga las cosas simples y claras: evite los trucos inteligentes a menos que mejoren significativamente el programa. Prefiere usar funciones de una biblioteca estándar a rodar su propio código.
• Si trabajas para una empresa que utiliza una guía de estilo, síguela religiosamente. Algunas de las reglas de estilo pueden ser dudosas, pero un estilo uniforme todavía ayuda enormemente.

Probablemente hay más.

Answer 3

Aquí hay algunos:

1. Borrar nombrar Esto es sorprendentemente difícil, pero nombrar variables, funciones y clases de manera apropiada es crítico. Si escribe var i = (j – c), está muy lejos de var price = (retailPrice – couponValue), por ejemplo. Hoy estuve revisando un código que alguien escribió que literalmente tenía este aspecto:

si ((j! = 0 && prev == 1 && im [i] [j] == 0) || (j == 0 && i-1> 0 && im [i-1] [j] == 1 && im [i] [j] == 0) || (i == 0 && j == 0 && im [i] [j] == 0)) {…

1. No hace falta que lo permitiera, no permití que se registrara. Este tipo de desorden muestra la falta de factorización de código adecuada y la falta de denominación adecuada. Es inigualable, difícil de probar y difícil de entender.
2. Una sola responsabilidad . Cada clase debe tener una sola responsabilidad. Cada función debe tener una sola responsabilidad. Nuevamente, identificar una responsabilidad clara es difícil, pero si piensa que su código es un gran conjunto de transformaciones de datos y que cada transformación es una responsabilidad, entonces ese es un modelo inicial razonable. Puedo escribir libros enteros sobre cuántas veces he visto esto violado. Normalmente, recomiendo que las funciones no superen aproximadamente las 10 líneas de código y los objetos que no superen los 10 o 20 métodos. Más allá de eso y hay algo terriblemente mal.
3. Sencillez. Difícil, de nuevo. La gente malinterpreta la navaja de Occam, así que permítame poner la definición real en juego: “No multiplique las entidades innecesariamente”. Busque la solución con el menor número de piezas móviles.
4. Colaboración. Y esta es la mejor: solo trabaje con otras personas, busque revisiones de código y escuche con atención lo que se dice y lo que no se dice. Obedezca las convenciones y patrones en el código base existente. No refactorizar innecesariamente. Buscar el consenso y las opiniones disidentes.
5. Pruebas Y esta es la más importante: las pruebas son la mejor fuente de documentación, ya que muestran cómo usar el código y cuál es el comportamiento esperado. Una combinación de pruebas unitarias y pruebas de integración es tanto la mejor documentación como la mejor herramienta de control de calidad que puede tener.
6. Código de documentación . Aprenda a usar jsdoc / scaladoc / javadoc – cualquier herramienta de documentación de código que tenga. Documentar las funciones correctamente. ¡Ponga los comentarios del código en todas partes, especialmente cuando se tomaron decisiones de diseño! Documente la intención de cada clase e incluya referencias a cualquier artículo externo cuando los use, como discusiones de stackoverflow, artículos de la base de conocimientos, código de muestra, etc.

Answer 4

Comentar, comentar, comentar. Cuanto más documente su código, mejor será el tiempo que alguien tendrá con él.

1. Escriba encabezados en la parte superior de sus métodos / clases / función / etc que expliquen en general lo que hace, cuáles son los parámetros, cuál es el rendimiento. Esto permite que las personas utilicen sus funciones / clases / métodos sin tener que rastrear todo el código escrito para averiguar qué hace.
2. Utilice nombres de variables detallados. Nadie puede mirar a través de su código y ver una sola letra o acrónimo y entenderlo de inmediato. Si usa nombres de variables que describan con precisión lo que los está usando para que el código sea mucho más legible. (es decir, “contador” vs “i” “longitud” vs “l” …) Esto puede eliminar la necesidad de comentarios en línea alrededor de todas sus variables.
3. Comentario en línea nada ambiguo. Cuando está escribiendo un documento de algoritmo, qué partes del código están haciendo para ayudar a que el código sea más fácil de rastrear. (es decir, “recorre la matriz y actualiza todos los elementos en función del parámetro”) No es necesario alinear todas las líneas (cuenta ++; // esta línea actualiza la cuenta), sino las que no se pueden interpretar de inmediato.
4. Siga una convención de codificación. Independientemente de las convenciones que utilice su equipo, cúmplalas. Si tu equipo siempre lo hace.

función x () {
}

y lo hace

función x ()
{
}

habrá pelea

Documentar su código es una habilidad muy valiosa y tomará práctica, pero no solo mejorará las vidas de sus compañeros de trabajo, sino también de usted mismo, ya que tendrá que revisar su código en el futuro.

Answer 5

Sugiero leer los siguientes dos libros:

1. Los elementos del estilo de programación, 2ª edición: Brian W. Kernighan, PJ Plauger
2. Código de limpieza: un manual de Agile Software Craftsmanship 1, Robert C. Martin

Puede encontrar copias en PDF gratuitas en línea si no quiere pagarlas.

A2A

Answer 6

Algunos pensamientos al azar:

• Estudia las guías de estilo de codificación que existen para tu lenguaje de programación. Debes asegurarte de mantener los estilos (comúnmente aceptados) todo el tiempo.
• Estudia libros como “Clean Code” de Robert Martin. No una vez sino una vez por trimestre.
• Pregunte a sus compañeros sobre guías de estilo informales o explícitas / convenciones de codificación que consideren esenciales para su trabajo.
• Práctica práctica práctica. Lo ideal es que se una a un grupo de revisión de código que se centre en ese tema de “escritura de código legible”.

Answer 7

Comience con el uso de variables significativas y nombres de métodos. Y no me refiero solo a lo significativo para ti. Asegúrese de que alguien que nunca haya leído su código pueda decir inmediatamente lo que está sucediendo sin necesidad de saber nada más.

Luego elige la claridad sobre la concisión. Si hacer dos cosas en la misma línea hace que sea más difícil determinar qué está sucediendo en esa línea, entonces hágalo en dos líneas.

Y hacer métodos para el código que suceda repetidamente. No copie y pegue, por favor.

Y comunicarse con los demás, a menudo. Esto será de tremendo valor.