¿Una clase por regla de archivo en .NET? [cerrado]

185

Sigo esta regla, pero algunos de mis colegas no están de acuerdo con ella y argumentan que si una clase es más pequeña, se puede dejar en el mismo archivo con otras clases.

Otro argumento que escucho todo el tiempo es "Incluso Microsoft no hace esto, entonces ¿por qué deberíamos hacerlo?"

¿Cuál es el consenso general sobre esto? ¿Hay casos en los que esto debe evitarse?

Joan Venge
fuente
1
posible duplicado de clases

Respuestas:

176

Una clase por archivo también le da una mejor idea de lo que está cambiando cada registro sin mirar las diferencias del archivo.

marca
fuente
44
Más clases en el mismo archivo mejora la diferencia entre clases relacionadas en una sola operación.
Luca
3
Los visores de diferencias adecuados le permiten ver todos los diferenciales de una confirmación.
Dykam
44
No estoy completamente seguro de cómo esta respuesta en particular es LA respuesta a la (s) pregunta (s) de la publicación original. Claro que proporciona una razón para mantener 1 clase en un archivo (aunque Luca y Dykam hacen buenos puntos), pero no refleja el consenso general ni proporciona casos en los que debería evitarse.
Robert Davis
44
Las mejores prácticas no existen; si cree en las mejores prácticas, comprenda que solo se aplican a un contexto determinado. Como otras respuestas señalan, hay momentos en que esta regla realmente creará un código menos mantenible. A medida que las herramientas mejoran, esta regla realmente se vuelve menos relevante, ya que es mucho más fácil encontrar clases y tipos dentro de un proyecto.
abombss
263

Odio cuando la gente piensa en absoluto y dice que nunca debes hacer esto o aquello con algo subjetivo y quisquilloso como este, como si todos tuviéramos que conformarnos con la estúpida idea de lo correcto y lo incorrecto de alguien. En pocas palabras: tener más de una clase por archivo está totalmente bien si tiene sentido. Por tiene sentido me refiero a cosas como:

  1. Hace que el código sea más fácil de digerir y mantener
  2. Hace que la solución sea menos molesta (desplazarse por innumerables archivos innecesarios) y menos lenta
  3. El equipo de desarrollo está de acuerdo con esto como práctica de codificación local.

Un muy buen ejemplo de por qué podría querer varias clases por archivo:

Supongamos que tengo unas pocas docenas de clases de excepción personalizadas, cada una tiene un revestimiento de 4, podría tener un archivo separado para cada una o podría agrupar las excepciones y tener un archivo por grupo. Para mí, lo que parece el enfoque más racional / pragmático es agruparlos y solo tener algunos archivos, porque es más eficiente en cuanto a tiempo / codificación (no tengo que hacer clic derecho -> Agregar clase, renombrar, 50 veces) , mantiene la solución menos abarrotada y con un mejor rendimiento.

James
fuente
92
+1,000. Comprender la justificación de las mejores prácticas y pensar dos veces antes de violarlas es genial. La adhesión esclava es malvada.
dsimcha
19
¿Algunas docenas de clases de excepción personalizadas ? ¿No es esa la verdadera fuente del problema? No solo quiero ser quisquilloso aquí: creo que la mayoría de las veces la gente quiere combinar clases en un solo archivo, es porque innecesariamente crean demasiados tipos. (Dicho esto, quizás haya un caso real en el que tengan sentido unas pocas docenas de clases de excepción personalizadas). Numerosas clases pequeñas, no operativas, son normalmente un signo de un problema mayor.
Jeff Sternal
16
Estoy de acuerdo contigo en la mayor parte. Pero las excepciones son un caso especial. Debido a que un sistema correctamente diseñado necesita tener un manejo de excepciones adecuado para tratar todos los casos que producen errores legítimos, la mayoría de los artículos de mejores prácticas que he leído enfatizan la necesidad de crear excepciones específicas (y algunas veces necesita muchos de ellos para cubra todas las reglas comerciales en un proyecto grande) para que no termine atrapando system.exception, que no es el manejo adecuado de excepciones en absoluto.
James
66
Estoy de acuerdo en que no debe seguir servilmente alguna directriz sin una buena razón, sin embargo, no estoy de acuerdo con el hecho de que debería tener más de una clase en un archivo. Para mí, el archivo debe tener el nombre de la clase y no contener más de uno. Algunos idiomas (java es uno) toman nota de que realmente hacen cumplir que la clase está en un archivo con el nombre del archivo que coincide con el nombre de la clase. Para mí, es más fácil para los recién llegados navegar, por eso creo que una clase por archivo es lo correcto
krystan honor
3
Mantener una clase por archivo y mantener el nombre del archivo y el nombre de la clase sincronizados es una convención, al igual que nombrar variables. Visual Studio está muy bien ajustado para este enfoque. Es más fácil para los sistemas de control de código fuente y los desarrolladores que se agregan en la mitad del proyecto. Buscarán intuitivamente el nombre del archivo que coincida con el nombre de la clase.
Oybek
75
static bool GeneralRuleShouldBeFollowed(IGeneralRule rule, IUseCase useCase)
{
    return (rule.Overhead(useCase) 
            < My.PersonalThresholds.ConformismVsPracticality);
}
Jeremy Bell
fuente
44
¿Hay una regla como esa en .NET? Yo también habría devuelto el resultado de la declaración. : O
Joan Venge
50

A veces agrupo más de una clase dentro de un archivo si están estrechamente acoplados y al menos uno de ellos es muy pequeño.

La 'mejor práctica' general es tener un archivo por clase.

Phil Rykoff
fuente
77
Si reconoce que están acoplados, ¿por qué no los desacopla?
El Matt
39
@ The Matt: Se llama evitar la sobreingeniería. Si tiene algunas clases estrechamente acopladas y las desacoplará, agregaría mucha complejidad en comparación con la cantidad de flexibilidad práctica que proporciona, entonces, ¿cuál es el punto?
dsimcha
9
A veces me gustan básicamente las clases de "datos" que solo usa esta clase, por lo que generalmente pongo la clase de datos en el mismo archivo que el usuario porque el datac-lass generalmente tiene poca o ninguna lógica en sí misma y parece un desperdiciar para crear un nuevo archivo para él.
Earlz
3
@ The Matt: A veces hay clases auxiliares que yo diría que son aceptables para el acoplamiento. Reducen la complejidad de parte de otra clase pero aún facilitan un propósito muy específico para esa clase.
Jordan Parmer
66
@TheMatt: Desacoplar esto: msdn.microsoft.com/en-us/library/… El acoplamiento entre módulos es malo, pero la colaboración entre clases dentro de una característica lógica es inevitable.
Ben Voigt
25

Más allá de argumentos hipotéticos y enfocándose en Windows .NET con Visual Studio IDE y proyectos de software en crecimiento, tiene sentido en este contexto tener una clase por archivo.


En general, para referencia visual, nada supera una clase por archivo. De Verdad.

No sé si Microsoft hace o no lo mismo, sin embargo, crearon la partialpalabra clave para dividir una clase en varios archivos (esto es aún más grave). A menudo se usa para dividir el código de diseñador generado automáticamente de su código personalizado en la misma clase (pero a veces se usa para permitir que diferentes desarrolladores trabajen en la clase al mismo tiempo a través de diferentes archivos). Por lo tanto, Microsoft ve los beneficios de múltiples archivos y todos tienen en mente múltiples ideas de organización de archivos con seguridad con .NET.

Para las clases anidadas no tiene más remedio que usar un archivo, o al menos las primeras partes de las clases en ellas. Un archivo es necesario y está bien en este caso:

class BicycleWheel {
    class WheelSpoke {
    }
}

De lo contrario, ¿por qué mantendría múltiples clases en un archivo? El argumento "porque son pequeños" o asociados entre sí sí no retiene mucha agua porque eventualmente sus clases se asociarán con otras clases. En última instancia, no se puede inferir fácilmente la organización en el archivo de los objetos en función de su uso, especialmente a medida que el software continúa creciendo.

Además, si usa carpetas para espacios de nombres , nunca tendrá un choque de nombre de archivo de clase. También es conveniente ubicar una clase por nombre de archivo en el sistema de archivos cuando no está dentro de un entorno de desarrollo como Visual Studio (por ejemplo, si desea editar rápidamente una clase con el Bloc de notas o algo rápido / ligero ).

Tantas buenas razones ...

John K
fuente
Gracias, ¿qué quieres decir con "al menos las primeras partes de ellos"? ¿Quiere decir que también puede separar clases anidadas?
Joan Venge
1
Esa es una referencia indirecta a la partialpalabra clave que mencioné.
John K
1
Para el registro, las clases anidadas pueden ser partial msdn.microsoft.com/en-us/library/wa80x488(VS.80).aspx Lo busqué por curiosidad.
John K
Esto solo muestra que la vista predeterminada debe ser lógica (espacio de nombres / clase) y no física (archivos).
David Schmitt
@DavidSchmitt para eso es Class View en Visual Studio.
Zack
14

En la gran mayoría de los casos, sigo la regla de una clase por archivo. La única excepción que hago regularmente es la definición de una enumeración que está estrechamente vinculada a una clase específica. En ese caso, frecuentemente incluiré la definición de la enumeración en el archivo de esa clase.

Greg D
fuente
12

Yo también creo que debería haber un tipo incluido en un solo archivo.

Hay una excepción a esta regla que debe mencionarse: tener dos clases que difieren solo por un argumento genérico como:

RelayCommand     

y

RelayCommand<T>
Andrei Rinea
fuente
¿Conoces la solución para hacer feliz a StyleCop en este caso?
George Polevoy
No estoy de acuerdo, hay otra convención para las clases genéricas, Foo 1.cs for Foo <T> `y Foo 2.cs for Foo <T, T1>`.
Oybek
@Oybek: ¿Qué pasa si tengo Foo <T>, Foo <U> y Foo <U, T>? ¿Ahora que?
Andrei Rînea
@AndreiRinea Es imposible tenerlo Foo<T>y Foo<U>dentro del mismo espacio de nombres. Pero si los espacios de nombres difieren, generalmente están en carpetas diferentes. Por lo tanto, para Foo<T>y Foo<U>debería ser Foo 1.cs and for Foo <U, T> `Foo`2.cs. Pero todavía una clase por archivo.
Oybek
¡Gracias por la información! :)
Andrei Rînea
8

Realmente, esto se reduce a preferencias personales. Todos dirán "una clase por archivo", pero todos tenemos nuestras razones para evitar eso en ciertas circunstancias. Solía ​​tener un gran proyecto que tenía alrededor de 300 enumeraciones diferentes. De ninguna manera voy a tener 300 archivos separados, uno para cada clase, cuando algunas de las enumeraciones solo eran de tres estados.

Además, para las personas que no pueden encontrar ciertas clases si no están todas en archivos con el nombre de lo que son, ¿hay alguna razón por la que no utilices Buscar buscando en toda la solución? Usar Find me ahorra un tiempo valioso al desplazarme por el Explorador de soluciones.

Jason M
fuente
Re: find: cuando busco la definición de un tipo, no quiero ver dónde se usa. Además, find lleva mucho más tiempo que desplazarse por una lista ordenada alfabéticamente de archivos que probablemente ya he dividido (por espacio de nombres).
Jeff Sternal
1
Noté que has indicado que estás trabajando con algo que has dividido por espacio de nombres. Desafortunadamente, no todos tenemos la suerte de trabajar siempre con proyectos que hemos podido gestionar.
Jason M
6

No importa cuán liviano sea el contenido, creo que una clase / interfaz / etc. por archivo es esencial.

Si estoy trabajando en una gran solución en Visual Studio, quiero poder ver los archivos y no tener que profundizar para verlos. Incluso con herramientas de navegación como ReSharper, quiero un mapeo 1: 1.

Si encuentra muchos archivos fuente con poco o ningún contenido (tal vez extendiendo una clase pero sin agregarle nada), entonces tal vez debería repensar su diseño.

Michael
fuente
5

Encuentro que agrupar una clase con su clase estándar de fábrica en el mismo archivo es muy útil.

Robert Davis
fuente
5

Normalmente tendría una clase por archivo, pero normalmente tendría que usar su discreción para ver si el archivo podría contener clases relacionadas, por ejemplo, agrupar sus excepciones que usted y otros desarrolladores pueden reutilizar. En este caso, el usuario solo necesita incluir un archivo en lugar de varios archivos.

Entonces el punto es: ¡se debe usar la discreción !

Akapetronics
fuente
1
La verdadera sabiduría, ninguna regla en la programación es dura y rápida.
ChaosPandion
4

En soluciones más grandes, creo que es muy valioso tener una clase por archivo y que el archivo tenga el mismo nombre que la clase. Hace que sea mucho más fácil localizar el código en el que necesita trabajar.

Chris Clark
fuente
Este argumento me parece menos valioso con herramientas como ReSharper. Hago CTRL + T y empiezo a escribir el nombre del tipo que estoy buscando.
Mark
3
Sí, pero ¿desea que la estructura de su aplicación dependa de una herramienta de terceros?
Magnus
1
@magnus No estaba diciendo que esta no sea una razón para no hacerlo, sino un argumento menos convincente para que alguien lo haga.
Mark
4

La herramienta StyleCop para C # tiene reglas estándar que no requieren más de una clase de nivel superior en un espacio de nombres (más cualquier número de interfaces, delegados y enumeraciones en ese espacio de nombres).

En los casos de dos o más clases en las que la segunda y las clases posteriores solo son utilizadas por la primera, esas podrían y deberían ser clases internas, visibles solo para la clase consumidora.

Steve Gilham
fuente
3
Cuando dice "no más de una clase de nivel superior en un espacio de nombres", quiere decir en un namespacebloque, ¿verdad?
Daniel Pryden
1
Las reglas aludidas son SA1403: el documento AC # solo puede contener un espacio de nombres único. SA1402: el documento AC # solo puede contener una sola clase en el nivel raíz, a menos que todas las clases sean parciales y sean del mismo tipo.
Steve Gilham
4

En algún momento una clase por archivo, pero ...

Cuando varias clases están estrictamente relacionadas, más de una clase en el mismo archivo fuente es, en mi humilde opinión, MEJOR que dedicar un archivo fuente corto a cada clase. La fuente es más legible y compacta (y usando #region, la misma fuente puede estar más estructurada que antes).

Considere también que a veces es NECESARIO distribuir la misma clase en diferentes archivos (usando parcial ), ya que tener un archivo fuente de más de 20000 líneas no es útil incluso con la RAM que tengo disponible (pero esta es otra pregunta).

Luca
fuente
Por supuesto, debe intentar evitar tener una clase con tantas líneas de código. Yo diría que incluso 1000+ se está volviendo demasiado grande. También me doy cuenta de que esto no siempre es posible en el código heredado.
Peter
Si intenta generar el código fuente (mi caso es la generación de C # vinculante para OpenGL a partir de su especificación, que tiene miles de puntos de entrada) es difícil pensar en una pequeña clase para una gran cantidad de datos ...
Luca
3

En ocasiones, dejaré una clase pequeña con una clase más grande, pero solo si están muy estrechamente relacionados como un objeto y es una clase de colección o una fábrica.

Sin embargo, hay un problema con esto. Finalmente, la clase pequeña crece hasta el punto en el que debería estar en su propio archivo, si la mueve al nuevo archivo pierde el acceso fácil a su historial de revisiones.

es decir.

  • el lunes hago un cambio en mis clases x e y en el archivo y.css
  • el martes separé la clase x en su propio archivo x.css porque ha crecido demasiado
  • el miércoles mi jefe quiere ver lo que cambié en la clase x el lunes, así que mira el historial de x.css, solo que x.css no muestra el historial antes de que los martes cambien.
pan de jengibre
fuente
1
¿Qué sucede si la "clase pequeña" es algo así como un derivado de EventArgs, que está destinado a pasar información a los destinatarios de los eventos de su clase? ¿Se haría el código más limpio o más fácil de mantener moviendo tal cosa a otro archivo? Podría decirse que tal cosa debería ser una clase pública anidada, pero también parece estar mal vista. En cuanto al historial de revisiones, ¿no habría aparecido la clase de la nada en el registro de cambios, y no debería haber un comentario en la nota del código de dónde vino?
Supercat
Clasificaría eso como una very tightly relatedclase y lo dejaría siempre que solo ocupe una pequeña cantidad de espacio en la pantalla y ninguna otra clase lo use con el mismo propósito.
gingerbreadboy
3

¿Es realmente un problema? :) Las
clases realmente pequeñas, al igual que las enumeraciones, se pueden juntar con otras. Hay una regla a seguir: reunir solo clases que tengan algo en común.

Como una digresión, en uno de mis proyectos tengo un archivo que tiene 150 clases dentro. El archivo tiene 10000 líneas de código. Pero se genera automáticamente, por lo que es totalmente aceptable :)

IamDeveloper
fuente
1
Tengo un mismo archivo con 120 clases y 750 subclases con medio millón de líneas, también se genera automáticamente. El problema es: si hago clic en él, debo reiniciar porque todo se detiene.
Behrooz
3

Una razón para poner varias clases relacionadas en un archivo es para que el bastardo pobre que usa su API no tenga que pasar medio día escribiendo el boilerplate de la declaración de importación y el bastardo pobre que tiene que mantener el código no tiene que gastar la mitad un día desplazándose a través de repeticiones de declaración de importación. Mi regla general es que varias clases pertenecen al mismo archivo si casi siempre usa un gran subconjunto de ellas al mismo tiempo en lugar de solo una a la vez.

dsimcha
fuente
1
¿Qué quiere decir con "declaración de importación boilerplate"? "¿Usando declaraciones"? ¿Pero no van a estar las clases en el mismo espacio de nombres?
Joan Venge
3
@Joan: me refiero a tener que importar 15 módulos diferentes pero relacionados para lograr algo realmente simple. Tal vez no se aplica específicamente a C #. Realmente no sé C #, pero en otros idiomas es un problema bastante molesto.
dsimcha
Gracias, sí, por eso estaba confundido.
Joan Venge
2

Hago esto, pero solo cuando las clases están relacionadas de una manera padre-hijo y las clases hijo SOLO son utilizadas por el padre.

CResultados
fuente
Gracias, pero ¿por qué no lo separas en otro archivo? Sólo curioso.
Joan Venge
@henchman lo ha dicho mucho más elocuentemente que yo, especialmente cuando el objeto hijo es muy pequeño. Es Normalamente el caso de que la clase hijo es única con propiedades quizás sólo un poco de lógica
CResults
2

Por lo general, me quedo con una clase por archivo. Pero haré excepciones para grupos de construcciones similares que se utilizan en todo el proyecto. Por ejemplo:

  • Un EventArgs.cs que contiene EventArgssubclases, ya que generalmente son solo 5-10 líneas de código cada una, pero generalmente son utilizadas por varias clases diferentes. Alternativamente, podría poner las EventArgsclases en el mismo archivo que la clase que declara los eventos.
  • Un Delegates.cs que contiene Delegados que se utilizan en todo el proyecto, ya que generalmente son solo 1 línea cada uno. Una vez más, la alternativa es colocarlos en el mismo archivo con la clase que los expone / consume.
  • Un Enums.cs que contiene enums utilizados en todo el proyecto. (Si hay una enumque solo usa una clase, generalmente llegaré privatea esa clase).
Daniel Pryden
fuente
2

Otra votación para una clase por archivo con el nombre del archivo igual a la clase. Para mí, ayuda con la mantenibilidad a largo plazo. Puedo mirar fácilmente a través del repositorio y ver qué clases son parte de una solución sin tener que abrir el proyecto ni ninguno de los archivos.

Tim Scarborough
fuente
2

Lo sigo el 99% del tiempo. Es bueno seguir los estándares, pero también creo que la flexibilidad tiene su lugar. A veces parece una tonta pérdida de tiempo separar las cosas. En esos momentos, me supero y solo escribo mi código.

Mike Pateras
fuente
2

Las respuestas hasta ahora parecen girar en torno a las excepciones de las personas a la regla, así que aquí está la mía: mantengo las clases y sus clases de 'amigos' de metadatos juntas cuando uso el paquete DataAnnotations en .NET3.5 SP1. De lo contrario, siempre están en archivos separados. Ya sabes, la mayor parte del tiempo. Excepto cuando no lo son.

Brant Bobby
fuente
2

Solo hago esto raramente. Por ejemplo, si hay una enumeración o estructura que está estrechamente relacionada con la clase pero que es demasiado trivial para separarse por sí sola.

O una clase separada para contener algunos métodos de extensión para esa clase principal.

puffpio
fuente
1

One case could be:cuando sus clases forman conjuntamente una clase module / unitque sirve a algunas clases principales como helper classes, por lo demás, no .

Eche un vistazo al código fuente del proyecto ASP.NET MVC 2.0 . Sigue estrictamente esta regla

Asad
fuente
1

Me gusta la idea de crear clases más pequeñas y asegurarme de que la clase solo haga lo que se supone que debe hacer. Si tiene varias clases que contribuyen a resolver un solo problema, entonces no hay nada de malo en juntarlas en el mismo archivo.

¡No seguiría las prácticas de EM ya que no son las MEJORES PRÁCTICAS!

azamsharp
fuente
1

Otro punto que no he visto mencionar a nadie más es que cuando desarrollas usando la regla de una clase por archivo, puedes ver fácilmente qué está usando esa clase específica.

Por ejemplo: puede tener dos clases donde una clase usa Linq y la otra no.

Si estas clases estuvieran en el mismo archivo, no podría saber sin mirar a través del código qué clase usa qué. Cuando se trata de una clase por archivo, todo lo que tiene que hacer es mirar la parte superior del archivo para ver exactamente qué se está utilizando en esa clase. Ayuda si alguna vez está migrando a una nueva biblioteca, etc.

Kieran Oldham
fuente
0

Otra razón para una clase por archivo que no se ha mencionado en las respuestas publicadas hasta ahora es que una clase por archivo facilita la comprensión del impacto de un RP durante una revisión de código. También reduce los conflictos de fusión.

Cuando alguien publica un RP para recibir comentarios, puedo mirar la lista de archivos modificados e inmediatamente ver cualquier superposición con lo que podría estar trabajando. Dependiendo de la superposición, es posible que desee ver su código más profundamente o darle un visto bueno porque estoy bastante seguro de que no afectará mis propios cambios.

Cuando dos personas trabajan en un archivo de varias clases y ambas agregan una dependencia, existe una buena posibilidad de que se produzca un conflicto de fusión en el using bloque en la parte superior. La separación de las clases en archivos separa las dependencias para que pueda ver qué está usando cada clase y no obtener conflictos como este.

Hay excepciones a esta regla (interfaz + implementación, enumeraciones, ...) pero es un mejor punto de partida que lo contrario, lo que generalmente permite a los desarrolladores junior agrupar todo tipo de clases no relacionadas en el mismo archivo.

Una clase por archivo es una regla clara e inequívoca que no está sujeta a interpretación.


Las clases relacionadas en un archivo están sujetas a preferencias personales e interpretación (como puede ver en todas las otras respuestas aquí en cuanto a cuándo está bien usar) y, por lo tanto, es una regla deficiente.

Ian Mercer
fuente
-1

La ida y vuelta ha sido muy interesante y aparentemente poco concluyente, aunque mi impresión general es que un mapeo 1-1 entre clases y archivos es la opinión mayoritaria, aunque con algunas excepciones persona por persona.

Tengo curiosidad por saber si alguna de sus respuestas varía según si: (1) está desarrollando una aplicación de formularios Windows Forms, una aplicación web, una biblioteca o lo que sea; o (2) usando Visual Studio o no. Al usar VS, parecería que la regla de una clase por archivo también implicaría una clase por proyecto de VS ya que el consenso en otros hilos parece ser que las soluciones / proyectos de VS deben reflejarse en el nombre y la estructura del directorio / archivo. De hecho, mi impresión es que el consenso es tener el nombre del proyecto = nombre del conjunto = nombre del espacio de nombres (anidado), todo lo cual se reflejaría en la estructura y el nombre del directorio / archivo. Si esas son las pautas (o reglas) correctas, todos estos mecanismos de organización aparentemente ortogonales se mantendrían sincronizados.

Steve Rehling
fuente
-1

Sí, en aras de la legibilidad, ¡deberíamos tener un archivo por clase! Acabo de saltar a un proyecto. Veo muchas clases en un archivo. solo hace que sea muy difícil para un chico nuevo entenderlo. ¿No deberíamos pensar en la mantenibilidad? cuando desarrollamos un software? muchas veces el desarrollo continuará por otros desarrolladores. Tenemos espacios de nombres para organizar nuestras cosas, ¡no necesitamos archivos para hacerlo !.

Ceti
fuente
-5

Un elemento de código por archivo, sí.

Todo lo demás es una mala práctica y, francamente, una señal de victimización por RAD.

Tan pronto como uno comienza el desarrollo de software adecuado (IoC, patrones de diseño, DDD, TDD, etc.) y abandona el "omg vamos a hacer esto, no tengo idea de cómo, pero me pagan", uno verá que esta regla realmente, realmente, importa.

Turing completo
fuente