Razón para colocar el tipo de función y el nombre del método en diferentes líneas en C

14

Acabo de comenzar en una empresa y uno de los comentarios de estilo en mi primera revisión de código fue que el tipo de retorno y el nombre del método deberían estar en líneas diferentes. Por ejemplo, este

void foo() {
}

debería ser esto

void
foo() {
}

Siempre he usado el primer estilo, y me preguntaba si hay alguna otra razón que no sea la preferencia personal por la que la gente usa el segundo estilo. No creo que el primero duela la legibilidad en absoluto. ¿Es uno más común que el otro con los programadores de C y los grandes proyectos de código abierto?

    
pregunta gsingh2011 07.06.2013 - 18:07
fuente

3 respuestas

18
  

se preguntaba si hay alguna otra razón que no sea la preferencia personal   ¿Por qué la gente usa el segundo estilo?

Ese es un estilo que fue popular en los primeros días de C, por lo que la razón puede ser que así es como lo han hecho durante mucho tiempo, tienen un montón de código que se parece a eso, y eso es a lo que todos estamos acostumbrados. No tanto las preferencias personales como el impulso corporativo.

Otra razón es que los nombres de las funciones siempre comienzan en la primera columna. Los tipos de devolución varían en longitud y pueden ser algo complejos. Poner el tipo en su propia línea hace que sea más fácil encontrar el nombre de la función.

Si la empresa tiene un estilo de conjunto, también puede tener un documento de estándares de codificación. Pregunta por ello. Puede explicar los motivos de esta elección y tener una copia lo ayudará a evitar problemas similares en futuras revisiones.

    
respondido por el Caleb 07.06.2013 - 18:14
fuente
7

Esta es prácticamente la única regla de formato de código que he encontrado que realmente tiene un impacto notable en la legibilidad y casi no requiere esfuerzo (suponiendo que el editor de código no comience una pelea con usted por eso).

Es un buen diseño de lenguaje de programación que los nombres aparezcan en una posición coherente en las declaraciones / definiciones. El razonamiento es sencillo: tiene un buen ancla visual (una abrazadera rizada o simplemente una hendidura colgante) que puede usar para encontrar inmediatamente el inicio del nombre. No tiene que analizar realmente el idioma al escanear un archivo para encontrar el nombre.

Es lo mismo que cuando está formateando un documento: cuando comienza una nueva sección, pone el nombre en negrita, a menudo en su propia línea, sin enterrar en ninguna parte, sin diferenciar, en una oración larga.

Early C tenía firmas muy concisas: los tipos de retorno eran opcionales y los tipos de argumento se declararon después de la firma. Los nombres también tienden a ser muy cortos. Esto mitigó el impacto de tener un tipo de retorno ocasional que compensa el nombre.

double dot(x, y);

Todavía es bastante digerible.

C ++ hizo esto un poco peor. Movió las especificaciones de tipo de argumento a las firmas haciendo que las firmas sean más largas. Esta sintaxis se adoptó posteriormente durante la estandarización de C.

static struct origin *find_origin(struct scoreboard *sb,
                  struct commit *parent,
                  struct origin *origin)

es menos digerible, pero no demasiado malo. (Extracto de Git)

Ahora considere prácticas de programación modernas con nombres largos y descriptivos y tipos parametrizados y vea cómo esta elección se ha vuelto desastrosa. Un ejemplo de un encabezado Boost:

template <class A1, class A2, class A3, class A4, class A5, class A6>
inline typename normalise<policy<>, A1, A2, A3, A4, A5, A6>::type make_policy(const A1&, const A2&, const A3&, const A4&, const A5&, const A6&)
{ 
   typedef typename normalise<policy<>, A1, A2, A3, A4, A5, A6>::type result_type;
   return result_type(); 
}

Si está escribiendo un código genérico, las firmas como esa no están fuera de lo común. Puede encontrar ejemplos de casos mucho peores que esto sin esforzarse demasiado.

C, C ++ y sus derivados, Java y C #, parecen ser las excepciones a tener declaraciones / definiciones legibles. Sus populares predecesores y compañeros (Fortran, ALGOL, Pascal) colocaron nombres antes que los tipos de resultados y, afortunadamente, muchos de sus sucesores (Go, Scala, TypeScript y Swift, por nombrar algunos) también han elegido sintaxis más legibles.

    
respondido por el user2313838 08.06.2013 - 21:08
fuente
5

Conocí este estilo por primera vez en 19 años trabajando con C & C ++. Estaba bastante desconcertado sobre cómo alguien podría inventar esta cosa malvada.

El único punto (potencialmente) positivo que pude encontrar es que puedes encontrar la definición de la función usando grep ^ FuncName. Podría ser un factor relevante hace una década + en algunas comunidades reales que odian a las comunidades ... En el lugar donde vi que se aplicaba a C ++ y las funciones de los miembros de la clase, que matan incluso este atributo.

Adivina mi opinión. :)

    
respondido por el Balog Pal 07.06.2013 - 19:00
fuente

Lea otras preguntas en las etiquetas