¿Cómo es el código de un buen programador? [cerrado]

Soy un programador aficionado (comencé con VBA para hacer sobresalir más rápido) y he estado trabajando con VB.NET / C # .NET y estoy tratando de aprender ADO.NET.

Una faceta de la programación que siempre me ha frustrado es ¿cómo se ve 'bueno'? No soy un profesional, así que tengo poco con qué compararme. ¿Qué hace a un mejor programador? Lo es:

• ¿Tienen una mejor comprensión de todos los objetos / clases / métodos en un idioma determinado?
• ¿Sus programas son más eficientes?
• El diseño de sus programas es mucho mejor en términos de mejor documentación, buena elección de nombres para funciones, etc.

Dicho de otra manera, si mirara el código de un programador profesional, ¿qué es lo primero que notaría sobre su código en relación con el mío? Por ejemplo, leo libros como 'Professional ASP.NET' de Wrox Press. ¿Son los ejemplos de código de ese libro de "clase mundial"? ¿Ese es el pináculo? ¿Alguno de los mejores programadores miraría ese código y pensaría que es un buen código?

La lista a continuación no es exhaustiva, pero estas son las cosas en las que pensé al considerar su pregunta.

• El buen código está bien organizado. Los datos y las operaciones de las clases encajan. No hay dependencias extrañas entre clases. No parece "espagueti".

• Los buenos comentarios de código explican por qué se hacen las cosas, no qué se hace. El código en sí explica lo que se hace. La necesidad de comentarios debe ser mínima.

• Un buen código utiliza convenciones de nomenclatura significativas para todos los objetos, excepto los más transitorios. el nombre de algo es informativo sobre cuándo y cómo usar el objeto.

• El buen código está bien probado. Las pruebas sirven como una especificación ejecutable del código y ejemplos de su uso.

• Un buen código no es "inteligente". Hace las cosas de forma sencilla y obvia.

• El buen código se desarrolla en unidades de cálculo pequeñas y fáciles de leer. Estas unidades se reutilizan en todo el código.

Aún no lo he leído, pero el libro que planeo leer sobre este tema es Código limpio de Robert C. Martin.

Lo primero que notará es que su código sigue un estilo de codificación consistente . Siempre escriben sus bloques de estructura de la misma manera, sangran religiosamente y comentan cuando es apropiado.

La segunda cosa que notará es que su código está segmentado en pequeños métodos / funciones que abarcan no más de un par de docenas de líneas como máximo. También utilizan nombres de métodos autodescriptivos y, en general, su código es muy legible.

La tercera cosa que notarías, después de jugar un poco con el código, es que la lógica es fácil de seguir, fácil de modificar y, por lo tanto, fácil de mantener.

Después de eso, necesitará algunos conocimientos y experiencia en técnicas de diseño de software para comprender las elecciones específicas que tomaron para construir su arquitectura de código.

Con respecto a los libros, no he visto muchos libros en los que el código pueda considerarse "de clase mundial". En los libros, tratan principalmente de presentar ejemplos simples, que pueden ser relevantes para resolver problemas muy simples, pero no reflejan situaciones más complejas.

Citando a Fowler, resumiendo la legibilidad:

Cualquier tonto puede escribir código que una computadora pueda entender.
Los buenos programadores escriben código que los humanos pueden entender.

Ya he dicho suficiente.

Personalmente, tendré que citar "El zen de Python" de Tim Peters. Les dice a los programadores de Python cómo debería verse su código, pero encuentro que se aplica básicamente a todo el código.

Lo bello es mejor que lo feo.
Explícito es mejor que implícito.
Lo simple es mejor que lo complejo.
Complejo es mejor que complicado.
Plano es mejor que anidado.
Es mejor escaso que denso.
La legibilidad cuenta.
Los casos especiales no son lo suficientemente especiales como para romper las reglas.
Aunque la practicidad vence a la pureza.
Los errores nunca deben pasar silenciosamente.
A menos que sea silenciado explícitamente.
Ante la ambigüedad, rechace la tentación de adivinar.
Debe haber una, y preferiblemente solo una, forma obvia de hacerlo.
Aunque esa forma puede no ser obvia al principio a menos que seas holandés.
Ahora es mejor que nunca.
Aunque nunca suele ser mejor quecorrecto ahora.
Si la implementación es difícil de explicar, es una mala idea.
Si la implementación es fácil de explicar, puede ser una buena idea.
Los espacios de nombres son una gran idea, ¡hagamos más!

El código es poesía.

Comience desde este punto de la lógica y podrá derivar muchas de las cualidades deseables del código. Lo más importante es observar que el código se lee mucho más de lo que se escribe, por lo tanto, escribe código para el lector. Reescribe, renombra, edita y refactoriza para el lector.

Un corolario de seguimiento:

El lector será usted en el momento n desde la fecha de creación del código. La recompensa de escribir código para el lector es una función creciente monótona de n. Un lector que mira su código por primera vez se indica mediante n == infinito.

En otras palabras, cuanto mayor sea el lapso de tiempo desde que escribió el código hasta que vuelva a visitarlo, más apreciará sus esfuerzos por escribir para el lector. Además, cualquier persona a quien le entregue su código obtendrá un gran beneficio del código escrito con el lector como consideración principal.

Un segundo corolario:

El código escrito sin consideración por el lector puede ser innecesariamente difícil de entender o usar. Cuando la consideración para el lector cae por debajo de cierto umbral, el lector obtiene menos valor del código que el valor obtenido al reescribir el código. Cuando esto ocurre, el código anterior se desecha y, trágicamente, se repite mucho trabajo durante la reescritura.

Un tercer corolario:

Se sabe que el segundo corolario se repite varias veces en un círculo vicioso de código mal documentado seguido de reescrituras forzadas.

He estado programando durante 28 años y encuentro que esta es una pregunta difícil de responder. Para mí, un buen código es un paquete completo. El código está escrito de forma limpia, con nombres significativos de variables y métodos. Tiene comentarios bien ubicados que comentan la intención del código y no solo regurgita el código que ya puede leer. El código hace lo que se supone que debe hacer de manera eficiente, sin desperdiciar recursos. También debe escribirse teniendo en cuenta la facilidad de mantenimiento.

Sin embargo, la conclusión es que significa cosas diferentes para diferentes personas. Lo que podría etiquetar como buen código que alguien más podría odiar. Un buen código tendrá algunos rasgos comunes que creo que he identificado anteriormente.

Lo mejor que puede hacer es exponerse al código. Mira el código de otras personas. Los proyectos de código abierto son una buena fuente para eso. Encontrará código bueno y código malo. Cuanto más lo mire, mejor reconocerá lo que determina que es código bueno y código malo.

Al final, serás tu propio juez. Cuando encuentre estilos y técnicas que le gusten, adáptelos, con el tiempo se le ocurrirá su propio estilo y eso cambiará con el tiempo. No hay ninguna persona aquí que pueda agitar una varita y decir qué es bueno y que cualquier otra cosa es mala.

Lea el libro Código completo. Esto explica muchas ideas sobre cómo estructurar el código y las razones para hacerlo. Leerlo debería acortar su tiempo para adquirir la experiencia necesaria para distinguir el bien del mal.

http://www.amazon.com/Code-Complete-Practical-Handbook-Construction/dp/0735619670/ref=pd_bbs_sr_1?ie=UTF8&s=books&qid=1229267173&sr=8-1

Después de haber estado programando durante casi 10 años y haber trabajado con otros, puedo decir sin prejuicios que no hay diferencia entre un buen programador y un programador promedio.

Todos los programadores a un nivel competente:

• Comenta correctamente
• Estructurar de manera eficiente
• Documentar limpiamente

Una vez escuché a un compañero de trabajo decir " Siempre he sido muy lógico y racional. Creo que por eso disfruto desarrollar "

Eso, en mi opinión, es la mente de un programador medio. Alguien que ve el mundo en términos de reglas y lógica y, en última instancia, obedece esas reglas al diseñar y escribir un programa.

El programador experto comprende las reglas, pero también su contexto. En última instancia, esto los lleva a proponer nuevas ideas e implementaciones, la marca de un programador experto. La programación es, en última instancia, una forma de arte.

En pocas palabras, el código de un buen programador se puede leer y comprender.

En mi opinión, el código de un buen programador es independiente del lenguaje ; El código bien escrito se puede leer y comprender en poco tiempo con un pensamiento mínimo, independientemente del lenguaje de programación utilizado. Ya sea que el código esté en Java, Python, C ++ o Haskell, las personas que ni siquiera programan en ese lenguaje en particular pueden entender un código bien escrito.

Algunas características del código que es fácil de leer son, métodos que están bien nombrados, ausencia de "trucos" y "optimización" complicada, las clases están bien diseñadas, por nombrar algunas. Como han mencionado otros, el estilo de codificación es consistente, conciso y sencillo. .

Por ejemplo, el otro día, estaba mirando el código de TinyMCE para responder una de las preguntas sobre Stack Overflow. Está escrito en JavaScript, un lenguaje que apenas he usado. Sin embargo, debido al estilo de codificación y los comentarios que se incluyen, junto con la estructuración del código en sí, fue bastante comprensible y pude navegar a través del código en unos minutos.

Un libro que me abrió los ojos en lo que respecta a leer el código de un buen programador es Beautiful Code . Tiene muchos artículos escritos por autores de varios proyectos de programación en varios lenguajes de programación. Sin embargo, cuando lo leí, pude entender lo que el autor estaba escribiendo en su código a pesar de que nunca lo había programado en ese idioma en particular.

Quizás lo que debemos tener en cuenta es que la programación también tiene que ver con la comunicación, no solo con la computadora sino con las personas , por lo que un buen código de programador es casi como un libro bien escrito, que puede comunicar al lector las ideas que quiere transmitir. .

• Fácil de leer
• fácil de escribir
• facil de mantener

todo lo demás es filigrana

Un buen código debe entenderse fácilmente.
Debería estar bien comentado.
Las partes difíciles deberían comentarse aún mejor.

El buen código es legible. No tendrá problemas para comprender lo que hace el código en la primera lectura del código escrito por un buen programador profesional.

En lugar de repetir las excelentes sugerencias de todos los demás, te sugeriré que leas el libro Code Complete de Steve McConnell.

Esencialmente, es un libro repleto de mejores prácticas de programación tanto en funcionalidad como en estilo.

[Respuesta puramente subjetiva]
Para mí, un buen código es una forma de arte, como una pintura. Podría ir más allá y decir que en realidad es un dibujo que incluye caracteres, colores, "forma" o "estructura" de código, y que todo esto es tan legible / eficaz. La combinación de legibilidad, estructura (es decir, columnas, sangría, ¡incluso nombres de variables de la misma longitud!), Color (nombres de clases, nombres de variables, comentarios, etc.) hacen lo que me gusta ver como una imagen "hermosa" que puede hazme muy orgulloso o muy detestable de mi propio código.

(Como dije antes, una respuesta muy subjetiva. Lo siento por mi inglés).

Apoyo la recomendación del "Código limpio" de Bob Martin.

"Beautiful Code" fue muy aclamado hace un par de años.

Vale la pena leer cualquiera de los libros de McConnell.

Quizás "El programador pragmático" también sería útil.

%

Solo quería agregar mis 2 centavos ... los comentarios en su código, y su código en sí, en general, deberían decir lo que hace su código, ahora cómo lo hace. Una vez que tenga el concepto de código 'cliente', que es código que llama a otro código (el ejemplo más simple es código que llama a un método), siempre debería preocuparse más por hacer que su código sea comprensible desde la perspectiva del "cliente". A medida que su código crezca, verá que esto es ... eh, bueno.

Muchas otras cosas sobre el buen código tienen que ver con los saltos mentales que harás (definitivamente, si prestas atención) ... el 99% de ellos tienen que ver con hacer un poco más de trabajo ahora para ahorrarte una tonelada de trabajar más tarde y reutilización. Y también con hacer las cosas bien: casi siempre quiero correr al revés en lugar de usar expresiones regulares, pero cada vez que me meto en ellas, veo por qué todos las usan en todos los idiomas en los que trabajo (son abstrusos, pero funciona y probablemente no podría ser mejor).

En cuanto a si mirar libros, diría que definitivamente no en mi experiencia. Mire las API, los marcos de trabajo, las convenciones de código y el código de otras personas, use sus propios instintos e intente comprender por qué las cosas son como son y cuáles son las implicaciones de las cosas. Lo que el código en los libros casi nunca hace es planificar para lo no planificado, que es de lo que se trata la verificación de errores. Esto solo vale la pena cuando alguien le envía un correo electrónico y dice: "Recibí el error 321" en lugar de "Oye, la aplicación no funciona".

El buen código se escribe pensando en el futuro, tanto desde la perspectiva del programador como desde la perspectiva del usuario.

Esto se responde bastante bien en el libro de Fowler, "Refactorización". Es la ausencia de todos los "olores" que describe a lo largo del libro.

No he visto 'ASP.NET profesional', pero me sorprendería que fuera mejor que OK. Vea esta pregunta para algunos libros con código realmente bueno. (Varía, por supuesto, pero la respuesta aceptada allí es difícil de superar).

Esto parece ser (debería ser) una pregunta frecuente. Recientemente, hay un artículo de ACM sobre código hermoso. Parece haber mucho énfasis en la facilidad de lectura / comprensión. Calificaría esto con "fácil de leer / entender por expertos en el dominio". Los programadores realmente buenos tienden a usar los mejores algoritmos (en lugar de los algoritmos O (n ^ 2) ingenuos y fáciles de entender) para cualquier problema dado, que podría ser difícil de seguir, si no está familiarizado con el algoritmo, incluso si lo bueno El programador da una referencia al algoritmo.

Nadie es perfecto, incluidos los buenos programadores, pero su código tiende a esforzarse por:

1. Corrección y eficiencia con algoritmos probados (en lugar de trucos ingenuos y ad hoc)
2. Claridad (comentario de intención con referencia a algoritmos no triviales)
3. Completitud para cubrir los conceptos básicos (convención de codificación, control de versiones, documentación, pruebas unitarias, etc.)
4. Sucinto (seco)
5. Robustez (resistente a la entrada arbitraria y la interrupción de las solicitudes de cambio)

Secundo la recomendación del "código limpio" del tío Bob. pero es posible que desee echar un vistazo a http://www.amazon.com/Implementation-Patterns-Addison-Wesley-Signature-Kent/dp/0321413091 ya que creo que esto trata un poco mejor su pregunta específica. un buen código debería saltar de la página y decirle qué hace / cómo funciona.

Jeff Atwood escribió un buen artículo sobre cómo los codificadores son la primera referencia de mecanógrafos: http://www.codinghorror.com/blog/archives/001188.html

Al ser un mecanógrafo, siempre debe ser elegante en su trabajo, tener una estructura y una "gramática" adecuada es muy importante. Ahora, convertir esto a tipo "programación" obtendría el mismo resultado.

Estructura

Comentarios

Regiones

Soy un ingeniero de software, lo que significa que durante mi educación me he encontrado con muchos lenguajes diferentes, pero mi programación siempre "se siente" igual, al igual que mi escritura en fekberg.wordpress.com, tengo una forma "especial" de escribir.

Ahora programando diferentes aplicaciones y en diferentes lenguajes, como Java, C #, Assembler, C ++, C he llegado al "estándar" de escritura que me gusta.

Veo todo como "cajas" o regiones y cada región tiene sus comentarios explicativos. Una región puede ser "clase Persona" y dentro de esta Región tengo un par de métodos para las propiedades, que puedo llamar "Métodos de acceso" o algo así, y cada propiedad y región tiene su propio comentario explicativo.

Esto es muy importante, siempre veo el código que hago, como "ser parte de una API", cuando la creación de una estructura API y la elegancia es MUY importante.

Piensa sobre esto. Lea también mi artículo en el Communication issues when adapting outsourcingque se explica en forma aproximada cómo el código incorrecto puede entrar en conflicto, ingrese como desee: http://fekberg.wordpress.com/2008/12/14/communication-issues-when-adapting-outsourcing/

Un buen código es fácil de entender, fácil de mantener y fácil de agregar. Idealmente, también es lo más eficiente posible sin sacrificar otros indicadores.

Para mí, un gran código es algo simple de entender pero sofisticado. Las cosas que te hacen pensar, "wow, por supuesto, ¿por qué no lo pensé de esa manera?". Un código realmente bueno no es difícil de entender, simplemente resuelve el problema en cuestión de una manera directa (o de manera recursiva, si eso es aún más simple).

Un buen código es donde sabes qué hace el método por el nombre. El código incorrecto es donde tienes que averiguar qué hace el código para darle sentido al nombre.

Un buen código es donde, si lo lees, puedes entender lo que está haciendo en poco más tiempo del que se necesita para leerlo. El código incorrecto es donde terminas mirándolo durante años tratando de averiguar qué es lo que hace.

El buen código tiene cosas nombradas de tal manera que hacen innecesarios los comentarios triviales.

Un buen código tiende a ser corto.

El buen código se puede reutilizar para hacer lo que hace en cualquier otro lugar, ya que no depende de cosas que realmente no estén relacionadas con su propósito.

El buen código suele ser un conjunto de herramientas sencillas para realizar trabajos sencillos (reunidos de forma bien organizada para realizar trabajos más sofisticados). El código incorrecto tiende a ser enormes herramientas de usos múltiples que son fáciles de romper y difíciles de usar.

El código es un reflejo de las habilidades y la mentalidad de un programador. Los buenos programadores siempre tienen la mirada puesta en el futuro: cómo funcionará el código cuando los requisitos o las circunstancias no sean exactamente lo que son hoy. ¿Qué tan escalable será? ¿Qué tan conveniente será cuando no sea yo quien mantenga este código? Cuán reutilizable será el código, para que otra persona que haga cosas similares pueda reutilizar el código y no volver a escribirlo. ¿Qué sucede cuando alguien más está tratando de entender el código que he escrito?

Cuando un programador tiene esa mentalidad, todas las demás cosas encajan perfectamente.

Nota: Muchos programadores trabajan en una base de código a lo largo del tiempo y, por lo general, no hay una designación específica de base de código para un programador. Por lo tanto, un buen código es un reflejo de todos los estándares de la empresa y la calidad de su fuerza laboral.

(Uso "él" a continuación porque esta es la persona que aspiro a ser, a veces con éxito).

Creo que el núcleo de la filosofía de un buen programador es que siempre está pensando "Estoy programando para mí mismo en el futuro cuando me haya olvidado por completo de esta tarea, por qué estaba trabajando en ella, cuáles eran los riesgos e incluso cómo esto se suponía que el código funcionaba ".

Como tal, su código tiene que:

1. Trabaja (no importa qué tan rápido llegue el código a la respuesta incorrecta. No hay crédito parcial en el mundo real).
2. Explique cómo sabe que funciona este código. Esta es una combinación de documentación (javadoc es mi herramienta de elección), manejo de excepciones y código de prueba. En un sentido muy real, creo que, línea por línea, el código de prueba es más valioso que el código funcional si no es por otra razón que la que explica "este código funciona, así es como debe usarse y por eso debo obtener pagado."
3. Ser mantenido. El código muerto es una pesadilla. El mantenimiento del código heredado es una tarea ardua, pero debe hacerse (y recuerde, es "heredado" en el momento en que deja su escritorio).

Por otro lado, creo que el buen programador nunca debería hacer estas cosas:

1. Obsesionarse con el formato. Hay muchos IDE, editores e impresoras bonitas que pueden formatear el código exactamente según las preferencias estándar o personales que usted considere apropiadas. Utilizo Netbeans, configuro las opciones de formato una vez y presiono alt-shift-F de vez en cuando. Decide cómo quieres que se vea el código, configura tu entorno y deja que la herramienta haga el trabajo.
2. Obsesionarse con las convenciones de nombres a expensas de la comunicación humana. Si una convención de nomenclatura lo lleva por el camino de nombrar sus clases "IElephantProviderSupportAbstractManagerSupport" en lugar de "Zookeeper", cambie el estándar antes de hacerlo más difícil para la siguiente persona.
3. Olvídese de que trabaja en equipo con seres humanos reales.
4. Olvídese de que la fuente principal de errores de codificación está sentada en su teclado en este momento. Si hay un error o un error, primero debe mirar a sí mismo.
5. Olvídate de que lo que va, vuelve. Cualquier trabajo que haga ahora para hacer que su código sea más accesible para los futuros lectores, seguramente lo beneficiará directamente (porque ¿quién será la primera persona a la que se le pedirá que mire su código? Él es).

1. Funciona
2. Tiene pruebas unitarias que prueban que funciona

El resto es hielo ...

• El mejor código tiene una cierta elegancia que reconoces en cuanto lo ves.
• Parece elaborado, con cuidado y atención al detalle. Obviamente, se produce con alguien con habilidad y tiene un arte al respecto; se podría decir que se ve esculpido y pulido, en lugar de tosco y listo.
• Es consistente y se lee con facilidad.
• Está dividido en funciones pequeñas y altamente cohesivas, cada una de las cuales hace una cosa y la hace bien.
• Está mínimamente acoplado, lo que significa que las dependencias son pocas y están estrictamente controladas, generalmente por ...
• Las funciones y clases dependen de abstracciones en lugar de implementaciones.

Irónicamente, el mejor es el programador el menos indispensable que él / ella llega a ser porque el código producido es mejor mantenible por cualquier persona (como se indica por consenso general de Eran Galperin).

Mi experiencia dice que lo contrario también es cierto. El peor es el programador de la más difícil mantener su / su código es, por lo tanto más indispensable que él / ella se convierte, ya que ninguna otra alma puede comprender los enigmas producidos.

Tengo un buen ejemplo:

Lea el código fuente de GWT (google web takeit), verá que todos los tontos lo entienden (algunos libros en inglés son más difíciles de leer que este código).