¿Crees en las reglas de generalización del ‘código limpio’ que la gente siempre comparte?

Answer 1

Absolutamente.

También prefiero un estilo que sea más fácil de acordar, imponer e interactuar con uno que sea perfecto. En Python, que es fácilmente Pep 8. No es que realmente me interesen algunos de los matices de Pep 8. Me importa mucho más que tantas herramientas diferentes de SDLC ya saben lo que es y pueden cambiar el comportamiento de manera progrática porque si lo hacen.

Por ejemplo, tox y pytest pueden rechazar el código que se envía para su publicación y que no lo sigue. Esto ayuda a alentar la base del código para que parezca que fue escrito por una sola persona. La mayoría de los editores de IDE / texto pueden alertar a un ingeniero si no colocaron el número correcto de espacios antes de un comentario o lo que sea, y sería trivial ajustarse a los nuevos estándares de los equipos.

La mayoría de las herramientas pueden hacer ajustes menores si, por ejemplo, el colectivo cree que el ancho de la columna del terminal 80 heredado es demasiado restrictivo y en su lugar desea un número diferente. Siempre y cuando esos cambios puedan ser absorbidos por la tubería que dice que el código pasa las pruebas y es consistente, está bien.

Answer 2

Absolutamente.

Notarás que incluso en mis respuestas de Quora, si hay un fragmento de código en C o C ++, colocaré la llave de apertura en la misma línea; si hay un fragmento de C #, la llave de apertura estará en la siguiente línea. En el primer caso me adhiero a K&R, en el segundo me adhiero a la guía de estilo C # de Microsoft.

También notará que en mi texto normal, pongo un espacio después de la coma, escribiré con mayúscula la primera letra de la oración y terminaré con un punto, un signo de interrogación o un signo de exclamación (u, ocasionalmente, una cara sonriente: D ).

Estas dos cosas las hago por la misma razón: porque cuando uso las reglas de formato acordadas, hace que sea más fácil “analizar” para otras personas. Puedo ser un copo de nieve único de otras maneras, no necesito que mi formato sea único 😀

Answer 3

Creo que el peor mal en el desarrollo de software son los dogmas …

Los dogmas como el príncipe seco.

El siguiente mal peor en el desarrollo de software es:

No seguir el principio DRY.

😛

Por lo tanto, lo que quiero decir es que no los tomen como dogmas, son “solo”, sin duda, consejos útiles que pueden ser que no encajan bien con su proyecto por varias razones pero, por lo general, si trabaja con otros desarrolladores, vale la pena. .

Answer 4

Si tienes una razón para apartarte de los estilos sugeridos, hazlo. Tal vez invente su propio estilo desde cero. Pero ¿por qué repetir el trabajo ya hecho, a menos que haya una buena razón?

Answer 5

Porque en algún momento vas a escribir el código que alguien más tiene que leer. Me gusta pensar de esta manera. Necesito escribir mi código para que después de que me vaya de la empresa cuando llegue ese pasante y encuentre un error o simplemente intente entender lo que el programa está haciendo, ellos puedan. Y el buen estilo es útil para esto. Sin mencionar que a medida que los programas que escribes se hacen más y más grandes, tener cierto estilo te ayudará a entender lo que escribiste.

Si todo lo que vas a hacer es escribir cosas pequeñas que nadie más leerá, sigue adelante y haz lo que se sienta bien. Pero debes saber que si no te estás ayudando si alguna vez cambia esta situación.

Answer 6

Solía ​​escribir addons para MyBB. Tienen un estilo particular. Cuando estaba escribiendo un complemento, usaba su estilo, pero no era el mío, así que cuando escribo mi propio código (no para usarlo en su foro), vuelvo a escribirlo a mi manera. Ninguna de las dos formas es “correcta”, son diferentes (corchetes abiertos en la misma línea / corchetes abiertos en una línea por sí mismos, ese tipo de cosas).

Pasé los primeros años de mi vida de programación haciéndolo a mi manera (me convertí en ingeniero jefe del primer proyecto en el que trabajé poco después de ser contratado), así que, después de 39 años, solía hacerlo por mi cuenta. camino.