Konvence pro programování v jazyku C++

Konvence jsou při programování (v jazyku C++) chápány jako soubor pravidel či doporučení, který firma předepisuje svým programátorům jakožto povinné. Důvodem k tomu je usnadnit či dokonce umožnit, aby někdo mohl pokračovat v práci udělané někým jiným - ať už to znamená dopracovat, odstranit chyby či optimalizovat. Většinou se má na mysli

  • dokumentace (včetně komentářů či komentáři)
  • způsob typografického odlišovaní různých entit či úrovní zanoření programových struktur
  • pojmenovávací pravidla, jazyková či omezení znakových sad.

V předmětu PB161 budeme mít jak pravidla, jejichž nedodržení se bude penalizovat, tak doporučení, jejichž nedodržení se penalizovat nebude, ale jejichž dodržování bude součástí uměleckého dojmu, který může snížit počet bodů, při nejasnostech. V dalším budeme pravidla a doporučení odlišovat. Jednotlivá pravidla a doporučení platí až od okamžiku, kdy se o technických náležitostech pro jejich realizaci bude mluvit na přednášce či cvičení (stačí jen na jednom).

Norma pro nás v současné době je ANSI/ISO C++, dále jen Norma .

Konvence z normy

Podrobněji se s nimi seznámíte na přednáškách.

Pravidla - povinná zdůvodnění doporučení - sama nepenalizována zdůvodnění
Funkce main musí vracet
hodnotu typu int.
Rozhraní s OS to předpokládá.
Pokud v zadání není explicitně zadáno jinak, pak funkce main vrací 0. Shell pozná, že program dopadl jak měl. Funkce main vrací hodnotu 0, nevyskytly-li se nesprávnosti. Vyskytly-li se, pak pro každý případ nesprávnosti vrací jinou malou kladnou hodnotu. Shell má možnost na různé případy nesprávnosti reagovat podle potřeby.
Používejte výhradně knihovní funkce
a konstrukce z Normy.
Ikdyž je váš překladač zvládne,
nezaručuje to u jiných.
Identifikátory funkcí a proměnných začínají malým písmenem nebo znakem '_' (podtržítko)
a pokud obsahují velká písmena, tak jen sporadicky a důvodně.
Rozlišení od pojmenovaných konstant. (Od sebe se rozlišují '(' a ')' (závorkami).
Identifikátory pojmenovaných konstant obsahují jen velká písmena
a jen sporadicky a důvodně znak '_' (podtržítko).
Rozlišení od funkcí
a proměnných.

Konvence pro uživatelskou příjemnost

Pište programy tak, aby se při běhu chovaly, jak byste si přáli, aby se chovaly Vám úplně cizí programy, když je pustíte.

Pravidla - povinná zdůvodnění doporučení - sama nepenalizována zdůvodnění
Pokud program čte ze standardního vstupu, pak musí vypsat jaké údaje očekává.
V případě, že údaje jsou chybné, pak je musí opsat na standardní výstup spolu s informací, v čem jsou chybné nebo jaké mají být.
Program, který očekává vstup, ale nedá o tom vědět, vypadá jako by se zasekl.
A i v případě, že byste se dovtípili, že máte něco zadat, nemusíte vědět co.
Uživatelem zadané údaje pro kontrolu opište na standardní výstup. Uživatel si často nemůže být jist,
v čem je chyba a výpis zadaných údajů pomůže.
Pokud Váš program předpokládá zadání některých údajů výhradně z příkazového řádku, pak při nesprávném zadání musí program, než skončí, vypsat, jak má zadání vypadat. Jak jinak by se to uživatel dozvěděl.
Po posledním výpisu na standardní výstup odřádkujte (vypište přechod na nový řádek - '\n'). Aby uživatel snadno poznal prompt (výzvu) shellu.
Program nechť pokyny a informace vypisuje „cestinou“ nebo „slovencinou“. Ne všechny OS se kamarádí s utf-8. Program by měl umožňovat přepnout nebo zvolit vypisování pokynů a informací v angličtině. Na Zeměkoulovi je dost lidí, kteří ani česky a ani slovensky neumí.

Konvence dokumentování

Pište programy tak, aby je mohl upravovat - jak opravovat, tak rozšiřovat - i podprůměrný programátor.

Pravidla - povinná zdůvodnění doporučení - sama nepenalizována zdůvodnění
Tam, kde to má smysl, používejte identifikátory, které vypovídají - i víceslovně - o tom, co se jimi označuje. Umožňuje to lépe se v programu vyznat. Pojmenování ať vychází z angličtiny. Je to „rodná řeč programování“.
V identifikátorech funkcí a proměnných se možná rozhraní „slov“ označují velkým prvním písmenem dalšího či znakem '_' (podtržítko). Umožňuje to rozšifrování původního víceslovného označení. Používejte lowerCamelCase. U pojmenování tříd používejte UpperCamelCase. (První možnost.) Později se vám to vyplatí.
V identifikátorech pojmenovaných konstant se možná rozhraní „slov“ označují znakem '_' (podtržítko). Umožňuje to rozšifrování původního víceslovného označení.
Je typograficky odlišné od funkcí a proměnných.
Každý soubor zdrojového textu dokumentujte podle Javadocu.
Jen tagy@author name“ a „@version version“.
Je nešikovné vymýšlet nové normy a nepoužít, co ještě potkáte.
Každou funkci dokumentujte podle Javadocu.
Jen tagy@param name description“ a „@return description“.
Je nešikovné vymýšlet nové normy a nepoužít, co ještě potkáte. Používejte Doxygen.
Text programu pokaždé, když použijete nezřejmou konstrukci či sled přikazů, komentujte. Podle okolností
/* takhle
*/

nebo na konci řádku // takhle.
Aby i podprůměrný programátor mohl ve Vaši práci pokračovat.
Protože pro to neexistují objektivní kriteria, nebudeme to striktně posuzovat.
Dodržujte maximální délku řádků 80 nebo 120 sloupců. Nemusí mít všichni grafické monitory.

Konvence pro profesionální programování

Jsou tu jen některé „dobré“ rady, které by měl dobrý profesionální programátor dodržovat.

Pravidla - povinná zdůvodnění doporučení - sama nepenalizována zdůvodnění
Program čleňte na funkce provádějící dílčí části algoritmu.
To nedělejte jen tam, kde to není rozumné.
Kriteria pro to, jsou natolik subjektivní, že to nelze posuzovat, pokud to nebude přímo předepsáno.
Nepoužívejte číselné hodnoty pro znaky. Po čase nebude vědět ani Vy, kde se ta čísla vzala.
Proměnné deklarujte lokálně uvnitř funkce;
pouze ty, které se budou používat ve více funkcích a není účelné je předávat jako parametry, deklarujte jako globální.
Používání globálních proměnných umenšuje násobné používání, jež je žádoucí.
Použité datové typy (například struktury) definujte příkazem typedef. Zaveďte vlastní třídu. Odstraňuje to nebezpečí, že požijete dvě různé struktury v domění, že to jsou ta samá.
Na začátku programu uveďte jejich prototypy. Pokud zadání vyžaduje vytvoření samostatného hlavičkového souboru, soustřeďte v něm deklarace všech prototypů i pojmenovaných konstant a definic typů a obsahovat by měl i deklarace tříd, název by měl být stejný a koncovka „.h“. Pak se stačí podívat, jen do jednoho souboru a ne hledat všude možně.
Lepší jsou zbytečné závorky navíc než kdyby nějaké chyběly. Překladač to někdy vidí jinak než Vy.
Vnořené programové struktury začínejte o 2 až 4 sloupce vpravo než jsou mateřské. Použité členění programu je srozumitelnější.
Řádky programové struktury stejné úrovně ať začínají na stejném sloupci. Usnadňuje to orientaci.
Používejte '{' a '}' i pro jeden či žádný příkaz, ikdyž to syntaktická pravidla nevyžadují. Text je přehlednější.
Na jeden řádek nejvýše jeden příkaz. Text je přehlednější.
Používejte jen nové standardní hlavičkové soubory bez přípony. V jazyce C, ale i u starších překladačů C++ mají standardní hlavičkové soubory příponu „.h“. Většina překladačů zná oba druhy hlavičkových souborů, ale ty se od sebe v detailech liší.
I když jazyk C++ v sobě obsahuje i prostředky pro vstup a výstup známé z jazyka C, až na odůvodněné výjimky jich nepoužívejte a nahraďte je používáním operátorů „«“ a „»“, případně V/V funkcí jazyka C++. Nekomplikujme si to.
Nepoužívejte jiné prvky jazyka C tam, kde má C++ k dispozici vhodnější nástroje (např. funkcím a operátorům z hlavičkového souboru <string> dáváme přednost před prostředky ze <string.h> nebo <cstring>). - „ -

Povídání starého zbrojnoše

Už v šedesátých letech se začala projevovat “krize programování„ - to byla situace, kdy poptávka po programování (psaní nových či údržba dosavadních) vysoce překračovala nabídku - tedy počet a produktivitu programátorů. Situace byla oproti dnešku ještě komplikována drahotou, nevýkoností a nespolehlivostí tehdejších počítačů, tím, že se programy psaly v mnoha často specifických jazycích: strojových kódech nebo assemblerech jednotlivých procesorů a také nekomfortností tehdejších OS a vstupů - děrné štítky a pásky.

Jeden z důsledků onoho stavu bylo, že dobří programátoři měli velmi vysoké platy a špatní nebyli vyhazováni. Často se u jednotlivých organisací stávalo, že poměr produktivity mezi nejlepšími a nejhoršími programátory byl 10 : 1. K nápravě krize programování částečně vedlo strukturované programování, tvorba nových programovacích jazyků, metodik, paradigmatu objektově orientovaného programování. Programy měly být univerzálnější, opětovně použitelné a zejména snadno udržovatelné.

Ze začátku, kdy programovali jen opravdoví programátoři (originál), kteří psali neuvěřitelně efektní a krátké programy (kvůli úspoře paměti kódu samomodifikující se), se ukázalo jako velký problém nedostatek těch, kdo ty geniální programy měl udržovat - opravovat v nich chyby, rozšiřovat jejich funkčnost a upravovat pro nové OS či stroje. Finační nákladnost údržby rostla. A čím dražší, protože komplikovanější, byl prvotní vývoj souboru programů, tím větší byly požadavky na prodloužení životnosti - tedy udržování. Začalo se mluvit o ceně za celou životnost - tedy pořízení a udržování. A udržování mnohdy ve finančních nárocích převyšovalo pořízení. Když si uvědomíme, že mnohý opravdový programátor údržbu prováděl záplatami ve strojovém kódů přímo na disk a nikde to nedokumentoval, pak se nemůžeme divit, že odchod takového opravdového programátora znamenal odepsání programu, ať už byl drahý, jak chtěl.

Způsob jak problém řešit je nabíledni: opravy a úpravy se musí dělat výhradně do dostatečně přehledného a komentovaného zdrojového textu ve vyšším jazyce - typicky C a velmi podrobná a pečlivá dokumentace. Záhy se ale projevilo, že když sice všichni píší texty programů dostatečně přehledně a podrobně a pečlivě je dokumentují, ale každý úplně jinak, tak to situaci nezlepší příliš a začaly se vytvářet konvence pro přehlednost textu programu a pro jejich dokumentaci a také nástroje, které tomu mohou být nápomocny.

QR Code
QR Code public:pb161_konvencec (generated for current page)