Zasady (konwencje) kodowania

// luźna uwaga: może dostaniemy "preferowaną" konwencje kodowania, więc ten dział może stać się "obsolete" :p

Nazwy zmiennych

lrem

Proponuję, aby zmienne widoczne szeroko miały opisowe nazwy, z kolejnymi słowami wyróżnionymi wielkością liter (double particleMass;). Sensowne też wydaje się rozróżnianie zmiennych/funkcji eksportowanych poprzez zaczynanie ich od wielkiej litery.

mceier

nazwy zmiennych: pierwszy wyraz małymi literami, kolejne wyrazy rozpoczynane wielką literą ... eksport zmiennych tylko w uzasadnionych przypadkach ( a najlepiej by takich nie było ), z prefixem 'g_' ( hmm uwagi o eksporcie nazw chyba lepiej byłoby przenieść na inną stronę )

nazwy funkcji podobnie jak nazwy zmiennych z tym wyjątkiem, że eksportowane częściej ( bez wymaganego uzasadnienia ) i bez prefixu 'g_'

nazwy klas - wszystkie wyrazy w nazwie rozpoczynane wielką literą, pozostałe litery małe

nazwy przestrzeni nazw - najlepiej jak najkrótsze, jednowyrazowe, wszystkie litery małe

Komentarze

pi-r

Styl Javadoc (do generowania dokumentacji np. Doxygen)

Formatowanie

mceier

tabulacje = 4 znaki, zawsze zamieniane na spacje liczba kolumn = 80 /* vim: set fo+=t ts=4 sts=4 sw=4 et tw=80: */

pi-r

Moje propozycje:

K&R Style (http://en.wikipedia.org/wiki/K%26R)

spacje wstawiane w taki sposób:

for(i=0; i<10; ++i) {
    printf("%d", i*(i+i));
}

Ewentualnie styl do którego będzie można sformatować automagicznie w jakimś IDE :-)

Tabulacje popieram, ale czy będziemy pracować w trybie tekstowym żeby trzymać się 80 kolumn? 120 znaków też może wyglądać czytelnie i nie trzeba przewijać na boki.

mceier

dla C++ myślę, że lepszy jest taki styl:

for(i=0; i<10; ++i)
{
    printf("%d", i*(i+i));
}

e.g.

class C
{
    int _a,_b,_c,_d,_e,_f;
    C(int a,int b,int c,int d,int e,int f) : 
        _a(a), _b(b), _c(c), _d(d), _e(e), _f(f)
    {
    }
};

lRem

Osobiście używam bandy terminali o starych dobrych 80x24 znakach... A jeżeli powiększam, to raczej tylko w pionie (wtedy mieszczą mi się dwa i jest ślicznie). Poza tym nie podoba mi się proponowany styl :P Ale tutaj to zawsze jestem w opozycji do reszty świata, więc się dostosuję... Acz propozycja Mariusza bardziej mi się podoba. Tylko pytanie skąd stwierdzenie o lepsześci tego do C++? ;)

(mceier) przykład:

1.

class A {
};

2.

class A
{
};

w którym przypadku można szybciej/prościej dodać klasę bazową do klasy A :p

... dlatego myślę, że lepiej ten styl używać w C++

w C jest to bez różnicy :p

(lRem)

BTW - ciekawostka, czemu większość ludzi pisze tutaj zachowując jakąś małą szerokość tesktu źródłowego? Przecież i tak jest potem przeformatowany ;)