Guía para un código legible, comprensible y mantenible.

[mjrofra]

Hola,

hace poco digitalboy (a quien aprovecho para expresar mi admiración y respeto), compartió con nosotros el Zen de Python:

1. Hermoso es mejor que feo.
   
2. Explícito es mejor que implícito.
   
3. Simple es mejor que complejo.
   
4. Complejo es mejor que complicado.
   
5. Plano es mejor que anidado.
   
6. Disperso es mejor que denso.
   
7. La legibilidad cuenta.
   
8. Los casos especiales no son suficientemente especiales como para romper las reglas.
   
9. Aunque lo pragmático gana a la pureza.
   

Esta serie de principios resulta relevante para cualquier lenguaje de programación, incluido VBA.

Cada quien tiene su forma de hacer las cosas. Como todos, supongo, he ido cambiando mi forma de escribir código a medida que voy aprendiendo cosas nuevas. Comparto con ustedes algunas ideas de lo que actualmente considero deben ser algunos parámetros básicos para escribir buen código.

Por lo general, considero que un buen código es aquel que:

1. Hace lo que tiene que hacer.
   
2. lo hace rápido
   
3. es legible, comprensible y mantenible.
   

El último punto es fundamental (quizás incluso más que los demás) y es en la que me quiero enfocar (y es lo que está subyacente en el Zen de Python): Un buen código debe ser legible, comprensible y mantenible.

Escribir cada declaración de variable en una línea con su correspondiente tipo de datos con la forma

Dim variabla1 as Tipo1

Dim variabl2 as Tipo2[/CODE]

y no

[CODE]dim x, y, z[/CODE]

hace el código mucho más [b]legible[/b] y es una buena práctica que se recomienda casi que en toda guía de estilo que uno encuentra para VBA.

El uso de caracteres de declaración de tipo, al estilo

[CODE]dim a$, b&[/CODE]

se considera obsoleto (se mantiene por compatibilidad con Basic pero su uso es desaconsejado ya que oscurece el código, no está de acuerdo con la forma de declarar datos en VBA y no abarca todos los tipos de datos).

Considero importante usar espacios entre líneas, distinguiendo bloques de código relacionado, lo que hace el código más legible.

Así mismo, cada instrucción debe ir en una línea

[CODE]instrucción1
instrucción2
instrucción3[/CODE]

Evitando el uso de

[CODE]instrucción1: instrucción2: instrucción3[/CODE]

Esto último hace el código menos legible y veo que frecuentemente se usa quizás con la intensión de transmitir la ilusión de un código más breve.

Por último, las márgenes (sangrías – indentation -) son fundamentales para la legibilidad de un buen código.

Haciendo el código más legible, damos un paso para hacerlo más [b]comprensible[/b]. Sin embargo, usar nombres de variables descriptivos ayuda a mejorar aún más la comprensión del código.

Esto:

[CODE]Dim a, b: b = 1
For a = 1 To 10: Cells(a, = 1: Next[/CODE]

Es menos legible que

[CODE]Dim a As Integer
Dim b As Integer

a = 1

For a = 1 To 10
Cells(a, = 1
Next a[/CODE]

Pero esto último es menos comprensible que esto:

[CODE]Dim Fila As Integer
Dim Columna As Integer

Columna = 1

For Fila = 1 To 10
Cells(Fila, Columna) = 1
Next Fila[/CODE]

Que el código sea legible y comprensible ayuda a que sea [b]mantenible[/b]. Sin embargo, una parte fundamental para hacerlo comprensible y mantenible es documentar el código.

Bueno, solo son algunas ideas que comparto y me gustaría escuchar que opinan y qué guías tienen ustedes para escribir código legible, comprensible y mantenible.

[Gerson Pineda]

Hola mjrofra

Que bueno (y me alegra) que hayas regresado y mira en que dia (24/12/12) estas dando buenos consejos jeje!

Tus apuntes son muy tomados en cuenta... pero entiendo que los dos puntos " : " sirven para acelarar las macros, estare equivocado?

Pd: no te pierdas hombre! que el pueblo (foro) siempre necesita alguien como tu

Feliz navidad y año nuevo (2013)

Saludos

[verzulsan]

Es decir, todo lo contrario a mi modulo secreto de encriptacion :eagerness:

i101010101010.zip

[digitalboy]

Por lo general, considero que un buen código es aquel que:

1. Hace lo que tiene que hacer.
   
2. lo hace rápido
   
3. es legible, comprensible y mantenible.
   

Bueno, solo son algunas ideas que comparto y me gustaría escuchar que opinan y qué guías tienen ustedes para escribir código legible, comprensible y mantenible.

Hola! Estoy de acuerdo en la importancia de los tres puntos! aunque la importancia de estos puede variar dependiendo el programador o el ambito en el que se desenvuelva... un programador que programe para si mismo y no tenga que compartir su codigo, quizas el punto 3 lo haga a su manera...

Cuando estuve trabajando como programador Python Jr no me cansaba de maldecir a los anteriores programadores y no es que me molestara la forma en que programaban pero realmente nos hubiesen echo la vida mas facil a mi compañero y a mi si hubiese por lo menos comentado las partes mas significativas de los modulos (funciones y clases) que crearon. Asi que comentar el codigo es una buena idea! pero sin caer en la exageracion... cuando empezaba a dar mis pininos en VBA, comentaba cada linea de codigo para recordar para que servia cada instruccion... mi compañero se burlaba diciendo: "Son mas comentarios que codigo!"

Saludos y Felices fiestas!

- - - - - Mensaje combinado - - - - -

Tus apuntes son muy tomados en cuenta... pero entiendo que los dos puntos " : " sirven para acelarar las macros, estare equivocado?

Me parece que ":" solo es para poder utilizar mas de una instruccion en una sola linea sin acelerar codigo!

- - - - - Mensaje combinado - - - - -

Es decir, todo lo contrario a mi modulo secreto de encriptacion :eagerness:

Crei que no existia la ofuscacion en VBA! veo que me equivoque!

[Gerson Pineda]

Digitalboy lo de los dos puntos, lo lei (no recuerdo donde) pero me parece que si VBA lee mas rapido una linea de programacion, creo ayudaria a hacer mas rapido su proceso...

Algunos enlaces (que lei tiempo atras) y aprovechando el tema de mjrofra

[DBOX]14 formas de acelerar y optimizar tus macros excel | TodoExcel[/DBOX]

[DBOX]EXCEL FORO: EJERCICIOS, EJEMPLOS, SOLUCIONES, DUDAS: VBA: Maneras de acelerar nuestras macros de Excel.[/DBOX]

Saludos

[digitalboy]

Digitalboy lo de los dos puntos, lo lei (no recuerdo donde) pero me parece que si VBA lee mas rapido una linea de programacion, creo ayudaria a hacer mas rapido su proceso...

Algunos enlaces (que lei tiempo atras) y aprovechando el tema de mjrofra

[DBOX]14 formas de acelerar y optimizar tus macros excel | TodoExcel[/DBOX]

[DBOX]EXCEL FORO: EJERCICIOS, EJEMPLOS, SOLUCIONES, DUDAS: VBA: Maneras de acelerar nuestras macros de Excel.[/DBOX]

Saludos

Muy buenos los tips!

Es en el segundo enlace, tip #13 donde dice:

""" Intentar reducir el número de líneas de código, empleando para ello la posibilidad de escribir en una misma línea usando el separador ':' """

Tengo mis dudas, recuerdo que cuando tenia dos intrucciones en la mis ma linea con ":" si ejecutaba el codigo paso por paso no se ejecutan las intrucciones al mismo tiempo, si no que primero una y despues salta a la segunda...

Hare una prueba...

Saludos!

[verzulsan]

entiendo que los dos puntos " : " sirven para acelerar las macros

Nunca había escuchado algo parecido y me ha entrado curiosidad. En un articulo de microsoft dice:

Separators

Separators do what their name suggests: they separate sections of code. In Visual Basic, the separator character is the colon ( : ). Use separators when you want to include multiple statements on a single line instead of separate lines. This saves space and improves the readability of your code. The following example shows three statements separated by colons.

Parece que lo usan con fines organizativos, no comentan sobre si mejora o aumenta la velocidad del código pero he realizado unas pruebas de velocidad y curiosamente me ha ocurrido al revés, en todas las pruebas que he realizado, el código comprimido en una sola línea se ejecuta más lentamente que el código normal estructurado:

Resultado de una de las pruebas:

Usando múltiples sentencias con el operador Colon (punctuation)	121667 Repeticiones en 10 segundos

Usando código normal sin Colon (punctuation)	133427 Repeticiones en 10 segundos[/CODE]

Dejo ahí el adjunto por si alguien quiere verificar este dato en su equipo.

Saludos.

Test de velocidad Comparacion.xls

[Guest Cacho R]

... ":" sirven para acelarar las macros, estare equivocado? ...

Este tipo de sugerencias -muchas veces- son el resultado de estadísticas indemostrables o de gustos personales, y pongo por caso lo siguiente:

Sub Prueba()
Dim i#, j%, iniTime!
Cells.ClearContents
Application.ScreenUpdating = False

' Usando los dos puntos...
iniTime = Timer
For j = 1 To 3
  For i = 1 To 65000#: Cells(i, j) = Rnd: Next i
Next j
Application.ScreenUpdating = True
Cells(1, 4) = Timer - iniTime
Application.ScreenUpdating = False

' Sin usar los dos puntos
iniTime = Timer
For j = 6 To 8
  For i = 1 To 65000#
    Cells(i, j) = Rnd
  Next i
Next j
Application.ScreenUpdating = True
Cells(1, 9) = Timer - iniTime
End Sub[/PHP]

Vemos dos bloques de instrucciones que "hacen lo mismo": primeramente con tres líneas de código separadas por los dos puntos, y luego esas mismas líneas ubicadas una debajo de la otra.

Luego de correr ese código unas 10 veces llego a la siguiente conclusión: "Empate técnico" (ni vencedores ni vencidos).

Al no haber encontrado un verdadero sustento técnico, caigo en el tema de [b][u]los gustos personales[/u][/b] y, por ejemplo, yo me quedo con la primera forma (utilizando los dos puntos) pues me resulta mucho más estético, legible y comprensible.

Para terminar notemos que gracioso es ver en el artículo técnico que nos menciona [b][b]verzulsan[/b][/b], que los dos puntos se utilizan (se dice allí) para mejorar la legibilidad del código: ¿Puede quedar más claro, entonces, que esto se trata de gustos personales?...

___

Otro lugar donde se ponen de manifiesto [u][b]los gustos personales[/b][/u] es en el uso de:

[color=#ff8c00][b]Dim i#, j%, iniTime![/b][/color]

en lugar de:

[color=#ff8c00][b]Dim i As Long, j As Integer, iniTime As Single[/b][/color]

Miremos (sin necesidad de entrar en el viejo Basic de fines de los '60) el nuevo Visual Basic 2012. En el enlace anterior vemos que el uso de caracteres de tipo identificador (así se los llama) no son -sino- una opción más a tener en cuenta.

[u]En resumen[/u]:

Las sugerencias o tips como los que analizamos siempre deben ser tenidos en cuenta: ya sea para adoptarlos si nos convencen o para descartarlos en caso contrario. Lo único que no sería interesante hacer es "no probarlos".

Saludos para todos y felices fiestas.

[Gerson Pineda]

Verzulsan! fijate que realice unos insignificantes arreglos a la estructura de tus codigos y parece que el "Monolinea" va mejor...

A PROBARLO

Public Declare Function GetTickCount Lib "kernel32" () As Long 'vzs_a: Tiempo en milisegundos


Sub Pruebas()

    [d5] = "Espera " & [b1] & " segundos"

    [d4] = "Espera " & [b1] & " segundos"

    Call MonoLinea(CLng([b1] * 1000))

    Call MultiLinea(CLng([b1] * 1000))

End Sub



Public Function MonoLinea(Retardo As Long)

    Dim TimeINI As Long

    Dim TimeFIN As Long

    Dim TimeDif As Long

    Dim Repet As Long

    Repet = 0

    TimeINI = GetTickCount

    Do While (TimeDif < Retardo): Repet = Repet + 1: TimeFIN = GetTickCount: TimeDif = TimeFIN - TimeINI: DoEvents: Loop

    [d4] = Repet

End Function

Public Function MultiLinea(Retardo As Long)

    Dim TimeINI As Long

    Dim TimeFIN As Long

    Dim TimeDif As Long

    Dim Repet As Long

    Repet = 0

    TimeINI = GetTickCount

    Do While (TimeDif < Retardo)

        Repet = Repet + 1

        TimeFIN = GetTickCount

        TimeDif = TimeFIN - TimeINI

        DoEvents

    Loop

    [d5] = Repet

End Function[/CODE]

Saludos

[pegones1]

Me encanta este tema iniciado por Mauricio sobre el Zen de Python y la guía para un código legible, comprensible y mantenible.

Aunque yo diría "código mantenido" por nosotros, los codificadores, que es lo que hacemos durante la mayor parte del tiempo: el mantenimiento del software durante la depuración, ya sea antes del despliegue o lanzamiento o después, durante la garantía del producto o del ciclo de vida de la aplicación.

Para mantener nuestro código en pie y, más a menudo de lo que nos gustaría, el de otros, es preciso seguir las mejores prácticas en programación que conozcamos, ejemplos de ellas:

[DBOX]Best Coding Practices - Wikipedia, the free encyclopedia

Best practices for programming in C

Top 10 Tips & Best Practices to Optimize, Speed-up Excel Formulas | Chandoo.org - Learn Microsoft Excel Online[/DBOX]

Hay dos reglas que no hay que olvidar nunca:

1. La creación o construcción de código es una parte pequeña pero necesaria de una aplicación. En un futuro próximo veremos más ejemplos de programación automática, como la grabadora de Excel, y de ordenadores que son capaces de aprender por sí mismos, como con la metaprogramación o la homoiconicidad.
   
2. La reutilización del código permite optimizar la producción de software. Es importante que esté bien documentado, mediante comentarios del programador o mediante herramientas de documentación automática.
   

Todos nosotros hemos aprendido mucho más de un programa bien estructurado, documentado, programado según una guía de estilo estándar, siguiendo un patrón de diseño, que facilita el aprendizaje de las nuevas generaciones de diseñadores condensando conocimiento ya existente en enciclopedias de desarrolladores, como la codepedia.

Siempre habrá un momento en el que tienes que volver a tu código. Tal vez sea para corregir un error, o para agregar una nueva función. De todos modos, mirando tu propio código, después de seis meses es casi tan malo como mirar cualquier otro código. Lo que necesitas es dejar recordatorios para ti mismo sobre lo que estabas haciendo y no olvides que, si cambias el código, también hay que cambiar los comentarios.

Y si aún así no somos profesionales, siempre nos quedarán las herramientas de análisis de código, aunque puede que lo que haya pretendido el programador es que nunca lo consigamos interpretar y haya ofuscado su código a la perfección.

[DBOX]List of tools for static code analysis - Wikipedia, the free encyclopedia

Ofuscación de código[/DBOX]

Espero no haberos hecho la pascua, si he sido muy pesado documentando mis propias experiencias en codificación.

¡Felices Pascuas codificadores!

[verzulsan]

Hola Gerson, al final lo que dice Cacho es desde mi punto de vista lo que tiene más sentido, también llego a la conclusión de que es indemostrable.

Probé tu código y me da:

Usando múltiples sentencias con el operador Colon (punctuation) 334131 Repeticiones en segundos

Usando codigo normal sin Colon (punctuation) 334983 Repeticiones en segundos

y luego probé el mío y me sale

Usando multiples sentencias con el operador Colon (punctuation) 340872 Repeticiones en segundos

Usando codigo normal sin Colon (punctuation) 349834 Repeticiones en segundos

Depende de los programas que se esten ejecutando en mi ordenador, a veces sale que multilineas es mas rapido y otras que monolinea es mas rapido, por otro lado, no le veo mucho sentido a que por definir las variables en una sola línea o en varias, cambie la velocidad de ejecución del resto del programa (Pero todo es posible)

Saludos.

[Antoni]

Hola a todos:

Yo he probado con 1.000 millones de ciclos, 3 veces y las 3 veces ha sido mas rápido el código línea a línea, aunque muy poco (2 segundos, 2 segundos y 1 segundo), casi despreciable si tenemos en cuenta que el Time de VBA no te muestra las fracciones de segundo, y tampoco no puedo garantizar que durante la ejecución (casi 40 minutos) no se produjeran interrupciones generadas por otras aplicaciones instaladas (Antivirus, Firewall,....).

Por lo que hemos de concluir que da igual que da lo mismo como escribamos nuestro código.

Y contra lo que pueda parecer, el escribir línea a línea ocupa menos espacio, ya que cada instrucción en la misma línea va separada por dos caracteres (Dos puntos y un espacio) mientras que el código escrito línea a línea solo tiene uno (Return).

Feliz año nuevo

[Guest Cacho R]

... Y contra lo que pueda parecer, el escribir línea a línea ocupa menos espacio, ya que cada instrucción en la misma línea va separada por dos caracteres (Dos puntos y un espacio) mientras que el código escrito línea a línea solo tiene uno (Return) ...

Mi estimadísimo y ugandés amigo Antoni: Si guardas tu módulo en el disco (*.bas) y analizas al archivo con un editor hexadecimal, verás que además del caracter 13 (retorno de carro ó Return) tienes al caracter 10 (salto de línea)...

Conclusión: ocupan lo mismo, de modo que ni tan siquiera en "gasto de caracteres" se diferencian.

[Gerson Pineda]

versulzan

En eso estamos estimado si tiene o no sentido probar (tu archivo) u otra forma de programar, yo gane mas tiempo con el arreglo, pero no es cuestion de demostrar creo es cuestion de experimentar:tennis:

Lo que nunca (yo) podria afirmar es darle punto y a parte a los debates, especialmente cuando se tratan temas de la "informatica"

Te sientes comodo con los : o no?, pues no importa jeje lo que importa es compartir a la comunidad sin restricciones!

Saludos

[Antoni]

From Uganda with love:

Siempre que afirmo algo de forma rotunda, "la cago" (Expresión Ugandesa que significa "la cago" , y sin embargo cunado no lo hago con rotundidad normalmente tengo razón, ¿ Porqué será ?, ¿ Es una de las leyes de Murphy ?

Ya lo dice el refrán, "Te arrepentirás siempre de hablar, pero nunca de callar"

Besitos y "be happy"

[Guest Cacho R]

... Siempre que afirmo algo de forma rotunda, "la cago" (Expresión Ugandesa que significa "la cago") ...

Si bien el idioma oficial de Uganda es el inglés, no hay nada como el uso de lenguas autóctonas (como el swahili que has empleado con notoria comodidad) para entender el sentido de tu pensamiento.

¡Ave Antoni!... ¡Tus admiradores te aclamamos!

(jajajajajajajajajaja)

[Gerson Pineda]

Hola......

El uso de caracteres de declaración de tipo, al estilo

[COLOR=#0000cd][B]dim a$, b&[/B][/COLOR][/CODE]

se considera obsoleto [color=#0000cd][b](se mantiene por compatibilidad con Basic pero su uso es desaconsejado ya que oscurece el código, no está de acuerdo con la forma de declarar datos en VBA y no abarca todos los tipos de datos).[/b][/color]

Considero importante usar espacios entre líneas, distinguiendo bloques de código relacionado, lo que hace el código más legible....

Bueno, solo son algunas ideas que comparto y me gustaría escuchar que opinan y qué guías tienen ustedes para escribir código legible, comprensible y mantenible.

mjrofra fijate que leyendo una vez mas tus buenos consejos, me he percatado sobre los signos como $ & ! etc, etc..., tienes toda la razon al indicar [b]"...ya que oscurece el codigo"[/b] [color=#696969][i](o sea como quien dice "ocultando algo por ahi" jeje y esperar algo como: "Como lo hiciste?" jaja)[/i][/color] y tomo muy en cuenta esto [b]"... no abarca todos los *tipos de datos*"[/b] umm me dije hay que leer un poco mas y no dejarnos llevar por practicas que no conocemos y mejor experimentar/probar/errar, ya que al final el resultado sera nuestro exito en el acelere o no de nuestras macros...

Adjunto un archivo que seguro les gustara! vamos todos a abrirlo... (y como indica una de las famosas redes sociales "Dale Me Gusta")

[ATTACH]35853.vB[/ATTACH]

Feliz año nuevo y que el mundo sea mas humano y menos materialista!:tennis:

Saludos

Feliz año nuevo2013.xls

[pegones1]

Gerson, aprovecho que tus felicitaciones son legibles y comprensibles para mantener mis mejores propósitos de Año Nuevo 2013 para todos los foreros. :very_drunk:

Como querías, le he dado a me gusta y también comparto mi felicitación ¡que no se autodestruye mientras se lee!

Por cierto, la he montado sólo con signos por si alguno no lo ve. :bull_head:

Feliz año nuevo2013-PW2.xls

[Gerson Pineda]

Pedro! que bueno te hayas animado a las felicitaciones (aunque estemos un poco fuera del tema inicial jeje disculpas mjrofra, pero estamos en fechas importantes)

A tu archivo uff que trabajito (curro como dicen ustedes!) pero ahi te va mi version mejorada... espero os guste

Armonia y hermandad para todos

Saludos

Feliz año nuevo.zip