ser que programar programador programacion lenguaje empezar cuesta como buen aprender coding-style

coding-style - que - me cuesta programar



¿Cómo se ve un buen código de programador? (30)

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

El resto es guinda ...

Soy un programador aficionado (empecé con VBA para hacer que Excel sea 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 ¿a qué se parece "bien"? No soy un profesional, tengo muy poco para comparar. ¿Qué hace un mejor programador? Lo es:

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

Dicho de otra manera, si tuviera que mirar el código de un programador profesional, ¿qué es lo primero que notaria 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 en ese libro ''clase mundial''? ¿Es ese el pináculo? ¿Algún programador de cañón superior miraría ese código y pensaría que era un buen código?

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

Creo que el núcleo de la filosofía de un buen programador es que siempre piensa: "Estoy codificando para mí mismo en el futuro cuando ya me habrá olvidado 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. Trabajo (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 este código funciona. Esta es una combinación de documentación (javadoc es mi herramienta preferida), 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 explica que "este código funciona, así es como debería usarse, y es por eso que debería 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 abandona su escritorio).

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

  1. Obsesión por el formateo. Hay muchos IDEs, editores e impresoras bonitas que pueden formatear el código exactamente con las preferencias estándar o personales que considere apropiadas. Uso Netbeans, configuré las opciones de formato una vez y presioné 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 funcione.
  2. Obsesión por nombrar convenciones 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 que sea más difícil para la siguiente persona.
  3. Olvida que él trabaja en equipo con seres humanos reales.
  4. Olvídate de que la fuente principal de errores de codificación está sentado en su teclado en este momento. Si hay un error o un error, primero debe verse a sí mismo.
  5. Olvida que lo que se da la vuelta viene. Cualquier trabajo que haga ahora para hacer que su código sea más accesible para futuros lectores seguramente lo beneficiará directamente (porque ¿quién será la primera persona a la que se le pida que lea su código?).

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" sería útil también.

%

Citando a Fowler, resumiendo la legibilidad:

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

''nough dijo.

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 en un nivel competente:

  • Comentar correctamente
  • Estructura de manera eficiente
  • Documente limpiamente

Una vez escuché a un compañero de trabajo decir " Siempre he sido muy lógico y de mente racional. Creo que es por eso que me gusta desarrollarme "

Que en mi opinión, es la mente de un programador promedio. Uno que ve el mundo en términos de reglas y lógica y finalmente obedece esas reglas al diseñar y escribir un programa.

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

El buen código debe ser fácil de entender.
Debería ser bien comentado.
Las partes difíciles deberían ser mejor comentadas.

El 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.

El buen código es legible. No tendría problemas para entender lo que el código está haciendo en la primera lectura del código escrito por un buen programador profesional.

El código es poesía.

Comience desde este punto de la lógica y puede derivar muchas de las cualidades deseables del código. Lo que es más importante, observe que el código se lee mucho más de lo que está escrito, por lo tanto, escriba el código para el lector. Reescriba, renombre, edite y refactorice para el lector.

Un corolario de seguimiento:

El lector estará 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 monótonamente creciente de n. Un lector que mira su código por primera vez está indicado por n == infinito.

En otras palabras, cuanto mayor sea el intervalo de tiempo entre el momento en que escribió el código y el momento en que revisa el código, más apreciará sus esfuerzos por escribir para el lector. Además, cualquiera que le entregue su código obtendrá un gran beneficio del código escrito con el lector como la principal consideración.

Un segundo corolario:

El código escrito sin consideración para el lector puede ser innecesariamente difícil de entender o usar. Cuando la consideración del lector cae por debajo de cierto umbral, el lector obtiene menos valor del código que el valor obtenido al volver a escribir el código. Cuando esto ocurre, el código anterior se descarta 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.

El código es un reflejo de las habilidades y la mentalidad de un programador. Los buenos programadores siempre tienen un ojo puesto en el futuro: cómo funcionará el código cuando los requisitos o las circunstancias no sean exactamente lo que son hoy. ¿Qué tan escalada será? ¿Qué tan conveniente será cuando no soy el que mantiene este código? Cuán reutilizable será el código, de modo que alguien más que haga cosas similares pueda reutilizar el código y no volver a escribirlo. Qué sucede cuando alguien más intenta comprender 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 código base para un programador. Por lo tanto, un buen código es un reflejo de todos los estándares de la compañía y la calidad de su fuerza de trabajo.

El gran código para mí es algo que es simple de entender pero sofisticado. Las cosas que te hacen ir, "wow, por supuesto, ¿por qué no lo pensé de esa manera?". El 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 es aún más simple).

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

En mi opinión, un buen código de programador es independiente del idioma ; un código bien escrito se puede leer y comprender en un corto período de 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, un código bien escrito es comprensible para personas que ni siquiera programan en ese idioma en particular.

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

Por ejemplo, el otro día, estaba echando un vistazo al código de TinyMCE para responder una de las preguntas en . 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í, era bastante comprensible, y pude navegar a través del código en unos pocos minutos.

Un libro que me abrió los ojos en lo que respecta a la lectura del buen código del programador es Beautiful Code . Tiene muchos artículos escritos por autores de diversos 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 he programado en ese idioma en particular.

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

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

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

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

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.

He estado programando durante 28 años y me parece una pregunta difícil de responder. Para mí, un buen código es un paquete completo. El código está escrito limpiamente, con nombres significativos de variables y métodos. Tiene comentarios bien colocados que comentan la intención del código y no solo regurgitan el código que ya puede leer. El código hace lo que se supone que debe hacerse de manera eficiente, sin desperdiciar recursos. También debe escribirse con miras a la mantenibilidad.

La conclusión es que significa cosas diferentes para diferentes personas. Lo que podría etiquetar como un buen código que otra persona podría odiar. El buen código tendrá algunos rasgos comunes que creo que identifiqué anteriormente.

Lo mejor que puedes hacer es exponerte al código. Mira el código de otras personas. Los proyectos de código abierto son una buena fuente para eso. Encontrarás un buen código y un código incorrecto. Cuanto más lo mires, mejor reconocerás lo que determinas que es un buen código y un código incorrecto.

En última instancia, serás tu propio juez. Cuando encuentre estilos y técnicas que le gusten adoptarlos, con el tiempo creará su propio estilo y eso cambiará con el tiempo. No hay nadie aquí que pueda agitar una varita y decir qué es bueno y que cualquier otra cosa es mala.

Irónicamente, cuanto mejor sea el programador, menos indispensable se vuelve porque el código producido es mejor para cualquier persona (como lo expresa el consentimiento general de Eran Galperin).

Mi experiencia dice que lo opuesto también es verdad. Cuanto peor es el programador, más difícil es mantener su código, por lo que se vuelve más indispensable , ya que ningún otro alma puede entender los enigmas producidos.

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

Cuando se es mecanógrafo, siempre se necesita ser elegante en su trabajo, tener una estructura y una "gramática" adecuadas es muy importante. Ahora convertir esto a la "programación" -typing obtendría el mismo resultado.

Estructura

Comentarios

Regiones

Soy un ingeniero de software, lo que significa que durante mi educación he encontrado muchos idiomas diferentes, pero mi programación siempre "siento" lo mismo que mis escritos en fekberg.wordpress.com. Tengo una forma "especial" de escribir.

Ahora, programando diferentes aplicaciones y en diferentes idiomas, 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 su explicación de comentarios. Una región puede ser "Persona de clase" y dentro de esta Región tengo un par de métodos para propiedades, que puedo llamar "Métodos de acceso" o similares y cada propiedad y región tiene sus propios comentarios explicativos.

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

Piensa sobre esto. También lea mi artículo sobre Communication issues when adapting outsourcing que explica en forma aproximada qué tan malo puede ser el código, Enterpret como desee: http://fekberg.wordpress.com/2008/12/14/communication-issues-when-adapting-outsourcing/

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

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

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

  • El código bueno usa convenciones de nombres significativas para todos los objetos menos 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.

  • El buen código no es "inteligente". Hace las cosas de manera directa y obvia.

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

Todavía no lo he leído, pero el libro que planeo leer sobre este tema es Clean Code por Robert C. Martin.

Lo primero que notará es que su código sigue un coding-style consistente. Siempre escriben sus bloques de estructura de la misma manera, sangran religiosamente y comenten cuando sea apropiado.

Lo segundo que notaría 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 usan nombres de métodos de autodescripción y, en general, su código es muy legible.

La tercera cosa que notarías, después de que te equivocaste 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á un poco de conocimiento y experiencia en técnicas de diseño de software para comprender las elecciones específicas que tomaron al construir su arquitectura de código.

En cuanto a los libros, no he visto muchos libros donde 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 que no reflejan situaciones más complejas.

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

Personalmente, tendré que citar "The Zen of Python" de Tim Peters. Le dice a los programadores de Python cómo debería ser su código, pero me parece que se aplica básicamente a todo el código.

Hermoso es mejor que feo.
Explícito es mejor que implícito.
Simple es mejor que complejo.
Complejo es mejor que complicado.
Flat es mejor que anidado.
Sparse es mejor que denso.
La legibilidad cuenta
Los casos especiales no son lo suficientemente especiales como para romper las reglas.
Aunque la practicidad supera a la pureza.
Los errores nunca deberían pasar silenciosamente.
A menos que esté explícitamente silenciado.
En vista de la ambigüedad, rechace la tentación de adivinar.
Debería haber una, y preferiblemente solo una, forma obvia de hacerlo.
Aunque de esa manera puede no ser obvio al principio a menos que seas holandés.
Ahora es mejor que nunca.
Aunque nunca es a menudo mejor que 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 de eso!

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

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

En cuanto a si mirar libros, definitivamente diría que no en mi experiencia. Mire las API y los marcos, las convenciones de códigos y el código de otras personas y use sus propios instintos, y trate de 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 planear lo no planeado, que es de lo que trata la comprobación de errores. Esto solo vale la pena cuando alguien te envía un correo electrónico y dice: "Recibí el error 321" en lugar de "oye, la aplicación está rota, tú".

El buen código está escrito pensando en el futuro, tanto desde la perspectiva del programador como desde la perspectiva del usuario.

Tengo un buen ejemplo:

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

Un buen código es donde sabes lo que hace el método a partir del nombre. El código incorrecto es donde tienes que averiguar qué hace el código para dar sentido al nombre.

Un buen código es donde, si lo lees, puedes entender lo que está haciendo en poco tiempo de lo que lleva leerlo. El código malo es donde terminas buscándolo durante años tratando de resolver el problema.

El buen código tiene elementos nombrados de tal forma que hacen innecesarios los comentarios triviales.

El buen código tiende a ser corto.

El código bueno se puede reutilizar para hacer lo que hace en cualquier otro lugar, ya que no se basa en cosas que no están relacionadas con su propósito.

El buen código generalmente es un conjunto de herramientas simples para hacer trabajos simples (organizados de maneras bien organizadas para realizar trabajos más sofisticados). El código erróneo tiende a ser herramientas enormes de uso múltiple que son fáciles de romper y difíciles de usar.

[Respuesta puramente subjetiva]
Para mí, el 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 con todo esto es tan legible / ejecutable. La combinación de legibilidad, estructura (es decir, columnas, sangría, incluso nombres de variables de la misma longitud), color (nombres de clase, nombres de variables, comentarios, etc.) hacen que todo lo que me gusta sea una imagen "hermosa" que pueda hazme muy orgulloso o muy detestable de mi propio código.

(Como dije antes, respuesta muy subjetiva. Perdón por mi inglés).

  • El mejor código tiene una cierta elegancia que reconoces tan pronto como 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 ser tosco y estar listo.
  • Es consistente y se lee fácilmente.
  • Se divide en pequeñas funciones altamente cohesivas, cada una de las cuales hace una cosa y lo 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 tienen dependencias de abstracciones en lugar de implementaciones.
  • Fácil de leer
  • fácil de escribir
  • facil de mantener

todo lo demás es filigrana