El Bruno

Excelente!

Hola Bruno! Nosotros en Signum no somos tan estrictos con esto (ni con casi ninguna otra cosa :)). En concreto, esta recomendación creo que viene importada de Java, donde tiene algo mas sentido porque allí todo son clases o interfaces.

En .Net sin embargo hay enums, delegados, structs... que tienden a ser mucho mas cortos y en mi opinión no se merecen su propio fichero, sino acabas teniendo una visión distorsionada del alcance del proyecto, pero en el sentido contrario.

Por otro lado, tambien tenemos clases parciales que permiten justo lo contrario. En Signum Framework por ejemplo conseguí mejorar la redibilidad haciendo que la jerarquía de objetos del Schema (FieldValue, FieldReference, FieldEmbedded) estuvieran todas juntas pero dividiendo las clases en ficheros distintos por funcionalid usando clases parciales: Schema.Save.cs contiene los override del metodo Save, Schema.Retrieve.cs los metodos Retrieve ...

Personalmente prefiero las recomendaciones de estilo algo más... 'opcionales'. Al final el criterio del programador es lo que cuenta y la única norma de estilo es: simplifica.

Tiempo de réplica?

Voy a comentar algo recien llegado de Málaga...

@Bruno, totalmente de acuerdo con lo que has indicado, de hecho, sigo estas mismas líneas y soy de los que como tú, se le ponen los pelos como escarpias cuando ve más de una clase dentro de un fichero de código.

@Olmo, entiendo que para vuestro mega-proyecto (quien no lo conozca lo invito a echarle un vistazo) hayáis tomado esas directrices, pero no las comparto.

Considero que la lectura se hace más cómoda y mejor haciéndolo como comentaba Bruno.

Por otro lado, huyo siempre que me es posible de los partial.

Y para mí, los delegados van en clases aparte, al igual que los enum, interfaces, etc.

Y en otro orden de cosas, para Bruno, para Olmo y para cualquiera, os recomiendo utilizar siempre en los proyectos un diagrama de clases y arrastrar allí cada uno de los objetos.

Ahí os llegará con total nitidez y claridad la organización del código, y veréis si metéis demasiados tipos de objetos en un único fichero y si eso os parece normal y correcto o no.

Olmo, prueba esto que te digo y me cuentas. ;-)

Bruno, la verdad es que, limitando la proposición a lo que dice el titulo (tipos que sean Clases, y que sean públicas), estoy bastante de acuerdo, exceptuando casos exóticos como el comentaba.

Mi principal punto de crítica es el tono de la idea, demasiado autoritario tal vez. programar es complicado y creativo, no hacen falta 10 mandamientos, tal vez 200 recomendaciones :).

De todas formas, yo también tengo mis manías, como es que la gente declare las variables y luego las inicialice. O que las re-use. O que las declare fuera del scope minimo posible.  

Jorge, por supuesto que usamos los diagramas de clase! aunque cada vez menos porque el soporte para genéricos está limitado a colecciones, con lo cual no funciona bien con Lite<T> para diagramas de entidades.

Tenemos pendiente incluso programar un plug-in para mejorar este soporte. Parece  complicado pero se puede intentar porque las powertoys son de código libre: blogs.msdn.com/.../418966.aspx  

Las clases de lógica son clases estáticas llenas le lambdas, así que tampoco queda muy bonito el diagrama.

Aunque convenciones como estas siguen siendo necesarias, huelen un poco, al igual que el UML o los patrones de diseño del GOF, a como se programaba en Java en 1998. El mundo está cambiando, los lenguajes dinámicos de lo están comiendo todo porque no hay tanta ceremonia y reverencia.

Ahora en lo que hay que centrarse es en las lambda, los Monads, las estructuras de datos inmutables, métodos dinámicos y meta programación o cualquier otro recurso que te permita reducir redundancia.

@Olmo

Las clases parciales, si alguna vez se puede justificar su uso, es cuando tienes código generado, algo de lo que yo personalmente estoy muy en contra, pero eso es otra discusión en la que no podemos entrar aquí.

Usar el mismo fichero para albergar más de un tipo no aporta ninguna ventaja salvo el hecho de poder navegar la solución mejor, un problema que ya está resuelto.

También si me permiten, "redibilidad" es una palabra que no existe. Creo que te refieres a la legibilidad si no me equivoco.

Bruno, te copio lo que he dejado en los foros porque bueno... no veo que "la masa" te esté inundando de comentarios :P

Bueno...

Yo sí suelo usar la norma de "un archivo .cs = una clase". Nunca uso clases partial, más que en los casos que están, digamos, recomendados por MS: extensión de clases generadas "por algo" (lease winforms designer, EF, ...).

Mis excepciones a esto son:

1.Enums suelo agruparlos con la clase que los usa primordialmente (muchas veces tenemos un enum que se usa básicamente como valor de retorno de uno o varios métodos de una sola clase). Finalmente si el enum se convierte en "mucho más importante" (es decir lo usan varias clases) lo muevo en un .cs aparte.

2.Delegates: lo mismo que los enums.

3.Variaciones de parámetros genéricos (suelo agruparlos todos en un mismo .cs).

4.Structs: A veces agrupo varias structs juntas.

De hecho, incluso, suelo meter cada clase, incluso las internas selaed en un archivo .cs propio...

Cuando java impuso esa norma, hubo bastante controversia al respecto, pero debe reconocerse que al final ayudó a localizar rápidamente en que archivo de código fuente estaba cada clase (sumado al hecho de que en java la organización lógica debe corresponderse con la física en directorios). Cuando trabajamos con IDEs puede no tener mucha importancia, pero si a veces hemos de localizar código usando herramientas no integradas, es bastante útil saber donde va a estar el código!

Un saludo!!

No puedo estar más de acuerdo con Hadi. :-)

Haidi,

De acuerdo contigo sobre el código generado, es una de las premisas de nuestro Framework :), las clases parciales las uso solo para cosas exóticas como dije.

Separar cada clase en un fichero también se supone que está hecho para mejorar la navegabilidad, y de la misma manera está resuelto por el IDE.

Sorry por lo de la redibilidad, no soy ortodoxo ni para eso :)