othello napisał(a)
Argument z liczeniem linii jest dość głupi. To wszystko można by napisać w jednej linii - wtedy to dopiero zajebisty bilans by wyszedł. Ale CO Z TEGO?
No to podam skrajność w drugą stronę. Skoro chcecie, żeby blok warunku był tak widoczny i nadmiarowe linie nie zaciemniają kodu to dowalcie 100 znaków nowej linii przed każdym nawiasem wtedy bloki staną się zaj*biście widoczne.
Ale panowie, rzucanie takimi skrajnościami nic nie wnosi do dyskusji.
Ja preferuję styl AT&T jedno to ze względów praktycznych, a drugie to, że Eclipse CDT stosuje go jako domyślny. Moje przyzwyczajenie i jako, że to jest styl najczęściej występujący w książkach (przynajmniej moich) to jest mi wygodniej.
Niektóre języki np dodają implicite średniki na końcach linii, o ile np linia daje się skompilować. Wtedy np kod:
while (true)
{
break
}
Spowodowałby nieskończoną pętlę.
Druga sprawa, już w codziennie używanych językach, jest taka, że nawiasy wąsate nie muszą oznaczać ciał instrukcji sterujących. Ja czasem sobie lubię wydzielić jakiś kawałek kodu, nie dość że mam logiczny podział, to jeszcze ograniczam sobie zasięg zmiennych gratisowo. Na przykład:
i++;
{
int b = 8;
b *= c;
d += b;
}
z += 8;
Jeżeli mam instrukcję sterującą (czyli if, while, for, itp) to nawias wąsaty otwierający walę w tej samej linii na końcu. Co to daje? Otóż tak czy siak szybko widać gdzie się bloki zaczynają lub kończą, natomiast jeżeli nawiasy wąsate otwierające pisze się w tej samej linii co instrukcje sterujące to od razu widzimy czy mamy do czynienia z rozgałęzieniem kodu:
Poza tym ciała instrukcji sterujących zawsze umieszczam w nawiasach wąsatych. Dosłownie zawsze. Zapobiega to błędom i ogólnie jest bardziej komfortowe. W tym przypadku pisanie nawiasu wąsatego otwierającego w jednej linii z instrukcją sterującą nabiera jeszcze większego znaczenia (i uzasadnienia), jako że zmniejsza to liczbę pustych linii, czyli więcej kodu się zmieści na ekranie.
Ta metoda z wydzielaniem bloków jest szczególnie przydatna w przypadku pisaniu długich funkcji. Oczywiście długie funkcje nie muszą łamać zasady DRY czy KISS, a z drugiej strony pisanie kilku funkcji (tzn rozbijanie tej długiej funkcji na siłę), z których każda jest używana dokładnie tylko w jednym miejscu czasem utrudnia czytanie kodu.
Dyskusja zacięta jak w parlamencie by ustalić czy to bruneci czy blondyni są wyżsi.
othello napisał(a)
większość znanych mi ide domyślnie formatuje kod sposobem 2 (C++ Builder, Visual Studio, QT Creator), a dopiero gdy ktoś się uprze to może sobie to przestawic w opcjach. Czyli poniekąd "lansowany" jest sposób 2, zresztą całkiem słusznie.
Znanych tylko z nazwy, choć i to nie do końca. Visual Studio to IDE, którego funkcjonowanie jest zależne od modułów supportu konkretnego języka, w wypadku C++ i C# nie zna pojęcia stylu, wcinanie i zawijanie kodu jest oparte na uniwersalnych zasadach. Qt Creator jest dostosowany do stylu biblioteki Qt. Biblioteka jest formatowana stylem mieszanym, tak jak jej przykłady, gdzie wyłącznie funkcje nawiasuje się symetrycznie:
http://doc.qt.nokia.com/latest/graphicsview-collidingmice-main-cpp.html:
int main(int argc, char **argv)
{
QApplication app(argc, argv);
qsrand(QTime(0,0,0).secsTo(QTime::currentTime()));
QGraphicsScene scene;
scene.setSceneRect(-300, -300, 600, 600);
scene.setItemIndexMethod(QGraphicsScene::NoIndex);
for (int i = 0; i < MouseCount; ++i) {
Mouse *mouse = new Mouse;
mouse->setPos(::sin((i * 6.28) / MouseCount) * 200,
::cos((i * 6.28) / MouseCount) * 200);
scene.addItem(mouse);
}
QGraphicsView view(&scene);
view.setRenderHint(QPainter::Antialiasing);
view.setBackgroundBrush(QPixmap(":/images/cheese.jpg"));
view.setCacheMode(QGraphicsView::CacheBackground);
view.setViewportUpdateMode(QGraphicsView::BoundingRectViewportUpdate);
view.setDragMode(QGraphicsView::ScrollHandDrag);
view.setWindowTitle(QT_TRANSLATE_NOOP(QGraphicsView, "Colliding Mice"));
view.resize(400, 300);
view.show();
QTimer timer;
QObject::connect(&timer, SIGNAL(timeout()), &scene, SLOT(advance()));
timer.start(1000 / 33);
return app.exec();
}
Visual Studio to IDE, którego funkcjonowanie jest zależne od modułów supportu konkretnego języka, w wypadku C++ i C# nie zna pojęcia stylu, wcinanie i zawijanie kodu jest oparte na uniwersalnych zasadach.
Co chcesz udowodnić? Zainstaluj na czysto Visual C#, napisz jakiś kod a potem wywołaj funkcję autoformatowania i zobacz wg której metody zostaną ułożone klamry. Więc nie żadna twoja "uniwersalna zasada", tylko klamra w nowej linii.
A potem utwórz projekt w Windows Forms i zobacz jak są ułożone klamry. Itd itp.
gdy coś czytam drażnią mnie samotne wąsate nawiasy, lubię gdy zapis jest "pytonowy"
gdy kompilator sugeruje, że brakuje mi klamerki czy nawiasu przeklinam i wolałbym by wszystkie nawiasy zamykały się w tej samej kolumnie.
ale, parę tysięcy lat temu Grecy wpadli na to że o gustach się nie dyskutuje.
Dorzucę moje 3grosze, mimo iż takich dyskusjii było już wiele..
Temat formatowania kodu jest paskudny, poniewaz IMHO najwazniejsze jest, aby formatowanie bylo spójne 2) a nie jakies tam konkretne, a druga rzecz to fakt, ze jesli dysponujemy IDE ktore posiada jakiekolwiek codefolding, to ... kod sie formatuje tak, aby się ładnie i czytelnie "zwijał", bo to jest istotne w jego czytaniu i utrzymaniu :\
ale abstrahujac od zwijania, w zalaczniku dorzucilem moj argument.
ja jestem za "pionowym" trzymaniem nawiasow, nawet jesli "kosztuje" to tę jedna więcej linijke per blok, z dwóch powodów:
jeżeli ktoś wprowadza blok, to ma ku temu cel: ograniczenie widocznosci zmiennych. przy okazji, jestem przeciwny stosowaniu klamer przy jednolinijkowych IF, FOR itd. osób które przy jednolinijkowym IFie, w momencie jego "powiększania", zapomną dostawić klamer, nie nazywam programistami1). dostawianie klamer jest naturalne, odruchowe i kosztuje czas bliski zeru. takie jest moje zdanie..
ale tym waznejszym argumentem, jest czytanie kodu. Kod czyta się nie tylko "z gory na dol", ale takze, paradoksalnie częsciej (debugging, szukanie bledu), i takze, czasem na boki. w tym momencie, zerknijcie prosze na zalaczone obrazki, staralem sie na nich zaznaczyc "ruchy oka" które są wymagane przy "sledzeniu kodu z dołu-do-gory", np. szukajac bledu.. uklad pionowy/symetryczny jest niestety wygodniejszy. raz, ze te "brzydkie" puste linie natychmiast wskazuja gdzie blok sie konczy/zaczyna, wiec skok oka jest praktycznie zaswze do pierwszej wiekszej pustej przestrzeni, a dwa.. ze mimo wszystko, przynajmniej mi, prosciej jest sledzic okiem kolumny/wiersze, niz szukac celu na ukos, pod blizej nieokreslonym "ukośnym kątem", co przy ukosnym formatowaniu konczy sie dwoma ruchami: do gory, i w prawo, zamiast jednym. w efekcie, przynajmniej ja, kod formatowany symetrycznie (nieukośnie), czytam nieco szybciej, niż ukośny
ps. w tych screenach takze dolaczylem swoje preferencje dotyczace "kolumnowania" i "wierszowania".. jesli w linijce, nawet dlugiej, nie ma "nic szczegolnego", zostawiam ją linijką. zwlaszcza, jezeli jest podobna do innych (acz QDri powinno byc tuż po linii SQuare, zapomnialem przeniesc). taki uklad przy wielu "szablonowych" linijkach pozwala szybko sledzic ich roznice
edit:
zapomną dostawić klamer, nie nazywam programistami
Oh ah jesteś wielki.
Chyba już gdzieś to słyszałem tyle że w zmodyfikowanych wersjach. Np. "kto używa błędnie wskaźników ten nie jest programistą", ablo "kto nie używa preprocesora ten nie jest programistą", w ogóle tekst w stylu egona.
Dużo zależy od języka i zachowania się parsera oraz od tego, na co pozwala składnia
Poza tym ciała instrukcji sterujących zawsze umieszczam w nawiasach wąsatych. Dosłownie zawsze.
Są przypadki, kiedy wygląda to ohydnie:
for {
country <- countries
city <- country.cities
} {
println(country.name -> city.name)
}
shape match {
case Circle(radius) => {
println(radius)
}
case Rect(a, b) => {
println(a, b)
}
}
val abs = if (a < 0) {
-a
} else {
a
}
Jak się stosuje wcięcia, to moim zdaniem szkoda całej jednej linii na klamrę. Dla mnie kod jest czytelniejszy bez tej klamry w osobnej linii, a z zastosowaniem wyraźnych wcięć.
A Pythona powinni w szkołach przed pascalem uczyć, bo nakazuje używania wcięć. Może dla niektórych to jest niewygodne, ale przynajmniej początkujący nabiorą dobrego nawyku robienia wcięć.
Deklaracja klas, struktur i przestrzeni:
class Example {
};
Definicje funkcji/metod, warunki oraz pętle
void foo()
{
while(...)
{
if(...)
{
...
}
else if(...)
{
...
}
else
{
...
}
}
}
Offtop: To chyba powinno być w dziale Flame zamiast Off-topic ;)
[losowa nazwa] napisał(a)
Offtop: To chyba powinno być w dziale Flame zamiast Off-topic ;)
teraz to chyba już tak ;)
Formatowanie stosuję różne, nie mam tu zasady „zawsze i wszędzie” (w ogóle uważam takie zasady za ślepe i z czasem rozmijające się z ich pierwotnymi przesłankami).
A zależy to od
— języka i przyjętej w nim konwencji
— środowiska i jego domyślnych ustawień: co innego wielki projekt w dużym IDE, co innego program pisany „na kolanie” w Notatniku EditPlusie.
— konkretnego programu: co innego zaczynać program od zera po swojemu, co innego poprawiać istniejący, jeszcze co innego rozbudowywać istniejący.
za coś takiego:
if (a == 0) {
doSth1();
} else if(a == 1) {
doSth2();
}
Należy się kastracja.
A tak na serio to są to po prostu dwa sposoby myślenia i tłumaczenia tego języka klamerek np. :
{ tłumaczymy jako ":"
} tłumaczymy jako "."
natomiast dla reszty:
{ tłumaczymy jako "Poczatek/wstęp"
} tłumaczymy jako "Koniec"
pierwszy sposób:
Jeżeli zabrakło paliwa :
jedziemy na stacje,
tankujemy,
. W innym wypadku: jedziemy dalej.
drugi sposób:
-O czynnościach które wykonujemy gdy licznik paliwa pokazuje rezerwę
Wstęp
Koniec
- O przypadkach pozostałych
Wstęp
Koniec rozdziału
I teraz w zależności jak kto sobie tłumaczy nawiasy nie pasuje mu druga opcja :
Jeżeli zabrakło paliwa
:
tankujemy
.
O czynnościach które wykonujemy gdy licznik paliwa pokazuję rezerwę Wstęp
tankujemy
Koniec
Tak sobie myślę że to też może wynikać ze sposobu w jaki myślimy , ci pierwsi myślą w kolejności a ci drudzy patrzą na kod jako obiekty.
Ale że co?
Że żadne argumenty nie mają żadnego znaczenia. Argumentowanie to takie dopasowywanie faktów na siłę do swojego toku myślenia.
Zupełnie nie kumam poprzedniego posta. Chyba zbyt wysoka abstrakcja jak dla mnie. :)
Nigdy nie myślałem o jakichś "wstępach" ani "końcach", if-else oznacza "jeżeli A to B, a jeśli C to D". Dla mnie po prostu naturalne jest czytelne kodowanie i umieszczanie klamer w oddzielnych liniach (z wyjątkiem inicjalizacji tablic i obiektów).
Czy nie uważają koledzy, że należałoby rozpatrzeć także nie mniej ważką kwestię, a mianowicie problem tabulatora.
W szczególności w aspekcie przenośności oprogramowania.
No i nie bagatelny problem jego szerokości. Częstym zwyczajem jest ustalanie tejże na 8. No cóż bardzo dobra to liczba, rzec by można okrągła, ale dla wielu może wydawać się zbyt wielka. Znowu jeden zrównuje go z prozaiczną spacją i niszczy jego inteligentne zachowanie.
Tak, wpływ onegoż na przenośność, czytelność oraz łatwości konserwacji oprogramowania uważam za wart przedyskutowania.
Mam nadzieję na wywołanie konfuzji ambiwalencji i pogodzę się nawet z trendem do eskalacji redundancji.
Kreślę się z szacunkiem, etc.
somekind napisał(a)
Zupełnie nie kumam poprzedniego posta. Chyba zbyt wysoka abstrakcja jak dla mnie. :)
Nigdy nie myślałem o jakichś "wstępach" ani "końcach", if-else oznacza "jeżeli A to B, a jeśli C to D". Dla mnie po prostu naturalne jest czytelne kodowanie i umieszczanie klamer w oddzielnych liniach (z wyjątkiem inicjalizacji tablic i obiektów).
Ale jaka abstrakcja ? po prostu jedni tłumaczą sobie klamerkę jako dwukropek inni jako taki powiedzmy odpowiednik begin z pascala czyli taki polski początek :
http://pl.wikipedia.org/wiki/Pascal_%28j%C4%99zyk_programowania%29
A zamkniętą klamerkę jedni interpretują jako kropkę(taka kropka kończąca zdanie) inni jako słowo koniec . Takie end z pascala.
I jeśli piszesz zdanie to logiczne że stawiasz dwukropek w tej samej linii co "treść" przykładowo:
psy to{
jamniki
}
jedni tłumaczą tak :
psy to :
jamniki
.
i takiej osobie dwukropek po zdaniu nie pasuje np.
:
psy to
:
jamniki
.
czyli:
psy to
{
jamniki
}
Jedni czytają kod programu jak tekst książki , czyli w kolejności słowo po słowie , inni jak obrazek , widzą stół , krzesło itd. . I jeśli patrzysz na kod wzrokowo to jak tutaj ktoś już przytoczył automatycznie szuka się drugiej klamerki aby zobaczyć pełny obraz bloku kodu.
Wow czy ja naprawdę tak niezrozumiale piszę ? Bo to już nie pierwsza osoba która mnie posądza o myślenie abstrakcyjne.
A co za różnica, niech każdy sobie formatuje jak chce, a koleś który to czyta i tak się połapie o co chodzi.
Xitami napisał(a)
Czy nie uważają koledzy, że należałoby rozpatrzeć także nie mniej ważką kwestię, a mianowicie problem tabulatora.
W szczególności w aspekcie przenośności oprogramowania.
No i nie bagatelny problem jego szerokości. Częstym zwyczajem jest ustalanie tejże na 8.
W jaki sposób tabulator ma niby wpływ na przenośność? To, czy TAB-a widzimy jako odstęp 2,3, 8 czy 16 znaków to kwestia wyświetlania przez edytor.
Co innego, gdy naciśnięcie taba nie powoduje wpisania taba, tylko od razu zamienia na n spacji. To już wpływa na zawartość pliku źródłowego.
Poza tym tabulatora się praktycznie nigdy ręcznie nie naciska. Dzisiejsze IDE robią wcięcia automatycznie.
Tak czy inaczej, wpływu na przenośność kodu nie widzę żadnego.
n napisał(a)
(.......)
I teraz w zależności jak kto sobie tłumaczy nawiasy nie pasuje mu druga opcja :
Jeżeli zabrakło paliwa
:
tankujemy
.
O czynnościach które wykonujemy gdy licznik paliwa pokazuję rezerwę Wstęp
tankujemy
Koniec
Tak sobie myślę że to też może wynikać ze sposobu w jaki myślimy , ci pierwsi myślą w kolejności a ci drudzy patrzą na kod jako obiekty.
cholender. dobre. wiesz, nigdy na to nie wpadlem, ale calkiem mozliwe ze masz sporo racji, zwlaszcza w "tak sobie mysle". to moze wszystko zalezec od tego, jak czlowiek "postrzega" kod..
kiedys bylem w zasadzie zwolennikiem doklejania { do poprzedniej linii, reguła "dwukropka", ale odkąd zacząłem grzebać w RAII/MPL/Lambda/Meta-wtf/etc bardzo szybko przestawilem sie na tryb "blokowy" i tego pierwszego juz "nie widze" bez "przestawiania sie" przez chwilkę. Wtedy, pamietam, spojrzenie na kod nagle dla mnie "przeksztalcilo sie" z "ciągu rozkazów" na "drzewo bloków"*), a ze w moim wyobrazeniu blok to prostokat, to mi 'ukosne' formatowanie nie lezalo zbytnio.. z kolei na poczatku, kiedy widzialem "ciag rozkazow" bardzo mi nie lezalo jak jedna linia musiala byc z racji dlugosci polamana na kilka wierszy i uwielbialem wycinac wszelkie niepotrzebne znaki, co mi pewnie zostalo w formie niepisania klamer gdy nie sa potrzebne.. heh. dobre. niezwrocilem wczesniej na to uwagi.
*) aktualnie moje "naturalne widzenie kodu" mozna okreslic jako graf, z drzewami w wezlach.. ale to nie calkiem pasuje, cholernie ciezko jest to nazwac tak aby faktycznie oddawalo 'wizje' :)
Mi format ukośny nie przeszkadza, aż tak bardzo gdyż jestem oprócz C++ to jeszcze Rubinowy więc taki sposób zapisu (dwukropkowy) bardziej mi pasuje bo nie muszę się aż tak przestawiać.