<?xml version="1.0" encoding="utf-8"?>
<page xmlns="http://projectmallard.org/1.0/" xmlns:its="http://www.w3.org/2005/11/its" type="topic" id="writing-good-code" xml:lang="es">

  <info>
    <link type="guide" xref="index#general-guidelines"/>
    
    <credit type="author copyright">
      <name>Federico Mena-Quintero</name>
      <email its:translate="no">federico@gnome.org</email>
      <years>2013</years>
    </credit>
    <credit type="author copyright">
      <name>Miguel de Icaza</name>
      <email its:translate="no">miguel@gnome.org</email>
    </credit>
    <credit type="author copyright">
      <name>Morten Welinder</name>
      <email its:translate="no">mortenw@gnome.org</email>
    </credit>

    <include xmlns="http://www.w3.org/2001/XInclude" href="cc-by-sa-3-0.xml"/>

    <desc>El código bueno y legible conserva el proyecto mantenible</desc>
  
    <mal:credit xmlns:mal="http://projectmallard.org/1.0/" type="translator copyright">
      <mal:name>Daniel Mustieles</mal:name>
      <mal:email>daniel.mustieles@gmail.com</mal:email>
      <mal:years>2016</mal:years>
    </mal:credit>
  
    <mal:credit xmlns:mal="http://projectmallard.org/1.0/" type="translator copyright">
      <mal:name>Javier Mazorra</mal:name>
      <mal:email>mazi.debian@gmail.com</mal:email>
      <mal:years>2016</mal:years>
    </mal:credit>
  </info>

  <title>La importancia de escribir buen código</title>

  <p>GNOME es un proyecto de software libre muy ambicioso, y se compone de muchos paquetes de software que son más o menos independientes unos de otros. Una gran parte del trabajo en GNOME se hace mediante voluntarios: aunque hay muchas personas trabajando en GNOME a tiempo completo o a tiempo parcial, los voluntarios siguen constituyendo un gran porcentaje de nuestros colaboradores. Los programadores pueden ir y venir en cualquier momento y serán capaces de dedicar diferentes cantidades de tiempo al proyecto GNOME. Las responsabilidades de la gente del «mundo real» pueden cambiar, y esto se reflejará en la cantidad de tiempo que puedan dedicar a GNOME.</p>

  <p>El desarrollo de software lleva grandes cantidades de tiempo y de esfuerzo minucioso. Por este motivo la mayoría de los voluntarios a tiempo parcial no pueden comenzar grandes proyectos por sí mismos; es mucho más fácil y gratificante contribuir a proyectos existentes, ya que estos producen resultados que son visibles y utilizables inmediatamente.</p>

  <p>Por lo tanto, llegamos a la conclusión de que es muy importante para los proyectos existentes hacer lo más fácil posible a la gente contribuir en ellos. Una forma de hacer esto es asegurándose de que los programas son fáciles de leer, comprender, modificar y mantener.</p>

  <p>El código desordenado es difícil de leer, y la gente puede perder el interés si no puede descifrar qué trata de hacer. También es importante que los programadores puedan entender el código rápidamente para que puedan empezar a contribuir con correcciones de errores y mejoras en un período de tiempo corto. El código fuente es una forma de <em>comunicación</em>, y es más para la gente que para los ordenadores. Igual que a alguien no le gustaría leer una novela con errores ortográficos, mala gramática, y una puntuación descuidada, los programadores deberían esforzarse en escribir buen código que sea fácil de entender y modificar por otros.</p>

  <p>Las siguientes son algunas cualidades importantes de buen código:</p>

  <terms>
    <item>
      <title>Limpieza</title>
      <p>El código limpio es fácil de leer con el mínimo esfuerzo. Esto permite a la gente empezar a entenderlo fácilmente. Esto incluye el estilo de codificación en sí (el lugar de las llaves, la sangría, los nombres de variables), y el control del flujo real del código.</p>
    </item>

    <item>
      <title>Consistencia</title>
      <p>El código consistente hace fácil a la gente entender cómo funciona un programa. Cuando se lee código consistente, uno forma inconscientemente una serie de suposiciones y expectativas acerca de cómo funciona el código, por lo que es más fácil y más seguro realizar modificaciones en él. El código que <em>parece</em> el mismo en dos sitios debería <em>funcionar</em> igual, también.</p>
    </item>

    <item>
      <title>Extensible</title>
      <p>El código de propósito general es más fácil de reutilizar y modificar que el código muy específico con muchas suposiciones en codificación fija. Cuando alguien quiere añadir una nueva característica al programa, obviamente será más fácil hacerlo si el código se diseñó para ser extensible desde el principio. El código que no se escribió de esta manera puede llevar a la gente a tener que implementar hacks feos para añadir características.</p>
    </item>

    <item>
      <title>Corrección</title>
      <p>Finalmente, el código que está diseñado para ser correcto permite a la gente emplear menos tiempo preocupándose por errores, y más tiempo mejorando las características de un programa. Los usuarios también aprecian el código correcto, ya que a nadie le gusta el software que se rompe. El código que se escribe para la corrección y la seguridad (es decir, código que intenta explícitamente asegurar que el programa permanece en un estado consistente) previene muchas clases de errores tontos.</p>
    </item>
  </terms>

  <section id="book-references">
    <title>Referencias del libro</title>

    <list>
      <item><p><link href="http://www.cc2e.com">Code Complete</link>, por Steve McConnell.</p></item>
      <item><p><link href="http://martinfowler.com/books/refactoring.html"> Refactoring: Improving the Design of Existing Code </link>, por Martin Fowler.</p></item>
      <item><p><link href="http://en.wikipedia.org/wiki/Design_Patterns"> Design Patterns: Elements of Reusable Object-Oriented Software </link>, por Erich Gamma, Richard Helm, Ralph Johnson y John Vlissides.</p></item>
      <item><p><link href="http://astore.amazon.com/gnomestore-20/detail/020163385X"> Object-Oriented Design Heuristics </link>, por Arthur Riel.</p></item>
    </list>
  </section>
</page>