Administrace komentářů

Abych se vyhnul zamotání se do detailů, narážka na vstupní body metody se týkala především GOTO (všichni dlouho zakazují použití, ale nikdo ho z překladače dosud nevyhodil :) ) nikoliv argumentů metody. Pokud je vstupních argumentů metody mnoho, odvolal bych se na designera... případně je testoval v separátní metodě. Na vysvětlenou dodám, že reset procesoru nepovažuji za výstupní bod. Přeci jen, pokud kontroluji nějaké proměnné s vyšším stupněm zabezpečení, v případě nesrovnalostí, volám reset OS - pro zajištění bezpečí osob/majetku. V případě, že je porucha fatální, a handling by mi navrátil kontrolu, skočím pro jistotu do nekonečné smyčky (z hlediska designu to snad nikdo nepovažuje za výstupní bod :)). Teď však k dlužnému vysvětlení: Dříve jsem používal returnů v metodách několik, avšak v zaměstnání jsem přišel na to, že je fajn, když se dodržuje dohodnutá štábní kultura a navíc když ji hlídá nějaký tool, např (sp)lint apod. Ten kritizuje spoustu maličkostí, ale u returnu jsem musel uznat, že je to opodstatněné varování. Představte si, že máte "povinnost/šanci" kontrolovat po kolegovi kód před každým mergem. Pak je reviewer rád za to, že 50 lidí píše jakš-takš uniformní kód bez ohledu na národnost. K tomu pro mě, bez pochyby, patří i počet returnů v metodě. Odpadá pak potřeba počítat, jestli ta či ona metoda měla 3 nebo 6 returnů -> měla prostě jenom jeden. Chápu, že to v někom snadno vyvolá pocit, že se snažím udělat return zbytečným, když bude vždy a pouze před poslední závorkou. Pro PC platformu bych to asi zvládnul, ale práce v automotive na mě měla eviděntně vliv... V zásadě je více vstupních/výstupních bodů metody noční můrou spíše pro designery než pro pisatele kódu, ale neměl by být pisatel tak trochu i designerem? Snad jsem Vám odpověděl.

PS OP těsně před returnem nastavuje nějakou statickou nebo globální proměnnou - to taky musí bejt pošušňáníčko pro unit testy nebo pro hledače závislostí :)