Czy nawiasy klamrowe powinny pojawiać się na własnej linii? [Zamknięte]

Czy nawiasy klamrowe powinny być na własnej linii, czy nie? Co o tym myślisz?

if (you.hasAnswer()) {
    you.postAnswer();
} else {
    you.doSomething();
}

a może powinno być

if (you.hasAnswer())
{
    you.postAnswer();
}
else
{
    you.doSomething();
}

lub nawet

if (you.hasAnswer())
    you.postAnswer();
else
    you.doSomething();

Bądź konstruktywny! Wyjaśnij dlaczego, dziel się doświadczeniami, poprzyj je faktami i referencjami.

Kiedy byłem studentem, umieszczałem nawiasy klamrowe w tym samym wierszu, aby było mniej wierszy, a kod był drukowany na mniejszej liczbie stron. Patrzenie na pojedynczy nawias drukowany jako jedyną rzecz w linii jest denerwujące. (środowisko, marnotrawstwo papieru)

Ale przy kodowaniu dużych aplikacji, dopuszczenie niektórych linii zawierających tylko nawiasy klamrowe jest przystępne, biorąc pod uwagę wrażenie grupowania.

Niezależnie od tego, który styl wybierzesz, zachowaj spójność, aby Twój mózg nie przetwarzał wielu stylów w powiązanych fragmentach kodu . W różnych scenariuszach (jak wyżej) powiedziałbym, że można używać różnych stylów, łatwiej jest „przełączać kontekst” na wysokim poziomie.

Nigdy nie powinieneś robić trzeciej metody.

Przeskakiwanie na nawiasach klamrowych może zaoszczędzić ci kilku naciśnięć klawiszy za pierwszym razem, ale następny koder, który pojawia się, dodaje coś do twojej klauzuli else, nie zauważając, że w bloku brakuje nawiasów klamrowych.

Napisz swój kod dla innych osób.

Przez długi czas twierdziłem, że są one jednakowej wartości lub tak bardzo bliskie równości, że możliwy zysk dzięki dokonaniu właściwego wyboru był znacznie, znacznie niższy niż koszt kłótni o to.

Będąc zgodny jest ważna , choć. Więc powiedziałem, rzućmy monetą i zacznijmy pisać kod.

Widziałem już wcześniej, że programiści nie chcą się tak zmieniać. Pokonaj to! Zmieniałem się wiele razy w mojej karierze. Używam nawet różnych stylów w moim C # niż w PowerShell.

Kilka lat temu pracowałem nad zespołem (~ 20 programistów), który postanowił poprosić o dane wejściowe, a następnie podjąć decyzję, a następnie egzekwować ją w całej bazie kodu. Będziemy mieli tydzień na podjęcie decyzji.

Dużo jęków i przewracających oczami. Wiele „Lubię swoją drogę, bo jest lepiej”, ale bez substancji.

Gdy badaliśmy drobne szczegóły pytania, ktoś zapytał, jak poradzić sobie z tym problemem w stylu brace-on-the-the-line:

void MyFunction(
    int parameterOne,
    int parameterTwo) {
    int localOne,
    int localTwo
}

Zauważ, że nie jest od razu oczywiste, gdzie kończy się lista parametrów, a zaczyna ciało. Porównać do:

void MyFunction(
    int parameterOne,
    int parameterTwo) 
{
    int localOne,
    int localTwo
}

Przeczytaliśmy, jak ludzie na całym świecie poradzili sobie z tym problemem, i znaleźliśmy wzór dodawania pustej linii po otwartym nawiasie:

void MyFunction(
    int parameterOne,
    int parameterTwo) {

    int localOne,
    int localTwo
}

Jeśli zamierzasz zrobić wizualną przerwę, równie dobrze możesz to zrobić za pomocą klamry. Wtedy twoje wizualne przerwy również stają się spójne.

Edycja : Dwie alternatywy dla rozwiązania „dodatkowej pustej linii” podczas korzystania z K&R:

1 / Wcięcie argumentów funkcji inaczej niż w treści funkcji

2 / Umieść pierwszy argument w tym samym wierszu co nazwa funkcji i dopasuj kolejne argumenty w nowych wierszach do tego pierwszego argumentu

Przykłady:

1 /

void MyFunction(
        int parameterOne,
        int parameterTwo) {
    int localOne,
    int localTwo
}

2 /

void MyFunction(int parameterOne,
                int parameterTwo) {
    int localOne,
    int localTwo
}

/Edytować

Nadal twierdzę, że spójność jest ważniejsza niż inne względy, ale jeśli nie mamy ustalonego precedensu , to właściwym rozwiązaniem jest brace-on-next-line.

Główne zasady to:

1. Postępuj zgodnie z istniejącym standardem kodowania projektu.
2. Jeśli nie ma standardu kodowania i edytujesz istniejącą bazę kodu należącą do kogoś innego - zachowaj spójność ze stylem istniejącego kodu, bez względu na to, jak bardzo go lubisz.
3. Jeśli pracujesz nad projektem typu green-field - dyskutuj z innymi członkami zespołu i osiągnij konsensus w sprawie formalnego lub nieformalnego standardu kodowania.
4. Jeśli pracujesz nad projektem typu green-field jako jedyny programista - podejmij decyzję, a następnie bądź bezwzględnie konsekwentny.

Nawet jeśli nie masz żadnych zewnętrznych ograniczeń, najlepiej (IMO) poszukać istniejącego (powszechnie używanego) standardu kodowania lub wytycznych dotyczących stylu i spróbować tego przestrzegać. Jeśli rzucisz własny styl, istnieje duża szansa, że ​​za kilka lat będziesz żałować.

Wreszcie styl, który jest implementowany / możliwy do wdrożenia przy użyciu istniejących kontrolerów stylów i formatatorów kodu, jest lepszy niż styl, który należy „wymusić” ręcznie.

Zaletą pierwszej metody jest to, że jest bardziej kompaktowa w pionie, dzięki czemu można zmieścić więcej kodu na ekranie i dlatego wolę. Jedynym argumentem, który usłyszałem na korzyść drugiej metody, jest to, że ułatwia ona parowanie nawiasów otwierających i zamykających, ale większość IDE ma do tego skrót klawiaturowy, a tak naprawdę jest to fałszywa instrukcja - zamiast parowania nawiasów otwierających z zamykającym nawias możesz sparować nawias zamykający z wyrażeniem „początek bloku” (jeśli, inaczej, przez chwilę) na tym samym poziomie wcięcia, więc równie łatwo jest ustalić, gdzie jest początek bloku.

Nie widzę powodu, aby marnować całą linię tylko na nawias, gdy poprzednia konstrukcja for / while / if już wizualnie wskazuje początek bloku.

To powiedziawszy, uważam, że nawias zamykający powinien znajdować się we własnej linii, ponieważ potrzebujemy czegoś, co wskazywałoby koniec bloku i jego strukturę wcięcia w widoczny sposób.

wolę

if (you.hasAnswer())
{
    you.postAnswer();
}
else
{
    you.doSomething();
}

koniec

if (you.hasAnswer()) {
    you.postAnswer();
} else {
    you.doSomething();
}

ponieważ wiersz you.postAnswer();jest znacznie łatwiejszy do odczytania i znalezienia na pierwszy rzut oka. Po drugie, wtapia się w linię powyżej ( you.hasAnswer()), przez co moje oczy muszą bardziej skupić się na czytaniu.

Wolę pierwszą metodę. Nawiasy klamrowe nie są warte oddzielnej linii.

Chodzi o to, że nawiasy klamrowe nie są ważne. Są tylko śmieciami składniowymi , które są absolutnie niepotrzebne do zrozumienia, do czego służy kod, jego celu i sposobu jego implementacji. Są tylko hołdem dla języków w starym stylu C, w których wizualne grupowanie operatorów było niemożliwe ze względu na mało dostępnego miejsca na ekranie.

Są języki (Python, Haskell, Ruby), które są w porządku bez nawiasów klamrowych. To tylko potwierdza, że ​​nawiasy klamrowe są śmieci i nie powinny zasłużyć na linię, jeśli to możliwe:

if (you.hasAnswer()){
    you.postAnswer();
}else{
    you.doSomething();
}

Użyj Pythona i całkowicie pomiń argument.

Pozycja nawiasów klamrowych powinna być

metadane

konfigurowalny w IDE przez programistę. W ten sposób te nieznośne nawiasy klamrowe w całym kodzie, niezależnie od autora, wyglądają tak samo.

To zależy.

Jeśli piszę w JavaScript lub jQuery, używam pierwszej formy:

jQuery(function($) { 
    if ($ instanceOf jQuery) { 
        alert("$ is the jQuery object!"); 
    } 
}); 

Ale jeśli koduję w C #, używam drugiej formy, ponieważ jest to kanoniczny sposób, aby to zrobić w C #.

public int CalculateAge(DateTime birthDate, DateTime now) 
{ 
    int age = now.Year - birthDate.Year; 
    if (now.Month < birthDate.Month 
        || (now.Month == birthDate.Month && now.Day < birthDate.Day)) 
        age--; 
    return age; 
} 

Pamiętaj, że twój przykład można napisać

if (you.hasAnswer())
    you.postAnswer();
else
    you.doSomething();

w C #.

Wolę pierwszy, ponieważ trudniej mi dostrzec błąd w tym przykładzie.

if (value > maximum);
{
    dosomething();
}

niż w tym przykładzie

if (value > maximum); {
    dosomething();
}

Po ; {prostu wygląda mi bardziej źle niż linia kończąca się, ;więc bardziej prawdopodobne jest, że to zauważę.

Wolę niewielki wariant 1)

if (you.hasAnswer()) {
    you.postAnswer();
} // note the break here
else {
    you.doSomething();
}

Dlaczego?

• Myślę zawsze umieszczanie nawiasów klamrowych na ich własnej linii zmniejsza czytelność. Mogę zmieścić tylko pewną ilość kodu źródłowego na ekranie. Styl wspornika 2) sprawia, że ​​algorytmy podnoszenia z wieloma zagnieżdżonymi pętlami i warunkami są boleśnie długie.

• Chcę elsejednak zacząć od nowej linii, ponieważ ifielse wizualnie należą do siebie. Jeśli przed nim znajduje się wspornik else, znacznie trudniej jest dostrzec, co należy do czego.

• 3) dyskwalifikuje się. Wszyscy wiemy, co złego może się stać, jeśli pominiesz nawiasy i zapomnisz o tym.

Czytałem gdzieś, że autorzy niektórych książek chcą, aby ich kod był sformatowany w następujący sposób:

if (you.hasAnswer())
{
    you.postAnswer();
}
else
{
    you.doSomething();
}

Ale ograniczenia przestrzenne ze strony wydawcy oznaczały, że musieli użyć tego:

if (you.hasAnswer()) {
    you.postAnswer();
} else {
    you.doSomething();
}

Teraz nie wiem, czy to prawda (ponieważ nie mogę jej już znaleźć), ale ten drugi styl jest bardzo rozpowszechniony w książkach.

Osobiście wolę nawiasy w osobnej linii, ponieważ:

a) wskazują nowy zakres,
b) łatwiej jest wykryć niedopasowanie (choć jest to mniejszy problem w środowisku IDE, który podkreśla błędy).

Ach, styl One True Brace .

Ma wszystko, czego potrzeba Świętej Drodze - nawet proroka (Richard „moja droga lub autostrada” Stallman).

Facet tak bardzo mylił się co do tak wielu rzeczy, ale GNU jest znakomita, jeśli chodzi o aparaty ortodontyczne.

[Aktualizacja] Widziałem światło i teraz czczę Allmana

Drugi przykład, jestem bardzo duży w zakresie czytelności. Nie mogę znieść patrzenia na bloki w jakikolwiek inny sposób = (

Prosta odpowiedź: co łatwiej debugować?

// Case 1:
void dummyFunction() {
  for (i = 0; i != 10; ++i) {
    if (i <= 10)
      std::cout << "i is: " << i << "\n";
      std::cout << 10 - i << " steps remaining\n";

      // Some hard work here
      // which is really hard
      // and does take some screen estate
    }
    else
      std::cout << "We'll never get there";
  }
} // COMPILER ERROR HERE


// Case 2:
void dummyFunction()
{
  for (i = 0; i != 10; ++i)

    if (i <= 10)
    {
      std::cout << "i is: " << i << "\n";
      std::cout << 10 - i << " steps remaining\n";

      // Some hard work here
      // which is really hard
      // and does take some screen estate
    }
    else
      std::cout << "We'll never get there\n";
  }
} // COMPILER ERROR HERE

W którym przypadku zdiagnozowałeś problem najpierw?

Nie dbam o osobiste preferencje (istnieje wiele innych stylów, w tym biali i inni) i nie obchodzi mnie to zbyt długo ... dopóki nie utrudni to mojej umiejętności czytania kodu i debugowania go.

Co do argumentu „marnuj miejsce”, nie kupuję go: i tak dodam puste linie między grupami logicznymi, aby program był bardziej przejrzysty ...

Nie żeby ktokolwiek to zauważył, ale właśnie dlatego nawiasy klamrowe należą do tej samej linii co warunek (z wyjątkiem bardzo długich warunków warunkowych, ale to przypadek na krawędzi):

W C jest to poprawna konstrukcja:

while (prawda);
{
    char c;
    getchar (); // Poczekaj na dane wejściowe
}

Szybki! Co robi ten kod? Jeśli odpowiedziałeś „nieskończona pętla z pytaniem o dane wejściowe”, jesteś w błędzie! Nawet nie dostaje się do wejścia. Zostaje złapany na while(true). Zauważ, że średnik na końcu. Ten wzór jest w rzeczywistości bardziej powszechny, niż się wydaje; C wymaga od ciebie zadeklarowania zmiennych na początku bloku, dlatego właśnie uruchomiono nową.

Linia kodu to myśl. Nawiasy klamrowe są częścią myśli zawierającej warunkową lub pętlę. Dlatego należą do tej samej linii.

Lubię pierwszą metodę. Wydaje się ładniejszy IMO i jest bardziej kompaktowy, co lubię.

EDYCJA: Ach, trzeci. Najbardziej podoba mi się ten, gdy jest to możliwe, ponieważ jest jeszcze mniejszy / schludniejszy.

Możesz to napisać:

you.hasAnswer() ? you.postAnswer() : you.doSomething();

Aby odpowiedzieć na pytanie; Kiedyś wolałem nawiasy klamrowe na ich własnej linii, ale aby uniknąć konieczności myślenia o błędach spowodowanych automatycznym wstawianiem średników w przeglądarkach, zacząłem używać stylu egipskiego do javascript. A kiedy kodowałem Javę w zaćmieniu, nie byłem zainteresowany walką (lub konfigurowaniem) domyślnego stylu nawiasów klamrowych, więc w tym przypadku poszedłem również do Egiptu. Teraz mam wszystko jedno i drugie.

Prawie wszystkie odpowiedzi tutaj mówią pewną odmianę „Cokolwiek robisz, trzymaj się jednego lub dwóch”.

Pomyślałem o tym przez chwilę i musiałem przyznać, że nie uważam tego za tak ważne. Czy ktoś może mi szczerze powiedzieć, że trudno jest przestrzegać następujących zasad?

int foo(int a, Bar b) {
    int c = 0;
    while(a != c)
    {
        if(b.value[a] == c) {
            c = CONST_A;
        }
        c++;
    }
    return c;
}

Nie jestem pewien, czy ktokolwiek inny ... ale mam absolutnie zerowe problemy z mentalnym przełączaniem się między stylami. Zajęło mi kilka chwil, aby dowiedzieć się, co zrobił kod, ale to wynik mojego losowego wpisywania składni podobnej do C. :)

Moim niezbyt skromnym zdaniem otwieranie nawiasów jest prawie całkowicie nieistotne dla czytelności kodu. Istnieje kilka przypadków narożnych wymienionych powyżej, w których jeden styl ma znaczenie, ale w większości rozsądne użycie pustych linii usuwa to.

FWIW, nasze style kodowania w pracy używają nieco bardziej uporządkowanej postaci 1 i zmodyfikowanej postaci 3. (C ++)

            // blank line is required here
if (x) {
            //This blank line is required
   y = z;
}
            // blank line is required here too, unless this line is only another '}'

if (x) y = z; //allowed

if (x)
    y = z;  // forbidden

Jestem ciekawy, czy ci, którzy zdecydowanie wolą formę 2, polubiliby tę wersję formy 1 tylko dlatego, że pusta linia zapewnia silniejszą separację wizualną.

Dziwię się, że to jeszcze nie zostało podniesione. Wolę drugie podejście, ponieważ pozwala ono łatwiej wybrać blok.

Kiedy nawiasy klamrowe zaczynają się i kończą w tej samej kolumnie i we własnej linii, możesz wybierać z marginesu lub za pomocą kursora w kolumnie 0. Zasadniczo oznacza to bardziej obszerny obszar z wyborem myszy lub mniejszą liczbę naciśnięć klawiszy z wyborem klawiatury.

Początkowo pracowałem z nawiasami klamrowymi na tej samej linii co warunek, ale po zmianie zauważyłem, że przyspieszyłem tempo, z jakim pracowałem. Oczywiście nie jest to noc i dzień, ale coś, co nieco spowolni pracę z aparatami ortodontycznymi przy stanach warunkowych.

Osobiście lubię drugi sposób.

Jednak sposób, w jaki zamierzam to zademonstrować, jest moim zdaniem najlepszy, ponieważ zapewnia największe bezpieczeństwo pracy! Kolega z mojego uniwersytetu poprosił mnie o pomoc w odrabianiu lekcji i tak wyglądał jego kod. Cały program wyglądał jak pojedynczy blok. Interesujące jest to, że 95% błędów w programie, który stworzył, pochodzi z niedopasowanych aparatów ortodontycznych. Pozostałe 5% było oczywiste po dopasowaniu nawiasów klamrowych.

while(1){
i=0;
printf("Enter coded text:\n");
while((s=getchar())!='\n'){
         if(i%1==0){
            start=(char*)realloc(input,(i+1)*sizeof(char));
if(start==NULL){
printf("Memory allocation failed!");
exit(1);}
input=start;}
      input[i++]=s;}
start=(char*)realloc(input,(i+1)*sizeof(char));
if(start==NULL){
printf("Memory allocation failed!!!");
exit(1);}
input=start;
input[i]='\0';
                puts(input);

Moje osobiste preferencje dotyczą pierwszej metody, prawdopodobnie dlatego, że tak właśnie nauczyłem się PHP.

W przypadku ifinstrukcji jednowierszowych użyję

if (you.hasAnswer()) you.postAnswer();

Jeśli to nie jest, you.postAnswer();ale coś znacznie dłuższego, na przykład you.postAnswer(this.AnswerId, this.AnswerText, this.AnswerType);prawdopodobnie powrócę do pierwszego typu:

if (you.hasAnswer) {
    you.postAnswer(this.AnswerId, this.AnswerText, this.AnswerType);
}

Nigdy nie użyję podziału linii i nigdy nie użyję tej metody, jeśli istnieje także elseinstrukcja.

if (you.hasAnswer()) you.postAnswer();
else you.doSomething()

jest teoretyczną możliwością, ale nie taką, której bym kiedykolwiek użył. Trzeba to zmienić

if (you.hasAnswer()) {
    you.postAnswer();
} else {
    you.doSomething();
}

Oni nie powinni; pierwsza metoda dla mnie.

Kiedy patrzę na drugi, ze względu na nieużywane linie (te, które mają tylko nawiasy klamrowe, inne niż ostatnia nawias zamykający), mam wrażenie, że przerywa ciągłość kodu. Nie mogę go odczytać tak szybko, ponieważ muszę zwrócić szczególną uwagę na puste wiersze, które zwykle oznaczają rozdzielenie celu kodu lub coś takiego, ale w żadnym wypadku „ta linia należy do nawiasów klamrowych” (co tylko powtarza znaczenie wcięcia).

W każdym razie, podobnie jak podczas pisania tekstu ... dodawanie wcięcia na początku akapitu jest zbędne, jeśli przed nim jest pusta linia (podwójny znak zmiany akapitu), nie ma potrzeby marnować linii na nawiasy klamrowe, gdy jesteśmy prawidłowe wcięcie.

Ponadto, jak już wspomniano, pozwala zmieścić więcej kodu na ekranie, co w przeciwnym razie jest nieco przeciwne do zamierzonego.

To zależy od platformy / języka / konwencji

W Javie:

void someMethod() { 
     if (you.hasAnswer()) {
         you.postAnswer();
     } else {
       you.doSomething();
     }
}

W C #

void someMethod() 
{ 
     if (you.hasAnswer()) 
     {
         you.postAnswer();
     } 
     else 
     {
       you.doSomething();
     }
}

W C:

void someMethod() 
{ 
     if (you_hasAnswer()) {
         you.postAnswer();
     } else {
       you_doSomething();
     }
}

Nienawidzę, kiedy faceci Java używają swojego stylu w kodzie C # i vice versa.

Wszystko, co mogę powiedzieć, to to, że jeśli jesteś fanem metody nr 3, będziesz prześladowany przez każdy program formatujący kod IDE na ziemi.

Pierwszej metody używam po prostu dlatego, że jest bardziej zwarta i pozwala na więcej kodu na ekranie. Sam nigdy nie miałem problemu ze sparowaniem nawiasów klamrowych (zawsze wypisuję je wraz z ifinstrukcją przed dodaniem warunku, a większość środowisk pozwala przeskoczyć do pasującego nawiasu klamrowego).

Jeśli nie trzeba powiązać się szelki wizualnie, to wolałbym drugą metodę. Pozwala to jednak na zmniejszenie liczby kodów jednocześnie, co wymaga przewijania większej liczby. I to, przynajmniej dla mnie, ma większy wpływ na odczytywanie kodu niż posiadanie starannie dopasowanych nawiasów klamrowych. Nienawidzę przewijania. Z drugiej strony, jeśli chcesz przewinąć jedną ifinstrukcję, najprawdopodobniej jest ona zbyt duża i wymaga refaktoryzacji.

Ale; najważniejsza jest konsekwencja. Użyj jednego lub drugiego - nigdy obu!

Kiedy uczyłem się programowania w wieku 12 lat, umieściłem nawiasy klamrowe w następnym wierszu, ponieważ takie są samouczki na temat kodowania Microsoft. W tym czasie naciąłem również 4-spacja TABS.

Po kilku latach nauczyłem się Java i JavaScript i widziałem więcej kodów nawiasów klamrowych na tej samej linii, więc zmieniłem się. Zacząłem również wciskać 2-spacjami.

Istnieje czwarta opcja, która utrzymuje nawiasy klamrowe w linii, ale nie marnuje miejsca:

if (you.hasAnswer())
{    you.postAnswer();
     i.readAnswer();
}
else
{   you.doSomething();
}

Jedyny problem polega na tym, że większość autoformaterów IDE dusi się na tym.

Wszystko zależy od ciebie, dopóki nie pracujesz nad projektem, w którym kierownik projektu określił pewne ograniczenia kodowania lub pewne standardy, które muszą przestrzegać wszyscy programiści pracujący nad tym projektem podczas kodowania.

Osobiście wolałbym pierwszą metodę.

Też nie dostałem tego, co chcesz pokazać trzecią metodą?

Czy to nie zły sposób? Na przykład rozważ sytuację jako ...

if (you.hasAnswer())
  you.postAnswer();
else
  you.doSomething();

Co teraz, jeśli ktoś chce dodać więcej instrukcji w bloku if ?

W takim przypadku, jeśli użyjesz trzeciej metody, kompilator zgłosi błąd składniowy.

if (you.hasAnswer())
   you.postAnswer1();
   you.postAnswer2();
else
   you.doSomething();