{"id":5464,"date":"2018-08-02T13:55:51","date_gmt":"2018-08-02T18:55:51","guid":{"rendered":"https:\/\/islascruz.org\/blog\/?p=5464"},"modified":"2018-08-03T10:38:28","modified_gmt":"2018-08-03T15:38:28","slug":"documentando-codigo-en-python","status":"publish","type":"post","link":"https:\/\/islascruz.org\/blog\/2018\/08\/02\/documentando-codigo-en-python\/","title":{"rendered":"Documentando c\u00f3digo en Python"},"content":{"rendered":"<blockquote><p>Code is more often read than written<\/p>\n<p>&#8211; Guido Van Rosssum<\/p><\/blockquote>\n<p><!--more--><\/p>\n<p>El c\u00f3digo es mas veces le\u00eddo que escrito, por eso es importante documentarlo apropiadamente. Un c\u00f3digo bien documentado permite a quien recibe el c\u00f3digo saber que hace dicho pedazo de c\u00f3digo, sea una funci\u00f3n, una clase, modulo o paquete.<\/p>\n<p>Quien recibe el c\u00f3digo puede ser tal vez un compa\u00f1ero de trabajo, puede ser alguien que no conozcas en absoluto o puedes ser tu mismo dentro de unos cuantos meses.<\/p>\n<p><img loading=\"lazy\" decoding=\"async\" class=\"aligncenter size-medium wp-image-5465\" src=\"https:\/\/islascruz.org\/blog\/wp-content\/uploads\/2018\/08\/r_820413_wyzyE-300x295.jpg\" alt=\"r_820413_wyzyE\" width=\"300\" height=\"295\" srcset=\"https:\/\/islascruz.org\/blog\/wp-content\/uploads\/2018\/08\/r_820413_wyzyE-300x295.jpg 300w, https:\/\/islascruz.org\/blog\/wp-content\/uploads\/2018\/08\/r_820413_wyzyE-768x756.jpg 768w, https:\/\/islascruz.org\/blog\/wp-content\/uploads\/2018\/08\/r_820413_wyzyE-518x510.jpg 518w, https:\/\/islascruz.org\/blog\/wp-content\/uploads\/2018\/08\/r_820413_wyzyE-406x400.jpg 406w, https:\/\/islascruz.org\/blog\/wp-content\/uploads\/2018\/08\/r_820413_wyzyE-50x50.jpg 50w, https:\/\/islascruz.org\/blog\/wp-content\/uploads\/2018\/08\/r_820413_wyzyE.jpg 799w\" sizes=\"auto, (max-width: 300px) 100vw, 300px\" \/><\/p>\n<p>Estoy seguro que no te ser\u00e1 extra\u00f1a la vez que viste un c\u00f3digo y pensaste que est\u00e1 mal escrito, que hay cosas que le cambiar\u00edas y despu\u00e9s te das cuenta que fuiste tu quien lo escribi\u00f3.<\/p>\n<p>Si estas usando alg\u00fan m\u00f3dulo, te dar\u00e1s cuenta de lo importante que es la documentaci\u00f3n, buscar\u00e1s ejemplos, querr\u00e1s saber que par\u00e1metros y que tipos de datos recibe alguna funci\u00f3n, que clase debes extender para hacer tu trabajo mas sencillo. Si el paquete\/modulo que estas pretendiendo usar no est\u00e1 bien documentado es muy probable que desistas de usarlo.<\/p>\n<h3>Comentar vs Documentar<\/h3>\n<p>&#8220;Una cosa es una cosa y otra cosa es otra cosa&#8221;, antes de avanzar mas tenemos que entender la diferencia de las dos. En general <strong>comentar<\/strong> es describir tu c\u00f3digo, la audiencia esperada son otros desarrolladores encargados de mantener tu c\u00f3digo. Los comentarios ayudan al lector a entender que hace el c\u00f3digo.<\/p>\n<blockquote><p>El codigo te dice como; los comentarios te dicen por que.<\/p>\n<p>&#8211; Jeff Atwood (Coding Horror)<\/p><\/blockquote>\n<p><strong>Documentar<\/strong> es describir el uso y la funcionalidad \u00a0a los usuarios finales, desarrolladores tal vez, pero no son los encargados de mantener el c\u00f3digo, no necesitan ver el c\u00f3digo, necesitan usarlo.<\/p>\n<p>Para comentar el c\u00f3digo en Python usaremos el s\u00edmbolo de &#8220;gato&#8221; o &#8220;n\u00famero&#8221;<\/p>\n<pre>def hello_world():\n    # Un comentario precediendo a una llamada a print\n    print(\"Hello world\")<\/pre>\n<p>De acuerdo al PEP8 los comentarios deben tener m\u00e1ximo 72 caracteres. Pero si por alguna raz\u00f3n lo que tratas de explicar es demasiado largo entonces puedes usar m\u00faltiples lineas.<\/p>\n<pre>def hello_world():\n    # Esta es un comentario demasiado largo como para que \n    # entre en una sola linea, por eso lo ponemos en 2\n    print(\"Hello world\")<\/pre>\n<p>Comentar el c\u00f3digo tiene m\u00faltiples prop\u00f3sitos:<\/p>\n<ul>\n<li>Planear y revisar: cuando estas desarrollando nuevo c\u00f3digo te puede servir para que no olvides porque hiciste algo en una funci\u00f3n determinada, o que paso sigue despu\u00e9s de ejecutar cierto c\u00f3digo.<\/li>\n<\/ul>\n<pre># Paso 1\n# Paso 2\n# Paso 3<\/pre>\n<ul>\n<li>Describe el c\u00f3digo. Los comentarios pueden explicar la intenci\u00f3n de ciertas partes del c\u00f3digo.<\/li>\n<\/ul>\n<pre># Intento de conectarse usando las configuraciones previas,\u00a0\n# En caso de no poder, solicitar datos al usuario.<\/pre>\n<ul>\n<li>Descripci\u00f3n algoritmica. Puedes indicar por que usas cierto m\u00e9todo en lugar de otro, a veces es mejor legibilidad que rendimiento, a veces es mejor lo contrario.<\/li>\n<\/ul>\n<pre># Usando quick sort porque es mas r\u00e1pido.<\/pre>\n<ul>\n<li>Etiquetado: El uso de etiquetas para saber que debe corregirse, mejorarse en el c\u00f3digo es muy com\u00fan y buena pr\u00e1ctica.<\/li>\n<\/ul>\n<pre># TODO: Agregar condici\u00f3n cuando val es None<\/pre>\n<p>Algunas de las convenciones al escribir comentarios:<\/p>\n<ol>\n<li>Mant\u00e9n los comentarios lo mas cercano del c\u00f3digo que estas comentando<\/li>\n<li>No uses formato complicado, como tablas ASCII o figuras, es mejor el texto plano.<\/li>\n<li>No uses informaci\u00f3n redundante, asume que el lector tiene conocimientos b\u00e1sicos para entender el programa.<\/li>\n<li>Dise\u00f1a tu c\u00f3digo para que se &#8220;comente&#8221; a si mismo&#8221;, la forma mas f\u00e1cil de entender el c\u00f3digo es leerlo.<\/li>\n<\/ol>\n<h3>Documentando el c\u00f3digo<\/h3>\n<p>Ahora que ya sabemos que es comentar el c\u00f3digo, vamos a ver que es documentar el c\u00f3digo.<\/p>\n<p>Cada funci\u00f3n, m\u00e9todo o clase puede tener documentaci\u00f3n, en el caso de Python es una cadena de comillas simples, dobles o triples definida justo debajo del nombre de la funci\u00f3n\/m\u00e9todo o clase y tienen por nombre &#8220;docstrings&#8221;<\/p>\n<p>Este &#8220;docstring&#8221; es accesible v\u00eda la propiedad <code>__doc__<\/code>o usando la funci\u00f3n <code>help<\/code>en alguna clase.<\/p>\n<pre>&gt;&gt;&gt; help(str):\nHelp on class str in module __builtin__:\n\nclass str(basestring)\n| str(object='') -&gt; string\n|\n| Return a nice string representation of the object.\n| If the argument is a string, the return value is the same object.\n|\n| Method resolution order:\n| str\n<\/pre>\n<p>La documentaci\u00f3n provista por <code>help<\/code>\u00a0incluye las funciones y par\u00e1metros requeridos por cada una de ellas, proviene de la introspecci\u00f3n de dicha clase, el texto justo debajo de la definici\u00f3n de clase el la documentaci\u00f3n explicita en la propiedad <code>__doc__<\/code>y la podemos ver usando la funci\u00f3n <code>dir<\/code>:<\/p>\n<pre>&gt;&gt;&gt; dir(str)\n['__add__', '__class__', '__contains__', '__delattr__', '__doc__',<\/pre>\n<p>Entonces, lo podemos imprimir:<\/p>\n<pre>&gt;&gt;&gt; print(str.__doc__)\nstr(object='') -&gt; string\n\nReturn a nice string representation of the object.\nIf the argument is a string, the return value is the same object.<\/pre>\n<p>Dicha propiedad es inmutable en objetos dentro de <code>__builtins__<\/code> aunque puede ser modificado en otros objetos.<\/p>\n<h3>Tipos de docstrings.<\/h3>\n<p>Un docstring puede contener una o varias lineas, a diferencia de los comentarios que requieren el s\u00edmbolo de &#8220;gato&#8221; o &#8220;numero&#8221; aqu\u00ed, al ser una cadena, podemos usar la misma sintaxis que con las cadenas:<\/p>\n<pre>def func():\n    \"Docstring de una sola linea con comillas dobles\"\n\ndef func2():\n    'Docstring con comillas sencillas' \n\ndef func3():\n    \"\"\"Resumen\n    \n    Docstring con comillas triples, aqui como en las cadenas\n    puedo hacer uso de multiples lineas, asi puedo dar mejor\n    formato a la documentaci\u00f3n\"\"\"<\/pre>\n<p>Notaron que en el ultimo hay un &#8220;resumen&#8221; y un resto de comentario?. No es obligatorio, digo, no pasa nada sin no seguimos dicho formato, pero por convenci\u00f3n lo debemos hacer, la primera linea resume todo en una sola sentencia, despu\u00e9s podemos explicarnos.<\/p>\n<h3>Documentaci\u00f3n de Paquetes y M\u00f3dulos<\/h3>\n<p>Los paquetes y m\u00f3dulos tambien pueden tener documentaci\u00f3n, en el caso de los paquetes se escribe al principio del archivo <code>__init__.py<\/code> y en el caso de los m\u00f3dulos se escribe al principio de dicho m\u00f3dulo.<\/p>\n<p>De la misma forma que con el docstring de las funciones o clases, se pueden usar comillas simples, dobles o triples.<\/p>\n<h3>Finalizando<\/h3>\n<p>Comentar y documentar el c\u00f3digo debe ser regla de oro para cualquier desarrollador, tanto para hacer el c\u00f3digo mas f\u00e1cil de entender y usar para otros como para salvar el pellejo cuando algo no ande bien y quieres saber r\u00e1pido que fue lo que pretend\u00edas hace unos meses o a\u00f1os atras.<\/p>\n<p>Es f\u00e1cil y te sirve de mucho, incluso hay herramientas como <a href=\"http:\/\/www.sphinx-doc.org\/en\/master\/\" target=\"_blank\" rel=\"noopener\">sphynx<\/a>, que puede crear la documentaci\u00f3n de tus proyectos usando los docstrings y la introspecci\u00f3n del c\u00f3digo.<\/p>\n<p>[amazon_link asins=&#8217;1449355730,1449357016,9351198146,1449340377&#8242; template=&#8217;ProductCarousel&#8217; store=&#8217;launocom-20&#8242; marketplace=&#8217;MX&#8217; link_id=&#8217;aaf50b37-9686-11e8-ba7e-654ecae9cfb6&#8242;]<\/p>\n<hr \/>\n<p>Si te gust\u00f3 el articulo, comp\u00e1rtelo en tus redes sociales, si tienes algo que agregar con toda confianza hazlo en los comentarios.<\/p>\n<div class=\"pvc_clear\"><\/div>\n<p id=\"pvc_stats_5464\" class=\"pvc_stats all  \" data-element-id=\"5464\" style=\"\"><i class=\"pvc-stats-icon medium\" aria-hidden=\"true\"><svg aria-hidden=\"true\" focusable=\"false\" data-prefix=\"far\" data-icon=\"chart-bar\" role=\"img\" xmlns=\"http:\/\/www.w3.org\/2000\/svg\" viewBox=\"0 0 512 512\" class=\"svg-inline--fa fa-chart-bar fa-w-16 fa-2x\"><path fill=\"currentColor\" d=\"M396.8 352h22.4c6.4 0 12.8-6.4 12.8-12.8V108.8c0-6.4-6.4-12.8-12.8-12.8h-22.4c-6.4 0-12.8 6.4-12.8 12.8v230.4c0 6.4 6.4 12.8 12.8 12.8zm-192 0h22.4c6.4 0 12.8-6.4 12.8-12.8V140.8c0-6.4-6.4-12.8-12.8-12.8h-22.4c-6.4 0-12.8 6.4-12.8 12.8v198.4c0 6.4 6.4 12.8 12.8 12.8zm96 0h22.4c6.4 0 12.8-6.4 12.8-12.8V204.8c0-6.4-6.4-12.8-12.8-12.8h-22.4c-6.4 0-12.8 6.4-12.8 12.8v134.4c0 6.4 6.4 12.8 12.8 12.8zM496 400H48V80c0-8.84-7.16-16-16-16H16C7.16 64 0 71.16 0 80v336c0 17.67 14.33 32 32 32h464c8.84 0 16-7.16 16-16v-16c0-8.84-7.16-16-16-16zm-387.2-48h22.4c6.4 0 12.8-6.4 12.8-12.8v-70.4c0-6.4-6.4-12.8-12.8-12.8h-22.4c-6.4 0-12.8 6.4-12.8 12.8v70.4c0 6.4 6.4 12.8 12.8 12.8z\" class=\"\"><\/path><\/svg><\/i> <img loading=\"lazy\" decoding=\"async\" width=\"16\" height=\"16\" alt=\"Loading\" src=\"https:\/\/islascruz.org\/blog\/wp-content\/plugins\/page-views-count\/ajax-loader-2x.gif\" border=0 \/><\/p>\n<div class=\"pvc_clear\"><\/div>\n","protected":false},"excerpt":{"rendered":"<p>Code is more often read than written &#8211; Guido Van Rosssum<\/p>\n<div class=\"pvc_clear\"><\/div>\n<p id=\"pvc_stats_5464\" class=\"pvc_stats all  \" data-element-id=\"5464\" style=\"\"><i class=\"pvc-stats-icon medium\" aria-hidden=\"true\"><svg aria-hidden=\"true\" focusable=\"false\" data-prefix=\"far\" data-icon=\"chart-bar\" role=\"img\" xmlns=\"http:\/\/www.w3.org\/2000\/svg\" viewBox=\"0 0 512 512\" class=\"svg-inline--fa fa-chart-bar fa-w-16 fa-2x\"><path fill=\"currentColor\" d=\"M396.8 352h22.4c6.4 0 12.8-6.4 12.8-12.8V108.8c0-6.4-6.4-12.8-12.8-12.8h-22.4c-6.4 0-12.8 6.4-12.8 12.8v230.4c0 6.4 6.4 12.8 12.8 12.8zm-192 0h22.4c6.4 0 12.8-6.4 12.8-12.8V140.8c0-6.4-6.4-12.8-12.8-12.8h-22.4c-6.4 0-12.8 6.4-12.8 12.8v198.4c0 6.4 6.4 12.8 12.8 12.8zm96 0h22.4c6.4 0 12.8-6.4 12.8-12.8V204.8c0-6.4-6.4-12.8-12.8-12.8h-22.4c-6.4 0-12.8 6.4-12.8 12.8v134.4c0 6.4 6.4 12.8 12.8 12.8zM496 400H48V80c0-8.84-7.16-16-16-16H16C7.16 64 0 71.16 0 80v336c0 17.67 14.33 32 32 32h464c8.84 0 16-7.16 16-16v-16c0-8.84-7.16-16-16-16zm-387.2-48h22.4c6.4 0 12.8-6.4 12.8-12.8v-70.4c0-6.4-6.4-12.8-12.8-12.8h-22.4c-6.4 0-12.8 6.4-12.8 12.8v70.4c0 6.4 6.4 12.8 12.8 12.8z\" class=\"\"><\/path><\/svg><\/i> <img loading=\"lazy\" decoding=\"async\" width=\"16\" height=\"16\" alt=\"Loading\" src=\"https:\/\/islascruz.org\/blog\/wp-content\/plugins\/page-views-count\/ajax-loader-2x.gif\" border=0 \/><\/p>\n<div class=\"pvc_clear\"><\/div>\n","protected":false},"author":1,"featured_media":5465,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[14,15,239],"tags":[999,998,1000,997,129,16,240],"class_list":["post-5464","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-programming","category-python","category-tips-and-tricks","tag-codigo","tag-documentacion","tag-lectura","tag-programacion","tag-programming","tag-python-2","tag-tips-and-tricks"],"brizy_media":[],"_links":{"self":[{"href":"https:\/\/islascruz.org\/blog\/wp-json\/wp\/v2\/posts\/5464","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/islascruz.org\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/islascruz.org\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/islascruz.org\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/islascruz.org\/blog\/wp-json\/wp\/v2\/comments?post=5464"}],"version-history":[{"count":7,"href":"https:\/\/islascruz.org\/blog\/wp-json\/wp\/v2\/posts\/5464\/revisions"}],"predecessor-version":[{"id":5477,"href":"https:\/\/islascruz.org\/blog\/wp-json\/wp\/v2\/posts\/5464\/revisions\/5477"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/islascruz.org\/blog\/wp-json\/wp\/v2\/media\/5465"}],"wp:attachment":[{"href":"https:\/\/islascruz.org\/blog\/wp-json\/wp\/v2\/media?parent=5464"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/islascruz.org\/blog\/wp-json\/wp\/v2\/categories?post=5464"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/islascruz.org\/blog\/wp-json\/wp\/v2\/tags?post=5464"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}