Code_formatting_rules

Odsazování

• Vypadá, že na tomto bodu se budeme muset shodnout, neboť kód editujeme všichni a nějak si musíme nastavit naše editovací nástroje, aby odsazovaly konzistentně.
• Dormon preferuje 2, Forrymu se to zdá velmi málo, John se také kloní k větší hodnotě. Jako kompromis se jeví 3.
• Závěr: zatím jsme se shodli na 3

Názvy tříd, typů, enumů, maker, proměnných, funkcí

• typy (třídy, struktury, ...) začínají velkým písmenem, proměnné pak malým
• existuje návrh nepoužívat Microsoftí styl, který každý typ a proměnnou uvozuje písmenem udávající typ (C pro class, P pro pointer,...)
• metody a funkce začínají malým písmenem
• pro víceslovné názvy proměnných a typů se kapitalizuje první písmeno každého slova počínaje druhým slovem; spojování slov _ se spíše vyhýbáme
• názvy položek v enum jsou velkými a víceslovné názvy se spojují _

Parametry funkcí a metod

• máme tři možnosti funkce( int a, int b ), funkce(int a, int b) nebo funkce(int a,int b)
• Johnovi se nejvíce líbí první, ale nemá problémy se druhou, třetí mu už není sympatická, ale zvykl bych si
• závěr: funkce(int a, int b) považujeme asi za standard a funkce(int a,int b) za povolenou variantu, se kterou nemáme problém; John se vzdává své rozvláčné formy

If, for a while

• pro if máme pět možnosti if( a < b ), if (a < b), if(a < b), if( a<b ) a if(a<b)
• závěr: povoleny varianty if (a < b), if (a<b), if(a < b) a if(a<b), John opouští rozvláčnou formu, pokud nebude hlas po jejím zachování

Závorkování u if-then-else

if(a < b)
{
    some code here
}
else
{
    some other code here
}

nebo

if(a < b) {
    some code here
} else {
    some other code here
}

• asi bych nechal na svobodě autora kódu
• jestli "} else {" nebo "}else{" souvisí asi s rozhodnutím k minulému bodu
• závěr: svoboda každého, ale ať je kód čitelný, jasně strukturovaný a opatřen dostatkem komentářů

Funkce vracející hodnoty přes parametry (ukazatele) v tomto formátu

Fce(a1,a2,a3)
a1 - seznam čistě výstupních parametrů z funkce Fce
a3 - seznam čistě vstupních parametrů do funkce Fce
a2 - vstupně výstupní parametry

toto je podle assembleru kde dst je vždy první parametr

Ve třídách uvádět private kvalifikátor první

• je to většinou z důvodu mít proměnné na začátku a v sekci private bývají nejčastěji proměnné
• většinou pak následuje blok public a nakonec to, co je jen pro děděné třídy, tedy část protected. Avšak striktní pořadí public a protected není vyžadováno.

Dormon rules

• to be added here

• adresovaní vicedimenzionalních polí

  Pole[((z]Height+y)Width+x)*4+0 <- všimni si nuly a pořadí operandů
  Pole[((z]Height+y)Width+x)*4+1
  Pole[((z]Height+y)Width+x)*4+2
  Pole[((z]Height+y)Width+x)*4+3

• Když už se musí napsat konstanty (nikdy), tak rozepsat

  NumTriangles34*sizeof(float) <- 3 a 4 není roznásobená

To be discussed:

• mnoho programátorů přepralo styl pythonu uvozovat privátní member proměnné v objektech _. Takto jsou jasně oddělené od veřejného rozhranní, nepletou se s lokálními proměnnými a každý hned ví, co jsou zač. S Forrym jsme si na to zvykli. Můžeme a nemusíme tento zvyk následovat.

• úspornost na mezery:

  return"ahoj";
  delete[]Neco;
  floatA=new float[12];
  CShaderProgramProgram=NULL;
  Johnův vkus je nechat to na dobrovolnosti. Pokud se na tom shodneme, jsem schopen se tento styl naučit, ale asi lnu trochu více ke klasickému stylu. Ale není to public rozhranní, takže buď se shodneme jak, nebo budeme mít kód napsaný více styly. Na čem bychom se ale podle mě měli shodnout tak, že pokud je soubor napsaný v jednom stylu (Dormon styl,...) a někdo tam něco opravuje, tak že to napíše ve stylu, ve kterém je celý soubor.

• další věci doplňte, pokud něco považujete za důležité