¿Cuáles son las mejores prácticas de programación y estándares de codificación independientes de los lenguajes de programación?

Algunas de las mejores prácticas de programación y estándares de codificación son las siguientes.

1. El código debe explicarse por sí mismo tanto como sea posible. Dé nombres significativos a sus funciones, variables y clases.
2. Comentarios apropiados, especialmente cuando su código involucra una lógica complicada. Evite comentar código donde la lógica es evidente. Mantenga los comentarios simples.
3. El código debe ser modular, reutilizable, ampliable, mantenible. Los desarrolladores profesionales deben recordar que no son los únicos que leen el código que han escrito.
4. Siga los conceptos de OOP estrictamente al codificar en lenguajes orientados a objetos.
5. Prueba de unidad siempre que sea posible.
6. Agregue los comentarios adecuados al ingresar su código en un sistema de control de revisión.
7. Evite parámetros de codificación rígida como números de puerto, cadenas de conexión de base de datos, etc.
8. Mantenga las convenciones de codificación de manera uniforme en todo el código.
9. Implemente patrones de diseño GOF siempre que sea posible.
10. Utilice las bibliotecas estándar existentes para funciones básicas como clasificación, comparaciones, búsqueda, funciones de fecha y hora, etc. en lugar de reinventar la rueda.

Las convenciones de nomenclatura, sangría de código, estándares de comentarios pueden variar de un idioma a otro. Para las convenciones de codificación Java, consulte

Convenciones de código para el lenguaje de programación Java: contenido

Comenzando con el OP ya observado, me gustaría mencionar algunos.

Comentarios: Esto se debate, aunque se usa con bastante frecuencia. Si bien algunos sostienen que todos los comentarios son mentiras (por ejemplo, la biblioteca Apache Thrift desaconseja enérgicamente los comentarios de código), creo que solo es aplicable cuando los comentarios intentan replantear QUÉ está haciendo un fragmento de código o cómo lo está haciendo. A veces se necesitan comentarios para dar un contexto de por qué un fragmento de código en particular está haciendo algo de la manera en que lo está haciendo. En un mundo Ideal, un desarrollador ya debería saberlo al comprender el resto del código, pero simplemente no es práctico en una base de código grande. Los comentarios pueden ser la diferencia entre pasar por 200 llamadas de método y leer los registros e inspeccionar las bases de datos v / sa lectura rápida a través del comentario.

Convención de nomenclatura: Aquí hay algo con las convenciones: cambian de vez en cuando y de un lugar a otro. Algunas personas odian la notación húngara, pero me han dicho que las están adoptando nuevamente recientemente. Sin embargo, siempre y cuando se adhiera al que se usa en el resto de la base de código, es bueno, pero tiene que ser consistente. También los nombres significativos son imprescindibles. Un método getTranDur () puede significar getTransactionDuration para usted, pero puede significar get TransitDuration () para otra persona.

Formato (incluye sangría): de nuevo, igual que las convenciones de nomenclatura. Apéguese al formato utilizado en el resto del código. Personalmente odio leer el código donde comienza un bloque en la misma línea que la instrucción de bloque, pero he tenido que usarlo porque todos los demás lo hicieron. Un problema que esto causa si no lo hace es que su formateador de código formateará el código que no ha escrito y luego, cuando lo registre en su repositorio, las cosas de las que no tiene idea se resaltarán con su nombre como el último editor. Ahórrate ese horror, por favor. Mientras que algunos complementos volverán a formatear el código al estándar del repositorio mientras realiza el check-in, pero personalmente no soy fanático de hacerlo.

Longitud del método: es posible que no tenga la licencia para cambiar el método de 2K líneas de largo que se escribió el año pasado, pero cada vez que tenga la oportunidad de convertir el código en un nuevo método, hágalo, por favor. Es mejor que su control fluya a través de 30 métodos bien escritos de 100 líneas cada uno que un método de 2000 líneas, aunque este último da la ilusión de ser menos detallado.

Longitud del archivo : Similar a los métodos, si uno de sus archivos de código fuente es demasiado largo (digamos 10000 líneas), entonces no está haciendo algo bien, incluso si los métodos tienen 100 líneas de largo.

Patrones de diseño: Úselos; Piensa en ellos. No todos los patrones de diseño pueden ser relevantes para su área de trabajo, pero cuáles son, apréndalos (y realmente no sabe cuáles no son para usted y cuáles son hasta que los estudie una vez, al menos). No reinventes la rueda. Tampoco use una rueda donde deba usarse una tapa de registro porque ‘encaja’ y evita que un hombre caiga en el registro.

Siga los modismos: si está utilizando la programación OO, haga OO puro. Si está haciendo programación funcional, vaya completa funcional. Mantén tu lenguaje lo más idiomático posible. eso hace que el código sea fácil de mantener y fácil de entender.

Además de todas las prácticas mencionadas por otros usuarios (¡buen trabajo, muchachos!), Hay algo que todo desarrollador debe recordar: la responsabilidad. No importa cuán experimentado sea y con cuántas personas trabaje, los conceptos básicos siguen siendo los mismos. Puede evaluar su trabajo con precisión. Se comunica bien con su equipo y no tiene miedo de admitir un error o dar retroalimentación a los demás. Estás jugando hacia el mismo objetivo y te enfocas en darle un valor al cliente en lugar de simplemente contar los compromisos. Si se pregunta de qué se trata el concepto de responsabilidad del desarrollador, aquí hay algunas palabras de un desarrollador senior experimentado que ha trabajado con personas de todo el mundo y tuvo la oportunidad de hacer algunas observaciones perspicaces: ¿Cómo ser un desarrollador responsable?

Siempre es bueno aprender y practicar la codificación. Ayuda a una persona a desarrollar habilidades.

A continuación se detallan algunos puntos para practicar en la programación:
1. Comentarios y documentación
Como es una tendencia común a olvidar, siempre es mejor tener un comentario para un ciclo o cualquier tarea compleja.
2. Sangría
Hace que el código se vea hermoso, simple y fácil de entender.
Puedes probar el script “Python”.
3. Si el código es complejo e implica repetición
Cree una subrutina y llame cuando sea necesario.
4. Tener consistencia en la convención de nomenclatura
Puedes nombrar Class en Camel Convention. AppStart; RunTimeCheck.
De manera similar para la subrutina: appstart; runtimecheck.
5. Separación del algoritmo del código.
Siempre es bueno tener una subrutina separada para el algoritmo en lugar de involucrar junto con los datos.

Hay un metaprincipio: mantenerlo simple y mantenerlo limpio. Es un lema en lugar de una práctica específica, pero señala el camino para un mejor diseño y un mejor código.