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