¿es mejor probar si se necesita una función dentro o fuera de ella?

Question

¿cuál es la mejor práctica? llamar a una función y luego regresar si prueba algo, o prueba algo, ¿luego llama?

prefiero la prueba dentro de la función porque facilita la visualización de las funciones a las que se llama.

por ejemplo:

protected void Application_BeginRequest(object sender, EventArgs e) 
     { 
      this.FixURLCosmetics(); 
     } 

y

private void FixURLCosmetics() 
     { 
      HttpContext context = HttpContext.Current; 
      if (!context.Request.HttpMethod.ToString().Equals("GET", StringComparison.OrdinalIgnoreCase)) 
      { 
       // if not a GET method cancel url cosmetics 
       return; 
      }; 

      string url = context.Request.RawUrl.ToString(); 
      bool doRedirect = false; 

      // remove > default.aspx 
      if (url.EndsWith("/default.aspx", StringComparison.OrdinalIgnoreCase)) 
      { 
       url = url.Substring(0, url.Length - 12); 
       doRedirect = true; 
      } 

      // remove > www 
      if (url.Contains("//www")) 
      { 
       url = url.Replace("//www", "//"); 
       doRedirect = true; 
      } 

      // redirect if necessary 
      if (doRedirect) 
      { 
       context.Response.Redirect(url); 
      } 
     } 

es tan bueno:

if (!context.Request.HttpMethod.ToString().Equals("GET", StringComparison.OrdinalIgnoreCase)) 
      { 
       // if not a GET method cancel url cosmetics 
       return; 
      }; 

o debe esa prueba se realiza en Application_BeginRequest?

¿Qué es mejor?

thnx

Answer 1

me siento como prueba dentro de la función es mejor. Si prueba fuera de la función, tendrá que probar en todas partes que se podría llamar a esa función (y causaría una gran cantidad de código duplicado).

Es más agradable tener todo en un solo lugar y luego extenderlo a todas partes.

Answer 2

Si un método requiere absolutamente que se cumpla una cierta condición antes de que pueda realizar su función, entonces sí, debe colocar la validación dentro de esa función. Si, por otro lado, su código de llamada dice "solo realice esta operación en este conjunto de condiciones", entonces la condición es mejor en el código de llamada, porque la próxima vez que desee llamar a ese método, es posible que no desee incluir esa condición .

Answer 3

En este caso, creo que el nombre de la función implica que algo va a pasar con la URL en todos los casos. Alguien puede querer llamar al FixURLCosmetics en una página que no sea GET y esperar que ocurra algo.

Cambiaría el nombre de FixURLCosmetics a FixGETURLCosmetics. Luego, lanza una excepción si se llama a una página que no sea GET.

Answer 4

Si fuera usted, probaría en AMBOS lugares, estar fuera Y dentro, y burlarse de los componentes internos que se están llamando (como el contexto.Llamadas de solicitud), para fortalecer también el comportamiento interno y burlarse de algunos retornos inesperados y cómo su método trata con ellos.

En este caso, una API como easymock podría simplificar MUCHO la burla de los componentes internos.