2011-07-13 14 views
6

Trabajo en el desarrollo de aplicaciones utilizando winforms en C#. Mientras desarrollo, quiero usar muchos métodos pequeños, por ej. resetPerticularCombo(), por lo que el código permanece lo más limpio posible. Pero el problema es hacer que los métodos para 3-5 líneas de código puedan dar lugar a demasiadas llamadas a métodos, he escuchado que, al compilar Visual Studio 2008, se ocupa de esto usando el código en línea.winforms .Net En cuanto al uso de métodos pequeños

Mi pregunta es, ¿debería confiar en esta característica y seguir con el uso de pequeños métodos de ayuda o debería usar la línea yo mismo?

+3

Si simplemente está tratando de evitar el desorden de código (métodos completos para el código utilizado solo desde una función), podría realizar instancias locales de delegados 'Action' o' Func', inicializadas con lambdas. Esto no será una mejora en el rendimiento de ninguna manera (pero vea la respuesta de Jon Skeet sobre por qué eso no importa), pero a veces puede hacer que la legibilidad gane, especialmente cuando tiene código repetido. P.ej. 'Acción doSomething = c => c = a * (b + c);', cuando tiene que escribir la misma línea varias veces. Entonces solo llamarías 'doSomething (g); hacer algo (h); '. –

+1

Tener métodos que son 3-5 líneas de código largo me suena bastante bien. En general, trato de mantener todos mis métodos más pequeños que 12 líneas de código. Si tiene métodos muy grandes (incluso cientos de líneas), indica un problema grave en su diseño ... – MattDavey

Respuesta

7

No debe preocuparse por tener un gran número de llamadas a métodos hasta que haya demostrado que es un problema. Es muy poco probable (IMO) que esto actualmente cause un problema, y ​​si le da un código más legible, eso es lo más importante.

Pero prueba el rendimiento todo el tiempo para ver si es aceptable. Averigüe dónde se encuentra el cuello de botella en su código, ya sea mediante el uso de perfiles u otras técnicas, y considere la optimización microscópica justo en los puntos en los que hará la mayor diferencia.

Según mi experiencia, la optimización microscópica en el nivel de "usar menos métodos" casi siempre es inútil en comparación con cambios de nivel superior (por ejemplo, pasar de una búsqueda de lista a una búsqueda de diccionario, etc.).

+0

Estoy de acuerdo con encontrar primero los cuellos de botella: recientemente descubrí la alegría de Cronómetro en el espacio de nombres System.Diagnostics. –

2

Acepto a Jon Skeet.

En cuanto a las aplicaciones empresariales que yo pueda decir el

Estoy llevando un pequeño equipo de desarrolladores siguiente (5 desarrolladores). Tenemos una aplicación con aproximadamente 500k loc.

Siempre tratamos de encontrar la preocupación más particular que debería tener un método. Así que tenemos muchos métodos pequeños y que "explican por sí mismos". Como resultado tenemos muchos métodos diferentes y esto nunca conduce a un problema.

La mayoría de las veces, los cuellos de botella están accediendo a recursos como SQL Server, Archivos, etc ... O la falta de asincronía.

También tengo un rendimiento que podría perfilar utilizando hormigas profilácticas.

también me gustan estas "reglas" de la optimización que encontré hace algún tiempo en la web

FirstRuleOfOptimization - No lo hagas.

SecondRuleOfOptimization - No ... todavía. P

ThirdRuleOfOptimization - ProfileBeforeOptimizing

Si el desarrollo de un software de timecritical (Gráfico o relacionados driver), luego estas cosas pueden hacer que el punto, pero entonces yo no estaría seguro si .net eran el mejor ambiente para Haga eso

+0

Muchas gracias Boas, especialmente sobre las Reglas de Optimizaciones. – mohits00691

0

Muchas rutinas pequeñas están bien, como ya dicen otras respuestas, pero recuerde considerar refaccionar rutinas similares, para legibilidad y mantenimiento (y no específicamente para el rendimiento).

resetPerticularCombo() y resetAnotherCombo() puede valer la pena convertir a resetCombo(PerticularCombo) y resetCombo(AnotherCombo), si las rutinas son de lo contrario la misma.

Con lambdas anónimos, esto incluso puede ser utilizado para consolidar otros algoritmos similares: (potentailly mal ejemplo, pero seguir utilizando el código de la OP)ProcessCombo(PerticularCombo, (c)=>c.Reset()) y ProcessCombo(PerticularCombo, (c)=>c.SelectFirst())

Soy un programador de VB.NET y este código ha sido ingresado directamente en SO sin ninguna verificación de sintaxis.

Cuestiones relacionadas