Powód umieszczenia typu funkcji i nazwy metody w różnych wierszach w C.

Właśnie zacząłem w firmie i jednym z komentarzy do stylu podczas mojej pierwszej recenzji kodu było to, że typ zwracanej nazwy i nazwa metody powinny być w różnych wierszach. Na przykład to

void foo() {
}

powinno być to

void
foo() {
}

Zawsze używałem pierwszego stylu i zastanawiałem się, czy istnieje jakiś inny powód niż osobiste preferencje, dlaczego ludzie używają drugiego stylu? Nie sądzę, żeby pierwszy w ogóle w ogóle szkodził czytelności. Czy jedno jest bardziej powszechne niż inne w przypadku programistów C i dużych projektów open source?

zastanawiał się, czy istnieje jakiś inny powód niż osobiste preferencje, dlaczego ludzie używają drugiego stylu?

Jest to styl, który był popularny na początku C, więc może być tak, że robili to od bardzo dawna, mają dużo kodu, który wygląda tak i właśnie to wszyscy są do tego przyzwyczajeni. Nie tyle osobiste preferencje, co dynamika korporacyjna.

Innym powodem jest to, że nazwy funkcji zawsze zaczynają się w pierwszej kolumnie. Typy zwrotów różnią się długością i mogą być nieco skomplikowane - umieszczenie typu w osobnej linii ułatwia znalezienie nazwy funkcji.

Jeśli firma ma ustalony styl, może również mieć dokument standardów kodowania. Poproś o to. Może to wyjaśniać powody tego wyboru, a posiadanie kopii pomoże uniknąć podobnych problemów w przyszłych recenzjach.

Jest to właściwie jedyna reguła formatowania kodu, którą znalazłem, ma zauważalny wpływ na czytelność i nie wymaga prawie żadnego wysiłku (zakładając, że Twój edytor kodu nie rozpocznie z tobą walki).

Dobrze jest zaprojektować język programowania, aby nazwy pojawiały się w spójnej pozycji w deklaracjach / definicjach. Uzasadnienie jest proste: masz ładną wizualną kotwicę (kręcone nawiasy klamrowe lub po prostu wiszące wcięcie), za pomocą której możesz od razu znaleźć początek nazwy. Nie musisz analizować języka podczas skanowania pliku, znajdź nazwę.

To tak samo, jak podczas formatowania dokumentu: kiedy zaczynasz nową sekcję, umieszczasz nazwę pogrubioną czcionką - często w osobnej linii - nie zakopaną gdzieś, niezróżnicowaną, długim zdaniem.

Wczesne C miało bardzo krótkie podpisy: typy zwracane były opcjonalne, a typy argumentów deklarowane po podpisie. Nazwy również były bardzo krótkie. Zmniejszyło to wpływ okazjonalnego typu powrotu kompensującego nazwę.

double dot(x, y);

Nadal jest lekkostrawny.

C ++ pogorszyło to nieco. Przenosi specyfikacje typów argumentów do podpisów, dzięki czemu podpisy są dłuższe. Ta składnia została później przyjęta podczas standaryzacji C.

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

jest mniej strawny, ale nie jest tak źle. (Fragment z Git)

Teraz rozważ współczesne praktyki programowania z długimi, opisowymi nazwami i sparametryzowanymi typami i zobacz, jak ten wybór stał się katastrofalny. Przykład z nagłówka 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(); 
}

Jeśli piszesz kod ogólny, takie podpisy nie są niczym niezwykłym. Możesz znaleźć przykłady o wiele gorszych przypadków, bez zbytniego wysiłku.

C, C ++ i ich pochodne, Java i C #, wydają się być wyjątkami od posiadania czytelnych deklaracji / definicji. Ich popularni poprzednicy i rówieśnicy (Fortran, ALGOL, Pascal) umieścili nazwy przed typami wyników i, na szczęście, wielu ich następców (Go, Scala, TypeScript i Swift, aby wymienić tylko kilka) wybrało również bardziej czytelne składnie.

Pierwszy raz poznałem ten styl około 19 lat, pracując z C & C ++. Zaskoczyło mnie, jak ktoś mógł wymyślić tę złą rzecz.

Jedynym (potencjalnie) pozytywnym punktem, jaki mogłem znaleźć, jest to, że można znaleźć definicję funcitonu za pomocą grep ^ FuncName. Może być istotny czynnik ponad dekadę temu w niektórych prawdziwych społecznościach nienawidzących narzędzi ... W miejscu, w którym widziałem, zastosowano go do C ++ i funkcji członków klasy, które zabijają nawet ten atrybut.

Zgadnij moją opinię. :)