Un colega me dijo una vez que Dios es matar a un gatito cada vez que escribo una for-loop.

Cuando se le preguntó cómo evitar bucles, su respuesta fue el uso de un lenguaje funcional. Sin embargo, si usted está atascado con un no-lenguaje funcional, decir C#, ¿qué técnicas existen para evitar bucles o para deshacerse de ellos por la refactorización? Con expresiones lambda y LINQ tal vez? Si es así, ¿cómo?

Preguntas

Así que la pregunta se reduce a:

  1. Por qué son para bucles de malo? O, ¿en qué contexto son para bucles para evitar y por qué?
  2. ¿Puede usted proporcionar el código de C# ejemplos de cómo se ve antes, es decir, con un lazo, y después, sin un bucle?
  • Para los bucles no son malos. Su colega estaba muy equivocada.
  • Él bien podría haber dicho, «no hay que escribir mucho para bucles, te vas a quedar ciego.» Que tiene mucha credibilidad.
  • Para los bucles son los más naturales de construcción para la iteración. Incluso los lenguajes funcionales uso de la iteración (especialmente en el fondo de su código de intérpretes).
  • Un bucle for, en la mecánica Cuántica sería matar el gato de Schrödinger, aunque.
  • No hay una distinción clara entre lo clásico, de longitud fija para los bucles y el más cómodo ba para cada uno de los bucles (que también podría trabajar en secuencias infinitas)? Especialmente el último, se implementó el uso de la máquina de estado basado en los enumeradores y bucles while.
  • «Para los bucles son los más naturales de construcción para la iteración.» <– Más natural no significa necesariamente el más apropiado.
  • «Incluso los lenguajes funcionales uso de la iteración (especialmente en el fondo de su código de intérpretes).» <– yo no estoy seguro de entender lo que quieres decir aquí. Cuidado de explicar?
  • Me refiero a que cada CPU o p-intérprete de código utiliza saltos/ramas para implementar bucles iterativos en el más bajo nivel de la máquina.

InformationsquelleAutor Lernkurve | 2010-04-15

18 Comentarios

  1. 29

    Construcciones funcionales, a menudo expresan su intención más claramente que para los bucles en los casos donde se operan en algunas conjunto de datos y se desea transformar, filtro de conjunto o de los elementos.

    Bucles son muy adecuados cuando se desea ejecutar repetidamente un poco de acción.


    Por ejemplo

    int x = array.Sum();

    mucho más claramente expresa su intención de

    int x = 0;
    for (int i = 0; i < array.Length; i++)
    {
        x += array[i];
    }
    • +1 Esto es similar a lo que ya he mencionado con respecto conjunto de operaciones que ser malo para los bucles.
    • Sí, pero ¿cómo se puede esperar Sum a ser implementado? Esto es realmente un argumento para el uso de métodos, que no evitar for bucles por completo.
    • Tao: me estaba refiriendo a la LINQ Suma método. Por supuesto, en algún lugar tendrá que haber un bucle. Pero podemos construir un buen conjunto de métodos (como el provisto por el LINQ) que los resúmenes de los bucles de distancia y hace que nuestro código mucho más legible.
    • Estoy completamente de acuerdo; mi punto, es que si el OP compañero de trabajo estaba tratando de argumentar que for bucles debe desaparecer completamente, él/ella probablemente fue gravemente equivocada acerca de cómo los métodos, tales como Sum, etc. en realidad el trabajo (es decir, mediante el uso de for bucles).
    • Tao: bueno, de puede implementar Sum utilizar un for-loop, o se puede hacer uso de la recursividad 😉 por supuesto, si usted se centra en los detalles de la implementación, eres realmente va a perder el punto. Para los bucles son un anti-patrón, porque no se puede componer como funciones de orden superior.
    • +1, aunque se debe agregar también un ejemplo en el que un para-bucle tiene sentido 🙂
    • Si usted se centra en los detalles de la implementación, probablemente es porque eres ejecución de algo. No todos somos simplemente los consumidores de los pre-existentes de las bibliotecas que resumen todos los detalles de implementación de distancia de nosotros; también nosotros hemos de crear nuestro propia abstracciones, y poner en práctica nuestro propia funcionalidad, y a veces usamos for bucles (o la recursividad, aunque me seriamente en duda los motivos de cualquier persona que implementó un Sum método que utiliza la recursividad!) para ello. Para mí, llamando for bucles de un «anti-modelo», es como decir que debemos abandonar las uñas porque no podemos construir ciudades fuera de ellos.
    • Tao @Julieta: en realidad, el método de Haskell usos (recursividad) y es muy elegante y «funcional» después de envolver su cabeza alrededor de ella.
    • La aplicación suma el uso de la recursividad no es diferente del uso de un enfoque iterativo cuando se considera el uso adecuado de la cola de la recursividad. Suma es simplemente un caso especial de una forma más general de la secuencia de escaneo y puede ser eficazmente implementado como tal.Usted no necesita un lenguaje funcional para que pueda ser implementado en C# de bien (uso funcional modismos de curso).
    • La recursividad es fina, como siempre y cuando usted tiene suficiente espacio en la pila (o el compilador puede convertir en un interactivas de bucle «automágicamente»).

  2. 16

    Por qué son para bucles de malo? O, en lo que
    contexto son para bucles para evitar y
    por qué?

    Si su compañero tiene una programación funcional, entonces él probablemente ya está familiarizado con las razones básicas para evitar los bucles for:

    Veces /Mapa /cubierta del Filtro de la mayoría de los casos de uso de la lista de recorrido, y se prestan muy bien a la función de la composición. Para los bucles no son un buen patrón, porque no se puede componer.

    La mayoría de las veces, se recorre a través de una lista a veces (agregado), el mapa, o filtro de los valores en una lista. Estos de orden superior a funciones que ya existen en cada corriente de un lenguaje funcional, por lo que rara vez se ve la for-loop lenguaje utilizado en código funcional.

    Funciones de orden mayor son el pan y la mantequilla de la función de la composición, lo que significa que usted puede fácilmente combinar función simple en algo más complejo.

    A dar un no-trivial ejemplo, considere la siguiente en un imperativo idioma:

    let x = someList;
    y = []
    for x' in x
        y.Add(f x')
    
    z = []
    for y' in y
        z.Add(g y')

    En un lenguaje funcional, nos gustaría escribir map g (map f x), o podemos eliminar el intermedio lista con map (f . g) x. Ahora podemos, en principio, eliminar el intermedio de la lista desde el imperativo de la versión, y que podría ayudar un poco, pero no mucho.

    El principal problema con el imperativo de la versión es simplemente que los bucles son detalles de implementación. Si desea cambiar la función, cambia su implementación, y la modificación de una gran cantidad de código.

    Caso en punto, ¿cómo podría usted escribir map g (filter f x) en imperativamente? Bueno, ya que no se puede reutilizar el código original que los mapas y los mapas que necesita para escribir una nueva función que los filtros y los mapas en su lugar. Y si usted tiene 50 maneras de mapa y 50 maneras de filtro, cómo usted necesita 50^50 funciones, o se necesitan para simular la capacidad de pasar funciones como de primera clase de los parámetros utilizando el comando patrón (si alguna vez has tratado de programación funcional en Java, para entender lo que es una pesadilla esto puede ser).

    De vuelta en el funcional del universo, se puede generalizar map g (map f x) en forma que le permite cambiar el map con filter o fold según sea necesario:

    let apply2 a g b f x = a g (b f x)

    Y lo llaman el uso de apply2 map g filter f o apply2 map g map f o apply2 filter g filter f o lo que usted necesita. Ahora usted probablemente nunca escribir código como en el mundo real, probablemente simplificar el uso de:

    let mapmap g f = apply2 map g map f
    let mapfilter g f = apply2 map g filter f

    Funciones de orden superior y la función de la composición de ofrecer un nivel de abstracción que no se puede conseguir con el código imperativo.

    A cabo la abstracción de los detalles de implementación de los bucles vamos que perfectamente intercambiar un bucle para otro.

    Recordar, para los bucles son un detalle de implementación. Si necesita cambiar la aplicación, usted necesita cambiar para cada bucle.

    Mapa /plegable /filtro resumen de distancia del bucle. Así que si usted quiere cambiar la implementación de los bucles, la cambia en esas funciones.

    Ahora usted podría preguntarse por qué te gustaría resumen de distancia de un bucle. Considere la tarea de asignación de elementos de un tipo a otro: generalmente, los elementos se asignan a uno en un momento, de forma secuencial, y en forma independiente de todos los demás elementos. La mayoría del tiempo, mapas como este son los principales candidatos para la paralelización.

    Desafortunadamente, los detalles de la implementación secuencial mapas y paralelo mapas no son intercambiables. Si usted tiene un montón de secuencia de mapas de todo el código, y quieres intercambiar en paralelo de los mapas, usted tiene dos opciones: copiar/pegar el mismo paralelo de asignación de código de todo el código base, o el resumen de distancia de asignación de lógica en dos funciones map y pmap. Una vez que usted es ir a la segunda ruta, ya estás de rodillas en la programación funcional del territorio.

    Si usted entiende el propósito de la función de la composición y la abstracción de los detalles de implementación (incluso detalles tan triviales como un bucle), usted puede comenzar a comprender cómo y por qué la programación funcional es tan poderosa en el primer lugar.

    • Ah, y antes de que algún bromista dice «pero no están mapa, pliegue, y el filtro implementado con fines de bucle!». Respuesta: no siempre. Son fáciles de implementar con recursividad: let fold f seed = function [] -> seed | x::xs -> fold f (f seed x) xs, let map f = [] -> [] | x::xs -> f x::map f xs, y let filter f = [] -> [] | x::xs -> if f x then x::filter f xs or filter f xs.
    • Yo sabía que esto era un Julieta post mucho antes de que yo había desplazado lo suficiente como para confirmarlo. Bien puesto.
    • Muy buena respuesta, no se puede negar que. Pero re: tu comentario acerca de la recursividad: sólo porque algunas de las funciones podrían ser implementadas por el uso de la recursividad tan fácilmente como mediante el uso de un for bucle no implica (a mí, de todos modos) que por lo tanto, es mejor–en el contexto de la aplicación de tales funciones–para evitar for bucles. Es la mendicidad, la pregunta, la verdad. Para mí es como decir: «Usted no debe comer manzanas.» «¿Por qué no?» «Debido a que usted podría comer naranjas, en su lugar.»
    • Lo siento, -1 por no contestar a la pregunta «cómo», y no con C# como se solicitó.
  3. 14
    1. Para los bucles no son malos. Hay muchas razones muy válidas para mantener un bucle for.
    2. Menudo se puede «evitar» un bucle for por trabajarla mediante LINQ en C#, que proporciona una sintaxis declarativa. Esto puede ser bueno o malo dependiendo de la situación:

    Comparar los siguientes:

    var collection = GetMyCollection();
    for(int i=0;i<collection.Count;++i)
    {
         if(collection[i].MyValue == someValue)
              return collection[i];
    }

    vs foreach:

    var collection = GetMyCollection();
    foreach(var item in collection)
    {
         if(item.MyValue == someValue)
              return item;
    }

    vs LINQ:

    var collection = GetMyCollection();
    return collection.FirstOrDefault(item => item.MyValue == someValue);

    Personalmente, las tres opciones tienen su lugar, y yo los uso todos. Es una cuestión de usar la opción más apropiada para su situación.

    • Gracias por la buena ejemplos de código! ¿Cómo sé cuál es el caso en el que el escenario?
    • Personalmente, yo elija en base a los siguientes criterios (en orden): la Corrección, la legibilidad, la facilidad de mantenimiento. El que sea el más fácil de entender tiende a ser la mejor opción de las tres… (Para los bucles son realmente sólo es necesario si necesita el índice, de lo contrario, el uso de foreach o LINQ, de la OMI.)
    • Estoy de acuerdo con el uso De bucles for sólo cuando el índice es necesario. Pero cuando escogerías LINQ frente foreach?
    • Si necesita el índice no necesariamente necesitan de un bucle for. Seleccione((x,i) => …) funciona bien en muchos casos.
    • Cuando es más claro. Normalmente, para mí, esto significa que cada vez que el bucle está tratando de «encontrar» un elemento, filtro, o realizar un mapa del/de la acumulación de operación. Si varias operaciones se producen en el interior del bloque foreach es a menudo más limpio.
    • Definitivamente estoy de acuerdo con respecto a varias operaciones. Cuando usted tiene una tarea compleja que necesita dividirlo en manejable procesal trozos. Si intenta meter a todos en una LINQ declaración se convierte en casi imposible para alguien que no sea el autor de descifrarla, y aun entonces el autor puede tener dificultad para comprender un año después.
    • él realmente es un buen ejemplo de arriba. Si desea realizar una acción en cada uno de los elementos de una colección, un bucle foreach es la adecuada. Sin embargo, si todo lo que quiero hacer es extraer el objeto(s) que coinciden con un criterio determinado, luego de LINQ es una buena opción. Lo normal sería encontrar un foreach que ocurren en el LINQ resultados más adelante en el código, como una cuestión de hecho.
    • En estos días que en su mayoría utilizan sintaxis funcional y caer de nuevo a la bucles cuando:- A. El cuerpo del bucle contiene una lógica compleja que no puede ser desenredado en un limpiador de aplicación secuencial de funciones y simplemente más fácil escribir un bucle con el complejo de código condicional en ella. B. La tarea es inherentemente no funcional, es decir, tiene efectos secundarios C. La tarea necesidades de manejo de excepciones en ella. Asegúrese de que usted puede escribir grandes lambda bloques try catch en ellos, pero en algún momento se vuelve más fácil y más limpio sólo para usar un for-loop.
    • Gracias por la aclaración. No he tenido suficiente de LINQ experiencia por lo que es digno de un buen aprendizaje.
    • Muchas veces cuando varias operaciones se producen en el interior del bloque puede ser fácilmente reestructurado como una secuencia de la función de las aplicaciones. Es sólo cuando los múltiples operaciones de interactuar en un no-funcional o tienen efectos secundarios que usted necesita para utilizar un procedimiento de bucle. Acaba de tener múltiples operaciones no es una razón para ir de procedimiento.
    • Cierto, sin embargo, muchas veces, va «funcional» por el bien de ir funcional sólo perjudica a la capacidad de mantenimiento, así. Como ya he dicho, para mí, es todo acerca de ser correcta, entonces es fácil de mantener (me encanta la programación declarativa, por lo que yo lo uso en el sentido que tiene…)

  4. 14

    No hay nada de malo con bucles, pero aquí están algunas de las razones por las que la gente puede preferir funcional/declarativa enfoques como LINQ, donde se declara lo que quiere en lugar de cómo conseguirlo:-

    1. Enfoques funcionales son potencialmente más fácil de poner en paralelo de forma manual utilizando PLINQ o por el compilador. Como CPUs mover a más núcleos de esto puede ser más importante.

    2. Enfoques funcionales más fácil alcanzar la evaluación diferida en multi-procesos de paso, porque puede pasar que los resultados intermedios para el siguiente paso como una simple variable que no ha sido evaluado plenamente sin embargo, en lugar de evaluar el primer paso completamente y, a continuación, pasar de una colección para el siguiente paso (o sin el uso de un método independiente y un rendimiento de instrucción para lograr el mismo procedimiento).

    3. Enfoques funcionales son a menudo más corto y fácil de leer.

    4. Enfoques funcionales a menudo eliminar condicionales complejas cuerpos dentro de bucles (por ejemplo, si las declaraciones y ‘continuar’ declaraciones) porque se puede romper el bucle hacia abajo en pasos lógicos – la selección de todos los elementos que coinciden, haciendo una operación sobre ellos, …

    • La lista es útil, gracias.
  5. 8

    Para los bucles no matan a la gente (o los gatitos o cachorros, o de los siete mares). Las personas matan a las personas.
    Para los bucles, en y de sí mismos, no son malos. Sin embargo, como con cualquier otra cosa, es la forma de usarlos, eso puede ser malo.

    • Para los bucles no matan a la gente, pero goto sin duda lo hace. xkcd.com/292
    • Él estaba hablando acerca de matar a los gatitos, no a las personas. Usted está fuera de tema, j/k +1
    • Pero, ¿la gente matar gatitos? Sólo Harkonnens, tal vez.
    • lol, es verdad, yo estaba parafraseando el dicho popular que dice acerca de las armas de fuego.
    • los fremen matar harkonen, no los gatitos.
    • +1 para los siete mares
    • Me refería a que quizás los Harkonnen matar gatitos. Pero los gatitos de matar a alguien?
    • Yo diría que depende del contexto:) stackoverflow.com/questions/2640236/…
    • Se puede matar a la legibilidad, aunque, lista.Contiene(«foo») vs un bucle for, por ejemplo.
    • Charles de curso de los Harkonen matar gatitos(y los cachorros, y de los siete mares). no estaría Harkonen si no.
    • GOTO no matar a la gente, sin restricciones de uso de GOTO hace. Consulte david.tribble.com/text/goto.html.
    • los bucles son los nuevos goto. 🙂
    • Lo siento, -1 por no contestar a la pregunta «cómo». Su respuesta es más de un comentario.

  6. 6

    En algún momento usted no matar solo un gatito.

    for (int i = 0; i < gatitos.Longitud; i++)
    {
    gatitos[i].Kill();
    }

    A veces matar a todos ellos.

    • Mal OO. ¿Por qué un método denominado Kill dentro de la clase Kitten matar a sí mismo? Usted debe cambiar kittens[i].Kill() a God.Kill(kittens[i]). +1 para el humor, aunque.
  7. 5

    Puede refactorizar el código lo suficientemente bien como para que no se vea a menudo. Un buen nombre de la función es definitivamente más fácil de leer que un bucle for.

    Tomando el ejemplo de AndyC :

    Bucle

    //mystrings is a string array
    List<string> myList = new List<string>();
    foreach(string s in mystrings)
    {
        if(s.Length > 5)
        {
            myList.add(s);
        }
    }

    Linq

    //mystrings is a string array
    List<string> myList = mystrings.Where<string>(t => t.Length > 5)
                                   .ToList<string();

    Sitos que el uso de la primera o la segunda versión en el interior de su función, Es más fácil de leer

    var filteredList = myList.GetStringLongerThan(5);

    Ahora que es demasiado simple ejemplo, pero se entiende mi punto.

    • Buen punto, gracias.
  8. 3

    Su colega no es correcto. Para los bucles no son malos per se. Son limpias, legible y no es particularmente propenso a error.

  9. 3

    Su colega está equivocado acerca de los bucles de ser malo en todos los casos, pero correcta que puede ser reescrito funcionalmente.

    Dicen que usted tiene un método de extensión que tiene este aspecto:

    void ForEach<T>(this IEnumerable<T> collection, Action <T> action)
    {
        foreach(T item in collection)
        {
            action(item)
        }
    }

    A continuación, puede escribir un bucle como este:

    mycollection.ForEach(x => x.DoStuff());

    Esto puede no ser muy útil ahora. Pero si usted, a continuación, reemplace la implementación de la ForEach método de extensión para utilizar una de múltiples subprocesos enfoque, a continuación, se obtienen las ventajas del paralelismo.

    Obviamente, esto no siempre va a funcionar, esta aplicación sólo funciona si el bucle de iteraciones son completamente independientes el uno del otro, pero puede ser útil.

    También: desconfíe siempre de las personas que dicen algunos de programación de la construcción es siempre malo.

  10. 2

    Un simple (y sin sentido realmente) ejemplo:

    Bucle

    //mystrings is a string array
    List<string> myList = new List<string>();
    foreach(string s in mystrings)
    {
        if(s.Length > 5)
        {
            myList.add(s);
        }
    }

    Linq

    //mystrings is a string array
    List<string> myList = mystrings.Where<string>(t => t.Length > 5).ToList<string>();

    En mi libro, la segunda parece mucho más ordenado y más simple, aunque no hay nada malo con la primera.

    • Donde<cadena>() devuelve IEnumerable<cadena>, no de la Lista de<Cadena>. No importa, usted puede escribir su ejemplo como var milista = mistrings.Donde(t => t.Longitud > 5); de todos modos.
    • Me fijo antes de ver este comentario, pero bien manchado! 🙂
    • Puede dejar fuera de la <string> las anotaciones en los métodos de LINQ para más conciso de código que el compilador es lo suficientemente inteligente como para entender lo que significa.
  11. 1

    A veces un bucle es mala, si no existe una alternativa más eficiente. Tales como la búsqueda, donde puede ser más eficaz para ordenar una lista y, a continuación, utilizar quicksort o el orden binario. O cuando se iterar sobre los elementos de una base de datos. Normalmente es mucho más eficiente utilizar el conjunto de operaciones basadas en una base de datos en lugar de iterar sobre los elementos.

    Lo contrario, si el para-loop, especialmente para cada uno de los que tiene más sentido y es legible, a continuación, me gustaría ir con los que en lugar de rafactor en algo que no es tan intuitivo. Yo personalmente no creo en esas religiosas que suena «siempre hacerlo de esta manera, debido a que es la única manera». Es mejor tener directrices, y comprender en qué casos es apropiado para aplicar esas directrices. Es bueno que se pregunte el por Qué!

  12. 1

    Bucle For es, digamos, «malo», ya que implica la rama de la predicción en la CPU, y posiblemente una disminución del rendimiento cuando la rama de predicción de la señorita.

    Pero la CPU (que tiene una rama de la exactitud de la predicción de 97%) y el compilador con técnicas como el bucle desenrollado, hacer que el rendimiento del circuito de reducción insignificante.

    • Dado que la mayoría de las Cpu no tiene instrucciones para operar en todo el conjuntos de datos, el código funcional normalmente se convierte en un bucle de todos modos, así que no hay rara vez (si alguna vez) una mejora en la eficiencia.
    • Estás en lo correcto. Además, me gustaría aclarar que LINQ no es funcional, se utiliza bucles de todos modos.
  13. 1

    Un bucle for que siempre puede ser sustituido por una función recursiva que no implican el uso de un bucle. Una función recursiva es una más funcional orzuelo de programación.

    Pero si usted ciegamente reemplazar por bucles de funciones recursivas, a continuación, los gatitos y perritos en ambos mueren por millones, y será realizado en un velocirapter.

    OK, aquí un ejemplo. Pero por favor, tenga en cuenta que no soy partidario de hacer este cambio!

    El bucle for

    for (int index = 0; index < args.Length; ++index)
        Console.WriteLine(args[index]);

    Puede ser cambiado a esta llamada a la función recursiva

    WriteValuesToTheConsole(args, 0);
    
    
    static void WriteValuesToTheConsole<T>(T[] values, int startingIndex)
    {
        if (startingIndex < values.Length)
        {
            Console.WriteLine(values[startingIndex]);
            WriteValuesToTheConsole<T>(values, startingIndex + 1);
        }
    }

    Esto debería funcionar de la misma para la mayoría de los valores, pero es mucho menos clara, menos eficiente, y puede agotar la pila si la matriz es demasiado grande.

    • Gracias. ¿Puede dar un ejemplo de código para esa sustitución?
  14. 1

    Su compañero puede ser lo que sugiere que bajo ciertas circunstancias en donde los datos de base de datos, es mejor utilizar una función SQL agregada como la Media() o Suma() en el momento de la consulta como se opuso a que el procesamiento de los datos en el C# secundarios dentro de un ADO .NETO de la aplicación.

    De otra manera para los bucles son muy eficaces cuando se utilizan correctamente, pero se dan cuenta que si usted se encuentra anidación de tres o más órdenes, usted puede ser que necesite un algoritmo mejor, como el que implica la recursividad, subrutinas o ambos. Por ejemplo, una especie de burbuja tiene un O(n^2) tiempo de ejecución en el peor caso (orden inverso) escenario, pero un recursiva del algoritmo de ordenación es sólo O(n log n), que es mucho mejor.

    Esperemos que esto ayuda.

    • Jim
  15. 0

    Cualquier construir en cualquier idioma está ahí por una razón. Es una herramienta que se utiliza para realizar una tarea. Medio para un fin. En todo caso, hay maneras en las que utilizarlo de forma adecuada, es decir, en una forma clara y concisa y en el espíritu de la lengua Y las costumbres de abusar de él. Esto se aplica a la muy desalineados goto declaración, así como a su for bucle enigma, así como while, do-while, switch/case, if-then-else, etc. Si el for bucle es la herramienta adecuada para lo que va a hacer USO de ÉL y su colega se necesita para venir a los términos con su decisión de diseño.

  16. 0

    Que depende de lo que está en el circuito, pero él/ella puede estar refiriéndose a una función recursiva

        //this is the recursive function
        public static void getDirsFiles(DirectoryInfo d)
        {
            //create an array of files using FileInfo object
            FileInfo [] files;
            //get all files for the current directory
            files = d.GetFiles("*.*");
    
            //iterate through the directory and print the files
            foreach (FileInfo file in files)
            {
                //get details of each file using file object
                String fileName = file.FullName;
                String fileSize = file.Length.ToString();
                String fileExtension =file.Extension;
                String fileCreated = file.LastWriteTime.ToString();
    
                io.WriteLine(fileName + " " + fileSize + 
                   " " + fileExtension + " " + fileCreated);
            }
    
            //get sub-folders for the current directory
            DirectoryInfo [] dirs = d.GetDirectories("*.*");
    
            //This is the code that calls 
            //the getDirsFiles (calls itself recursively)
            //This is also the stopping point 
            //(End Condition) for this recursion function 
            //as it loops through until 
            //reaches the child folder and then stops.
            foreach (DirectoryInfo dir in dirs)
            {
                io.WriteLine("--------->> {0} ", dir.Name);
                getDirsFiles(dir);
            }
    
        }
  17. 0

    Si usted resumen el for bucle directamente se obtiene:

    void For<T>(T initial, Func<T,bool> whilePredicate, Func<T,T> step, Action<T> action)
    {
        for (T t = initial; whilePredicate(t); step(t))
        {
            action(t);
        }
    }

    El problema que tengo con esto de la programación funcional, la perspectiva void tipo de retorno. Esto esencialmente significa que for bucles de no redactar muy bien con cualquier cosa. Por lo que el objetivo no es tener un 1-1 conversión de for bucle para alguna función, es pensar funcionalmente y evitar hacer cosas que no componen. En lugar de pensar en bucle y de actuar pensar en la totalidad del problema y de lo que son la asignación de y.

    • Oh lordy espero que nadie podría escribir un orden superior For función como eso. Trate de void Iter<T>(Action<T> f, IEnumerable<T> items) { foreach(item item in items) f(item); } lugar.
    • Ese es exactamente mi punto. for no tiene un tipo de interés de la firma.
  18. 0

    La pregunta es si el bucle será la mutación de estado o de causar efectos secundarios. Si es así, utilice un bucle foreach. Si no, considere el uso de LINQ u otras construcciones funcionales.

    Ver «foreach» vs «ForEach» en Eric Lippert del Blog.

Dejar respuesta

Please enter your comment!
Please enter your name here