it-swarm-eu.dev

Použití jednotlivých znaků pro názvy proměnných ve smyčkách / výjimkách

Vedl jsem pár rozhovorů se spolupracovníkem o použití jednopísmenných proměnných jmen za určitých okolností uvnitř naší kódové základny, na které jsme oba nesouhlasili.

Upřednostňuje více výstižné pojmenování konvence pro tyto, a já ne.

Podle mého názoru existují tři scénáře, ve kterých používám názvy proměnných s jedním písmenem:

  • Smyčky - ifor(int i = 0; i < 10; i++) { ... }
  • Lambda výrazy v C # - x/y/z: .Where(x => x == 5)
  • Výjimky - e: try { ... } catch(ExceptionType e) { /* usage of 'e' */ }

Toto jsou scénáře pouze, kde bych je použil, a zjevně používám podrobnější pojmenovací konvence jinde.

Můj kolega předložil následující argumenty pro výjimky a opakování:

  • i - nic to neznamená.
  • e - je to nejběžnější dopis v anglickém jazyce. Pokud byste chtěli hledat řešení pro výjimky, našli byste mnoho nežádoucích případů e.

Přijímám tyto argumenty, ale opakuji, že pokud člověk neví, co znamená i ve smyčce for for, pak by pravděpodobně neměl být programátor. Je to velmi běžný termín pro smyčky a výjimky, jako je e. Také jsem zmínil, že pokud by někdo chtěl, mohl by v případě výjimky vyhledat catch.

Uvědomuji si, že je to subjektivní, ale pak lze tvrdit, že standardy kódování jsou právě to - názory, i když názory akademiků.

Byl bych v každém případě šťastný a výsledky mu předám, ale raději bychom měli (naši společnost) nadále používat jednotný kódovací standard, než mít dva vývojáře s odlišnými názory na to, co použít.

68
Dan Atkinson

Plně souhlasím s vaším názorem a věřím, že to není vše , které je subjektivní.

Název proměnné je pouze tak relevantní jako její rozsah.

Nemá smysl v nekonečných diskusích o jménu proměnné, které bude číst pouze osoba, která si přečte ten konkrétní kousek kódu. Na druhou stranu jména tříd a jména členů musí jasně uvádět, co se děje. Mnoho očekávaného chování je třeba vysvětlit stručným jménem.

Konvence zlepšují čitelnost.

i a e jsou běžné konvence používané pro ty malé proměnné s rozsahem. Jejich úmysl je opravdu jasný, pokud znáte úmluvu.

Zřetelnost zlepšuje čitelnost.

Krátký název proměnné, který jasně vyjadřuje svůj záměr, má být upřednostněn před velkým názvem proměnné.

83
Steven Jeuris

To opravdu záleží na situaci/kontextu (a neexistuje žádné řešení, které by vyhovovalo všem ).

Obecně lze i, j, k [btw, i považovat za index; jeho použití pochází z matematického pozadí, kde to byly nejčastěji první tři indexy (pamatujte na tenzorový počet). Může to být také spojeno s Fortranovou historií, kde i jako první implicitně zadané celé číslo, bylo často používáno jako index smyčky. ] se často používají, pokud se jedná o jednoduchý čítač. Pokud má specifický význam, například měsíc nebo rok, pak je lepší název delší proměnné.

54
Rook

Souhlasím s vámi: i jako název proměnné smyčky je věkem starý idiom, který by neměl nikoho zmást. Stejné jako e pro proměnnou výjimky v bloku catch. Posledně jmenovaný (nebo spíše oba) by měl být krátký a jednoduchý, takže rozsah proměnné by měl být malý, což by čtenářům omezovalo možnost záměny. A pokud někdo chce hledat výjimky, lepší hledání typů výjimek nebo blokování bloků.

To znamená, že osobně dávám přednost použití názvů proměnných s delší smyčkou, například index nebo idx. Můj důvod je, že i je tak krátký, že je obtížné jej najít pomocí kurzoru.

Aktualizace

Pro informaci, argumenty vašeho spolupracovníka pravděpodobně pocházejí z Ottingerova pravidla pro pojmenování - vynikající a pragmatický přístup k předmětu, doporučený ke čtení. Možná však přehlédl níže uvedené části:

Moje osobní preference je, že jednopísmenná jména mohou být použita POUZE jako místní proměnné uvnitř krátké metody. Délka jména by měla nějak odpovídat velikosti jeho rozsahu. Pokud by proměnná nebo konstanta mohla být viděna nebo použita na více místech v těle kódu, je nezbytné dát jí jméno pro vyhledávání.

A

Počitadlo smyček může být pojmenováno i nebo j nebo k (i když nikdy l!), Pokud je jeho rozsah velmi, velmi malý a žádné jiné názvy může s tím být v rozporu. Jsou přípustné, protože se jedná o tradiční názvy domén řešení.

24
Péter Török

podrobnější jména mohou být stejně bezvýznamná. "i" se běžně používá jako jednoduchý iterační čítač, je to téměř standardní praxe. Volání stejného čítače „iter“, protože některé „kódovací standardy“ zakazují názvy proměnných s jedním písmenem, nepřidávají vůbec žádnou hodnotu.

"x", "y" a "z" jsou standardní názvy souřadnic, které je nazývají xCoord, yCoord, zCoord nepřidává nic.

„e“ je samozřejmě matematický výraz. Je však poměrně běžné používat jej jako jméno pro výjimky v blocích catch v Javě. Volání „exc“ nebo něco podobného by opět nepřineslo skutečnou hodnotu.

15
jwenting

Dávám přednost smysluplným názvům proměnných, a to i pro proměnné smyčky. Takže obvykle psám něco jako

for (int vertexIndex=0; vertexIndex<polygon.VertexCount; vertexIndex++)
   DoSomethingWithVertex(polygon[vertexIndex]);

Uvědomuji si, že pro malou smyčku, jako je tato, je malý rozdíl (v obou směrech), ale:

  • pokud je tělo smyčky delší, vertexIndex je často jasnější než i. Samozřejmě i je index, ale jaký index? Do kterého pole? K jakému prvku v tomto poli?
  • pokud tělo smyčky volá jiné funkce a předá index jako argument, je často snazší pojmenovat hodnotu důsledně v místě volajícího a na pozici volajícího - a nechtěli byste volat parametry metody i a x
  • pokud existují vnořené smyčky, použití i, j, k jako indexů je velmi matoucí a náchylné k chybám

abych byl konzistentní, používám smysluplné názvy proměnných pro indexy smyček všude.

@ André Paramés se zeptal: „Pokud je tělo smyčky dostatečně dlouhé na to, aby skrývalo význam i, není čas na refaktor?“

Typický lidský mozek má krátkodobou paměťovou kapacitu asi 7 kusů dat. Pokud tedy tělo smyčky obsahuje 8 nebo více kousků (kde „kousky“ jsou příkazy, lokální proměnné, parametry, komentáře), pak váš mozek nemůže ukládat význam každého z těchto bloků současně. Místo toho váš mozek posune kousky dovnitř a ven z pracovní paměti, zatímco čtete kód. Například pokud používáte názvy proměnných jako i a j, váš mozek posune významy i a j z jeho pracovní paměti; při příštím čtení j se váš mozek obvykle spoléhá na kontext, aby našel význam, tj. pokud si přečte customers[j] uprostřed těla smyčky bude váš mozek infer, že j je index do pole customers. Pokud jste napsali customers[vertexIndex], viděli byste, že používáte nesprávný index. A to je pro těla velmi krátkých smyček s pouze 8 kousky informací, tj. 5-8 řádků kódu.

Pokud se tělo prodlouží, obvykle byste jej rozbalili do samostatné funkce s parametrem vertexIndex. A to je druhý bod, který jsem dělal: Pokud je proměnná pojmenována vertexIndex uvnitř této funkce, měla by být skutečně nazývána vertexIndex také u volajícího.

15
nikie

Nesouhlasím s tvými kolegy.

Pro mě to znamená „iterace“. Docela smysluplné v případě smyčky.

Většina IDE umožňuje vyhledávání v textu typu regex. Takže můžete hledat „e“ ne uvnitř slova. To by bylo efektivní.

10
TZHX

Krátké názvy proměnných jsou jako zájmena v přirozených jazycích: používají se v malém kontextu/oboru. „i“ v krátké smyčce (bez hnízd) nebo „e“ v sekvenci několika úlovků jsou dokonale v pořádku. V mnoha případech by dlouhé/popisné jméno pro „i“ bylo „the_stupid_index_needed_to_get_at_the_really_interesting_things“ a použijete výraz lambda jen proto, že je potřebný pouze v jednom kontextu.

Perl's $ _ je super-zájmeno, které funguje (pro programátory Perl); i když je povoleno/povzbuzováno přeskočit i 'it' (jen "print" to "print $ _") je něco, čeho se trochu bojím.

Hledání proměnných názvů, abych zjistil problémy v kódu, by nebyl můj první nápad. Myslím, že by programátor měl mít představu o třídě nebo funkci, kde hledat v případě specifických potíží.

6
Ekkehard.Horner

(Toto je .NET-centrické, ale vaše otázka zmiňovala výrazy C # lambda, takže si myslím, že je to ve vašem případě relevantní.)

Jako výjimku bych vždy používal ex, protože e je již používán (konvencemi WinForms a ASP.NET WebForms) jako argument EventArgs- zadaný pro obsluhu události.

např.

protected void button_Click(object sender, System.EventArgs e)
{
    try
    {
        // whatever
    }
    catch (Exception ex)
    {
        // some exception handling
    }
}

Avšak MSDN používá e pro proměnné výjimky .

Během této diskuse bych navrhl mít na paměti dvě věci:

  • Konvence proměnného pojmenování lze obvykle považovat za formu náboženská válka .
  • Nejdůležitější konvencí kódování je zachovat styl existujícího kódu .
6
Richard Ev

Nevidím tu žádnou otázku, ale „i“, „j“ obvykle odkazují na souřadnice stejně jako „x“ a „y“ (moje osobní preference), chápu, že „e“ může být příliš časté, ale pokud vaše hledání výjimek, jus to hledání "Výjimka".

největším problémem s použitím proměnných s jedním písmenem je to, že se s nimi můžete zaměnit, ale pokud má tato proměnná omezený rozsah, například ve smyčce nebo při pokusu o zachycení, nevidím s tím žádný problém.

5
IvoC

Obvykle to není příliš důležité, pokud máte jednu smyčku, a já raději používám i nebo j pro jednoduchost (a kvůli konvenci). U vnořené smyčky někdy používám více podrobných jmen, abych rozpoznal, který index se vztahuje k čemu. Například, pokud mám dvě pole: dat a kvantititů a mám vnořenou smyčku iterující nejprve přes data, a pak přes množství, použil bych jména dateIdx a kvantityddx, abych zabránil záměně. Když jsem psal, měl jsem v kódu chyby

matrix[i][j] = fun(dates[i], quantities[j]);

ale měl by

matrix[i][j] = fun(dates[j], quantities[i]);

S podrobnějšími jmény bych chybu snadno našel, jako

matrix[quantityIdx][dateIdx] = fun(dates[quantityIdx], quantities[dateIdx]);

vypadalo by to špatně.

5
quant_dev

Zajímavou epistemologickou otázkou je otázka význam. Zdá se, že váš kolega předpokládá, že jen proto, že něco znamená něco pro něj, pak je význam a jinak tomu tak není.

Pravda je, že všechny ty symboly, které používáme každý den, nejen v programování, mají význam pouze proto, že jim je připisujeme. Nebo, jinak řečeno, což znamená je ve vašem mozku, ne v symbolu. (Chcete-li to objasnit jedenácti, pomyslete na klínový tablet - určitě to mělo pro spisovatele význam jednou za čas, ale pro většinu z miliard lidí dnes to tak není.)

S ohledem na to je předpoklad, že dlouhá jména něco znamenají, zatímco krátká jména ne, absurdní. Kromě toho očekávání, že dlouhé jméno v textovém textu nějakým způsobem nese význam, který má v jiném kontextu, může vést k nejasnostem.

4
Ingo

Několik bodů:

  • Slyšel jsem, že to naznačuje, že byste měli raději používat „ii“ až „i“, protože pokud budete někdy muset hledat index smyčky, budete to moci udělat (a obecně je vizuálně odlišnější) a Myslím, že je to dobrý nápad.
  • Záleží na rozsahu a obsahu vaší smyčky. Pokud vaše smyčka prostě dělá něco 10krát (např. Pokud vůbec nemá přístup k proměnné smyčky), pak si myslím, že „i“ nebo „ii“ je tisíckrát rozumnější než delší jméno. Každý, kdo kdy vůbec naprogramoval, by se měl vědět nebo se učit než „i“ obvykle znamená „proměnná smyčky“
  • Pokud má smyčka uvnitř velký blok kódu, zvažte to, že se jedná o funkci, ale v každém případě může být užitečné mít krátké, ale smysluplné jméno, např. carIdx nebo den, v neposlední řadě proto, že budete chtít použít "i" v těle smyčky.
  • Pokud vaše smyčka opakuje obsah datové struktury, použijte příslušné jméno: zkratka nebo malá forma datového typu nebo proměnné, která je obsažena, pokud je to přiměřeně rozlišovací (např. Pro auto v autěVýroba), nebo delší forma, pokud je vaše smyčka složitější.
  • Myslím, že totéž platí pro jehňata a výjimky, i když jsem méně známý. Například pokud existuje IS rozumné jméno pro vstup do vaší lambdy, zejména pokud existuje více než jedno, použijte jej, ale většinou je celý BOD lambda vzít anonymní vstup, který každý chápe jako "x" velmi dobře.
4
Jack V.

Když mluvíte o čitelném kódu, musíte zvážit několik věcí:

  • Jaké jsou vaše standardy kódování?
  • Jaké jsou běžné konvence pro vaši platformu?
  • Existuje potenciál pro záměnu?

Předpokládejme, že vaše kódovací standardy příliš nehovoří o konvencích názvů proměnných, měli byste přemýšlet o diskuzi o kódu. Například se smyčkou níže:

for(int i = 0; i < 10; i++)
{
    function(i);
}

Smyčku a všechny její funkce lze jasně vidět v celém rozsahu. Nyní si představte, jestli jsme vnořili smyčky (moje oblíbená je smyčka uvnitř smyčky uvnitř smyčky); nebo možná smyčka přesahující 100 řádků. V tomto okamžiku iterátory s jedním písmenem nedávají moc smysl, protože je tak snadné ztratit se v rozsahu. Možná budete chtít přehodnotit 100 řádků kódu do některých metod/funkcí, aby se trochu zkrotil, ale indexu dejte smysluplné jméno.

Pokud jde o výjimky, měl bych tendenci souhlasit s tím, že e prostě není dobré jméno. Moje důvody se však liší od důvodů vašich přátel. V průběhu let jsem udělal hodně programování Java) a musím se vypořádat se všemi těmi ošklivými kontrolovanými výjimkami, které se nikdy nevrhnou, pokud někdo nenabije vaše Java = install. Je to fakt života. Takže, když zpracováváte výjimku, musíte zapouzdřit část své manipulace s výjimkami do jiného obsluhy výjimek. Častým místem v tomto případě je kód JDBC.

Sečteno a podtrženo, protože každá výjimka, kterou jste kontrolovali, potřebuje jedinečný název a v jedné klauzuli try zpracováváte několik typů chyb, zadejte názvy výjimek, které něco znamenají. Zobrazení e, e1, e2 nepomůže, když čtu kód. Na jaký typ výjimky se dívám? Takže znovu, protože existuje prostor pro zmatek, používejte dlouhá jména.

4
Berin Loritsch

Jako čítač ve smyčkách používám i, pouze pokud:

  • používá se jako index; a
  • když je jeho rozsah velmi krátký.

Jak řekl Rook, výraz i má matematické pozadí jako index, který je označen jako programovací konvence. Pokud je však dlouhá smyčka obsahující mnoho proměnných, přejmenoval bych čítač i na něco explicitnějšího. Pokud máte vnořené smyčky, které iterují například maticí, obvykle místo toho používám row a col, protože i a j nejsou zrovna jasné na co se ještě odkazují („Bylo to A[i][j] nebo A[j][i]...? ").

Pokud jde o e pro výjimky, mám tendenci používat ex, protože jsem viděl, že e se používá pro element.

3
gablin

Přichází k rozdílu mezi „Co to děláš?“ vs "Jak to děláte?"

Nejprve ze všech, kde je to možné, použijte raději foreach než for. To lépe vyjadřuje, co děláte (tj. Procházejte se kolekcí a zpracovávejte každý prvek.) Tím se eliminuje problém pojmenování úplně.

Pokud má proměnná indexu vůbec jiný význam než „the_stupid_index_needed_to_get_at_the_really_interesting_things“ (díky E.H.), použijte tento význam. row a col by měly být upřednostňovány před i a jpokud pole představuje tabulku. Také ráda používám position nebo pos, pokud dělám hodně swapování.

Idiom for (int i = 0 ....) je však tak dobře zaveden, že je de facto standardem pro iteraci. Nehrajte si se zavedeným idiomem bez dobrého důvodu.

Výjimka výše: Matematika nebo Fyzika - Použijte standardní vzorce z textu.

v = d/t; je fyzikům nebo technikům známější než velocity = distance / time;

2
Chris Cudmore

I když nemám problém s používáním „i“, kodexy standardů vyžadují něco víc. Neztrácel bych čas argumentováním, pokud je to nutné. Pro mě jsou „loopIndex“ a „loopCounter“ dvě standardní jména, která používám místo „i“.

1
DPD

@ nikie již uvedl některé z mých argumentů, ale chci dodat, že váš argument pro omezení výřečnosti je slabý.

Při pohledu na kód izolovaně by pomohlo popisnější jméno. Samotná identifikace smyčky není problém, jak jste zmínil.

V aplikaci budete mnohokrát používat „i“ a mohli byste ušetřit nějaké psaní, ale ne všechny odkazují na totéž. Mnoho skriptů SQL alias tabulky s jedním písmenem, ale pokaždé, když je použit, odkazuje na stejnou tabulku.

Přijít se smysluplnými jmény může být obtížné, proto je nejlepší si z něj zvyknout.

1
JeffO

Pro "e", což samozřejmě znamená „výjimka“ nebo „chyba“, je snadné vyhledávat výjimky, stačí se ujistit, že vaše vyhledávání odpovídá celému slovu (může také hledat „e)“ se shodnými celými slovy, pokud nepoužíváte mezeru mezi proměnnou a závorkou), sami mnoho nenajdete, kromě obsluhy výjimek.

Pro "i", to má význam: znamená "iterátor" (nebo případně "index", nebo "inkrementor").

Existuje další důvod, proč mít krátký název proměnné: zkratky k tomu, co by bylo delší jméno proměnné/třídy, které se v rámci používá velmi často, nebo co máte. Například JQuery "$".

1
Phoenix

Myslel jsem, že i znamená „přírůstek“. Myslím, že velké množství různých odpovědí naznačuje, že existuje něco k původní otázce o smysluplnosti proměnných jmen - často to znamená něco tradičního, ale mnoho lidí je používá, aniž by vědělo, jaká je tradice. Je snadné říci, že někdo, kdo neví, co i znamená „neměl by být programátor“, ale jak se dá čit se co i znamená ? Zde je půl tuctu odpovědí.

1
David Rhoden

Steve McConnell v Code Complete měl skvělou radu pro bezvadnost názvů proměnných, vše záleží na rozsahu a použití proměnné. Pokud máte velkou třídu, vaše členské proměnné by měly mít jasná jména, protože chcete vědět, co proměnná představuje, když jste pohřbeni v kódu na půli cesty do souboru. Pokud máte krátkou funkci nebo proměnnou, která se používá pouze pro několik řádků kódu, můžete ji zkrátit tak, jak chcete, abyste se nestali zmateni tím, kde je definována nebo co představuje, a menší název kód vytvoří jasnější.

Proto jsou pro váš případ i, e a x skvělé názvy proměnných. (za předpokladu, že samozřejmě nemáte velké složité smyčky)

1
Richard