VbAutodoc: Auto documentando VB

Qué lindo sería contar con una herramienta que, lea el código fuente (en este caso en VB) y me arme un archivo de documentación sobre las funciones y sub rutinas (preferentemente en html).
Cómo soy programador y me gusta python =) decidí hacerla. La bautizé vbautodoc (muy original) y está disponible una muy precoz temprana versión.

Próximamente, voy a mejorar aspectos en cómo se construyó, por ejemplo, el pedazo de html que uso como base, lo metí dentro del código, y sólo funciona para documentar VB, cuando, si se parametriza podría servir para cualquie lenguaje.

Web del proyecto
Descargas

Top 5 tips para desarrollar mejores aplicaciones

 Muchas veces me pongo a pensar en retrospectiva, acerca de cosas que se han hecho bien y cosas que se han hecho mal. Aquí escribo un resumen de las principales cosas que recomiendo hacer para ser un programador más feliz.

1- El usuario no tiene tiempo, ni quiere leer.

Olvidense del RTFM. Nadie lo lee. Hay que imaginarse que el usuario está inmerso en un caos tremendo, teléfonos sonando, gente, alarmas, etc. Lo que menos quisiera es estar lidiando con carteles del tipo "está seguro que desea cerrar etc", o, con aplicaciones oscuras que, si bien hace lo que se debe, tienen muchos botones, radio button y demás, y que, ni el mismo desarrollador entiende sin mirar el código.
Por eso, las aplicaciones tienen que ser intuitivas, se tienen que "auto-explicar". Lo mismo se aplica para los carteles y pop-ups que requieren una decisión del usuario. Si no hay más remedio que poner un cartel, que sea corto y puntal. Por ejemplo:

¿Está seguro que desea cerrar la aplicación?
[si] [no]

Cuando se podría:

¿Salir?
[si] [no]

Mucho más corto y al pie.

Por último, recuerden la página de Google, un cuadro de texto y un botón. ¿Qué mas?

2- Refactorizar vs From Scratch.

No siempre es bueno reescribir todo, ni tampoco siempre lo es reusar. Hay que usar esto de forma inteligente. Por un lado el código viejo no es necesariamente malo o confuso. Hay que tener en cuenta que, por un lado, leer código es más dificil que escribirlo (por eso siempre es tentador el reescribir todo) y por otro, el código viejo es, muchas veces, un código ya testeado, con bugs correjidos, en fin, es tiempo de trabajo. Reescribir todo desde cero significaría, tirar todo eso a la basura.
Lo ideal es un balance entre, reescribir las partes "mal escritas" tratando de reusar lo más posible. Es significativamente menos tiempo que escribir todo desde cero, sobre todo, si tenemos en cuenta que, el código desde cero va a tener bugs nuevos.

3- Pensar en grande.


Todo buen programa tiene que empezar cómo algo simple, pero, pensado a lo grande. Esto es, pensar que en un futuro, el programa puede crecer. Por eso, hay que escribir todo de forma flexible, aunque lleve más tiempo ahora, en un futuro va a ser más facil expandir y mantener. Mucho se ha hablado de la deuda técnica.Esto es un poco lo que trato de comunicar aquí: El tiempo que se ahorra escribiendo código chapucero ahora, lo pagás mañana.

4- Keep it simple.

Muchas aplicaciones tienen varias faces de desarrollo. Esto es, se reune con el cliente, se diseña, se programa, se vuelve a ver con el cliente, se corrijen cosas, se agregan otras. Entonces, es de esperar que el cliente no sea muy lógico, que haga cambios sobre la marcha y que no tenga en cuenta el diseño general del sistema. Para eso nos paga a nosotros ¿Verdad? Por eso, siempre hay que hacer limpieza del código y del programa. Lo que no se usa, fuera (por lo menos, de la vista) Esto ayuda mucho a que se cumpla el punto 1.
Si la aplicación en si, estaba pensada con otro espiritu y luego, se modificó, tratar de quitar todo lo que sobre. A veces más es menos. Muchos botones y radio button, checks, etc, para mantener un poco la idea anterior y que conviva con la idea nueva genera más problemas que soluciones. Use it or lose it.

5- Testing

Esto es obvio, pero, no se respeta mucho. El cliente no es un beta tester. Si se programa con la idea "que tenga bugs, total lo corrijo rápido" se arriesga, primero, problemas en datos que haya que resolver (esto es tiempo) y, segundo, da la idea de que el programa anda mal.

Octopys: Octopus para linux

Algún día prometí que iba a hacer una versión de octopus para linux, y cumplí. Por lo menos, ya hace algo, habrá que pulirlo un poco, lógicamente.

Está escrito en Python, con una GUI en Qt y lo pueden descargar desde acá.
O, pueden mirar el código directamente gracias a pastebin:

main.py
oct.ui
octo.py

El funesto caso de Is y ==

Hace varios días (creo que pasaron meses) inicié una discusión en la lista de mail (creo yo, más famosa y con más gente que sabe en serio) de python. PyAr.
La cosa empezó por un artículo que leo, donde se mostraba lo siguiente:

>>> a = 10
>>> b = 10
>>> a == b
True
>>> a is b
True

Luego

>>> a = 500
>>> b = 500
>>> a == b
True
>>> a is b
False

Claro. Al ser relativamente nuevo en python, ver esto me sorprendió, por lo que decido preguntar de que se trataba en la lista.
Mi pregunta no fue del todo clara, (y acepto 100% la culpa) por lo que se entendió que mi sorpresa venia por una confusión de conceptos y que, lo que no sabía era la diferencia entre "is" y "==".

Lo que pasó:

En realidad, yo posteo todo el ejemplo (que incluye "is" y "==") para dar un contexto, pero, en si, mi sorpresa venía SOLAMENTE por ver como el operador "is" se comportaba aparentemente distinto en dos situaciones aparentemente iguales.
Noten el uso de aparentemente. Esto es:

[entero_valor_x] is [entero_valor_x]

True

[entero_valor_Y] is [entero_valor_Y]

False

Olvidemos que comparar enteros con "is" es una chanchada, es incorrecto y no tiene mucho sentido. Más allá de eso, no me parecía (noten que uso el tiempo pasado) que comparar enteros (del mismo valor numérico) con "is" resultara True en algunos casos y False en otros. No veia el por qué, y me parecía feo (noten que sigo usando el pasado).

Pero claro, como se interpretó mal mi pregunta, todo se enfocó a explicarme que "is" no era "==", lo cuál, no era PARA NADA el punto del topic.
Claro, fue mi culpa por no ser claro en una primera instancia. Luego, traté de remediarlo, pero ya era tarde y... el resto es historia.

La explicación:

La explicación la había encontrado muy al comienzo del thread. Posteo una que me gustó y es sencilla:

Autor: Facundo Batista
Fecha: 2009-11-04 12:192009-11-04 15:19 -300UTC
A: pyar
Asunto: Re: [pyar] WTF?

a apunta a un 3 en memoria, y b apunta al mismo 3 en memoria. Python
no creó dos objetos "3", sino que usó el mismo para los nombres a y b.

a apunta a un 500 en memoria, y b apunta a otro 500 en memoria. Python
sí creó dos objetos "500".

La pregunta es... ¿por qué la diferencia de comportamiento? Como bien
dijo Nati arriba, Python precachea (o tiene internalizado) algunos
enteros chicos, porque sabe que siempre se van a usar.

Esa es sólo una, varios usuarios lo explicaron muy bien también. =)
Y eso era todo lo que quería escuchar. Una explicación sobre el funcionamiento, en apariencia, raro del "is" comparando enteros. No que me digan que usar "is" en ese caso estaba mal (cosa que sabía) ni que "is" no es "==" (cosa que sabía), y un largo etc.

P = NP?? So what????

Mi Filosofía de la Programación

a) Los nombres de variables y procedimientos deben ser descriptivos, pero, lo más breves posibles. Lo mismo se aplica a nombres de tablas y campos de las mismas.

b) Los nombres de variables auxiliares deben ser más cortos aún. Si es una sola letra, mejor.

c) Todo código que se puede reutilizar se debe reutilizar.

d) Si vas a escribir 2 veces algo similar, es probable que tengas que separar ese trozo en un procedimiento aparte.

e) Es preferible que el código se explique a si mismo que escribir código ofuscado y necesitar n líneas de comentarios (salvo que genere una alta considerable en el rendimiento)

f) El CamelCase da legibilidad, pero no hay que abusar. Lo mismo se aplica al underscore.

g) Una pequeña línea de comentarios a veces ayuda mucho, pero, no abusar, si quisieramos escribir tanto seríamos escritores.

----------------------------------------------------------------------------------------------------------------------------------
Esa es mi filosofía en cuanto a la programación. Se puede estar de acuerdo o no. Paso a explicar cada punto:

a) Esto es, no usar nombre del tipo xuiud, xxsw, x45, n45. Pero tampoco utilizar nombres como NrodeCuentaBancariadelCliente. clie, nomb, arti son óptimas para variables o campos, Articulos, Clientes, VeriDeuda para tablas o procedimientos. Sentido común, yo puedo llamar a una funcion VerificarDeudaCliente, pero podría abreviarla con VeriDeuda y se seguiría entendiendo de qué se trata.

b) Si se va a usar una varible que, por ejemplo, se incrementa en una iteración el nombre tiene que se más corto aún que en a), por ejemplo: i, e, r.

c) Este punto es bastante obvio. Si ya lo pensaste ayer, reciclalo.

d) No dudar en separar código en común en una subturina o función pasandoles argumentos.

e) Eso es algo que siempre discuto. Es preferible escribir código un poco más largo en líneas pero que se entienda fácil a escribir algo ofuscado y necesitar varias líneas de comentarios para explicarlo. Esto es más obvio cuando se escribe algo hoy y se tiene que modificar en 2 o 3 meses. Ese sería el filtro.
La única excepción sería si escribirlo así me diera un rendimiento mayor y notorio.

f) Usarlos con sentido común. VeriClie o veri_clie, son aceptables. VeRiClIe o ve_ri_cli_e, es abusar.

g) Relacionado con el punto e). Agregar una línea de comentario para aclarar un poco el panorama está bien. Ahora, líneas y líneas por todos lados demuestra que algo no anda bien, por qué tu código necesita tanta explicación??
Además, si tanto te gusta escribir, capaz deberías considerar la literatura =)

Lego