Estilo de codificación C# - longitud de línea / líneas de envoltura [cerrado]

Ahora que hemos aclarado que esto no tiene que ver con los caracteres de continuación de línea reales y simplemente con el ajuste de línea, dígame. Esto:

IEnumerable<int> orderIDs = context.Customers.Where(c => c.CustomerID >= 1 && c.CustomerID <= 10).Select(c => c.Orders).SelectMany(o => o).OrderBy(o => o.OrderDate).Select(o => o.OrderID);

O esto?

IEnumerable<int> orderIDs = context
    .Customers
    .Where(c => c.CustomerID >= 1 && c.CustomerID <= 10)
    .Select(c => c.Orders)
    .SelectMany(o => o)
    .OrderBy(o => o.OrderDate)
    .Select(o => o.OrderID);

¿Qué preferirías leer?

Creo que el límite de longitud de línea se ha ido alargando gradualmente (o desapareciendo) en los últimos años, ya que todo el mundo obtiene monitores de alta resolución de pantalla ancha y rara vez imprime código. Ninguno de los proyectos en los que he trabajado tiene una guía oficial, solo usamos el sentido común y el salto de línea aproximadamente al ancho de una ventana del editor (todos usan el mismo diseño básico de la ventana de Eclipse con la misma resolución). No veo problemas con este método.

Estoy a favor de romper líneas en puntos lógicos. La razón es ayudar con las funciones de diferenciación y fusión de control de código fuente. He encontrado que entender los cambios en un entorno así es mucho más fácil si las declaraciones con muchos elementos se rompen en varias líneas.

Los monitores son grandes. Pero puede encontrarse trabajando en una computadora portátil y realizando una combinación en la que tiene ramas base, fuente y destino en ventanas separadas a través de la pantalla. Cuenta los caracteres: cada una de estas ventanas en una computadora portátil de 17 pulgadas tiene solo unos 55 caracteres de ancho.

Si está trabajando de forma remota, descubrirá que el desplazamiento horizontal no está bien optimizado, y bien puede pensar en algunos pensamientos reprochables sobre los programadores que escriben funciones con 15 parámetros en una sola línea.

Así que piense en TODAS las formas en que tiene que trabajar en el código fuente, y romper líneas en lugares que sirven a TODAS sus necesidades.

Hace algunos años leí las Mejores Prácticas de Perl de Damian Conway . Aquí hay un enlace a continuación

Perl Mejores prácticas en Google Books

Hay un capítulo entero allí que trata de Disposición del código. Todos mis sentimientos sobre el diseño del código se resumen en su escritura. Recomiendo encarecidamente ese capítulo. Se puede aplicar fácilmente a C#.

He estado tratando de atenerme a sus reglas para cualquier lenguaje que pueda estar usando: C#, Java, Perl, JavaScript, VBScript, VB, PHP,...

En este libro, Conway sugiere usar líneas de 78 columnas. Tengo que admitir que rompí la regla y me pegué a 80 pero creo que está bien.

He integrado esta regla a cada editor que uso (Notepad++, Komodo, Vi, Vim, Visual Studio 2005) para tener una guía visual que muestre este límite.

Algunos de ustedes se preguntarán cómo mostrar una guía sobre VS, ¿eh?

Bueno, me pareció que no era tan obvio. De hecho, usted tiene que crear realmente un parámetro de cadena en el registro. Aquí hay un post que encontré en TAN al respecto. Espero que ayude.

Agregar una guía al editor en Visual Studio

Personalmente, me gusta poder "ver" todo. Por otra parte, tengo un monitor bastante decente. Pero en serio, me gustan las funciones bonitas y pequeñas frente a las funciones gigantescas con estados "if" anidados. Lo mismo con líneas de código.

Al final del día, todo se reduce a las preferencias personales y lo que usted y los miembros de su equipo decidan. Sé consistente. Y favorezca la legibilidad para el próximo tipo que vea su código.