Hola a todos
En algunos debates con mis colegas, hemos discutido sobre que forma de programar es mas eficiente, comparando diferentes codigos que hacen lo mismo
No es porque tenga que escribir menos, sino para la PC cual codigo la recarga menos
Por ejemplo, cual es mas eficiente:
Memo.Lines.Add('texto');
Memo.Lines.Add('texto');
Memo.Lines.Add('texto');
Memo.Lines.Add('texto');
ó
With Memo.Lines
begin
Add('texto');
Add('texto');
Add('texto');
Add('texto');
end;
Desde el punto de vista del desarrollador es mucho más productivo y eficiente el uso de with. Desde el punto de vista del compilador es recomendable el primero, ya que el uso del with es más "lento".
Emplear with para el que escribe es muy ventajoso, por la cantidad de caracteres pero esto le supone un poco más de carga para el compilador porque implica el uso de indirecciones de punteros. Pero tampoco es que el compilador se atrofie...
Desde el punto de vista "matemático" o técnico, es indiferente, puesto que genera la misma cantidad de LDC (Lineas De Código) y todo cálculo basado en este indicador no se verá alterado, en ambos casos tenemos un LDC de 4.
Si lo viéramos "matemáticamente" es lo mismo hacer:
Xa + Xb + Xc + Xd
que:
X*(a + b + c + d)
En este caso, X sería Memo.Lines, y "a", "b", "c" y "d" los correspondientes Add(Texto).
Incluso, desde el aspecto de vista de la complejidad ciclomática V(G) tenemos el visto valor, 1 puesto que no hay bucles, bifurcaciones, etc.
Por tanto desde el aspecto de las métricas supone cierta indiferencia.
Tambien, que es mas eficiente para los parametros de una función, una variable o directamente la propiedad de un control (Ej: edit.text)
NO entendí este punto. ¿Te refieres a que es mejor, acceder a una variable o propiedad?
El acceso a una variable es directo, no supone dificultades para el compilador. En el caso de las propiedades es otro mundo.
Cuando uno accede a una propiedad pueden suceder dos cosas:
1. O hace uso de algún método de protección que tenga asociado al mismo (los métotos
set y
get) O bien,
2. Accede de forma directa a la variable privada.
Para el primer caso tenemos por ejemplo esto:
property Name: string read GetName write SetName;
y Para el segundo:
property Name: string read FName write FName;
Si la propiedad cuenta con métodos de escritura y/o lectura, implica un pequeño gasto y retardo para el compilador puesto que debe hacer uso del método adecuado para acceder al campo o variable privada. Para el ejemplo 1, el tener esto:
Objeto.Name := 'Un nombre';
El compilador lo traduce a:
Objeto.SetName(UnNombre');
Es decir, realiza
un paso más.
Cuando la propiedad no tiene estos métodos, se ahorra ese paso y accede de forma directa al campo.
Esto no quiere decir que debe descartarse el uso de propiedades con métodos de lectura y escritura. Se debe disponer de estos métodos cuando se necesite de un control frente al uso de la variable o campo privado.
Alguien tiene o sabe de algun manual o alguna documentacion sobre como programar de forma mas eficiente, es decir ahorrando lineas de codigo, recargar menos la memoria, hacer el ejecutable mas pequeño, etc.
Es que en ese debate se me desperto el interes para hacer mis codigos mas eficientes, y asi optimizar mejor mis programas
Pues yo no conozco ningún manual o libro que trate de forma directa el tema. Lo que te ha recomendado Egostar es lo más "directo" que conozco.
Pressman en su libro "Ingeniería de Software, un enfoque práctico" trata de forma airosa e introductoria, desde mi humilde punto de vista, unos temas que podrían ser utilizados para analizar las estructuras de control y el flujo de datos buscando reducir y simplicar algunas operaciones.
En la cuarta edición, capítulo 16.5 Prueba de la estructura de control habla de dos técnicas de prueba:
* Prueba de condición, que tiene como finalidad probar las condiciones lógicas.
* Prueba de flujo de datos, que busca desarrollar caminos de prueba siguiendo el orden de aparición de los datos.
* Prueba de bucles, que busca explotar la forma en como se llevan a cabo los anidamientos, si existen bucles infinitos, etc.
En cierto modo, estos tipos de pruebas pueden detectar si algo no anda bien y si es necesario volver a revisar.
Tal vez no sean las más adecuadas para reducir las líneas de código.
Hay una serie de métricas que pueden ofrecer algunos resultados interesantes. Una de ellas es el uso de V(G) o complejidad ciclomática de los algoritmos que se implementan. Cuanto más alto sea el valor más casos de prueba debería hacerse y más atención al código debería prestarse. Un valor grande
podría indicar que es momento de particionar el código.
Algunas de las métricas basados en las líneas de código no son muy tomadas en cuenta. En ocasiones no son buenas representativas pero en casos
micros pueden aportar algunos valores interesantes.
Halstead con su teoría ha levantado una controversia fuerte al proponer una métrica de complejidad y de volumen basada en el código fuente... al día de hoy sigue siendo un tanto cuestionada pero hay que admitir que ofrece una premisa bastante fuerte: existe una expresión mínima para todo algoritmo. Y eso es muy cierto puesto que todo algoritmo posee un cierto grado de complejidad mínimo (por ejemplos los algoritmos de ordenamiento son de orden u expresiones cuadráticas o logaritmicos), como contraparte esta métrica es dependiente del lenguaje de programación y esto no es de buen agrado como un valor
imparcial.
Pero como Delphi es un LOO, estás métricas que he mencionado carecen de peso frente al paradigma OO. En un ambiente OO se espera que la clase tenga un equilibrio entre cohesión y acoplamiento... casi todas las métricas propuestas para el paradigma OO están basadas en información proporcionada por las clases.
La métrica MPC (Métodos ponderados por Clase) puede proporcionar un valor de lo compleja que pueda llegar a ser una clase, y a su vez puede indicar el grado de reutilización. En el link que ofrece Eliseo hablo un poco más de ésto.
Adoptando posturas más formales, como las de la sala limpia, podemos conseguir mejores pruebas (al menos eso aseguran) que las de posturas menos informales y de pruebas unitarias extensas o tediosas. Analizando nuestros algoritmos desde "adentro hacia afuera", podemos preveer si el diseño es el más adecuado y/o responde a lo que esperamos.
La idea de las subdemostraciones de las
cajas transparentes es de convertir nuestro algoritmo en una
sumatoria de funciones cuyo valor de una caja superior pueda ser
predecido por una inferior.
Si deseas saber más de esto recomiendo una lectura al libro. Lo que he estado hablando responde a diversos capítulos... digamos que he dado un paseo por casi todo el libro.
Lo importantes que que si vas a poner en práctica un proceso de "depuración" y de mejora a tu código es que seas repitente, y constante. Adoptarlo como una actividad más y que te aporte valor. De nada sirve hacerlo por hacer si no hay una toma de conciencia y uno no le da el significado e importancia que se le merece.
Ya sea que lo lleves de una forma medianamente formal, o formal lo importante es que seas reuterativo.
De este modo se consigue los beneficios.
Disculpen por si me he extendido demasiado.
Saludos,
) 
(a) 
