it-swarm-eu.dev

Je to špatný design pro programovací jazyk, který umožňuje mezery v identifikátorech?

Některé ( link 1 , link 2 ) programovací jazyky umožňují ve svých identifikátorech mezery (např. Proměnné, procedury), ale většina z nich ne a místo toho programátoři obvykle používají případ velblouda , případ hada a další způsoby, jak oddělit slova v názvu.

Pro podporu mezer nebo jiných znaků Unicode umožňují některé programovací jazyky zapouzdření názvu určitým znakem a tím omezí jeho začátek a konec.

Je to špatný nápad povolit prostory, nebo to prostě není dovoleno z historických důvodů (když existovala více omezení než nyní nebo prostě bylo rozhodnuto, že nestojí za implementaci)?

Otázka je více o hlavních výhodách a nevýhodách implementace v nově vytvořených programovacích jazycích.

Související stránky: link 1 , link 2 .

51
user7393973

Zvažte následující.

 var [Example Number] = 5;
 [Example Number] = [Example Number] + 5;
 print([Example Number]);

 int[] [Examples Array] = new int[25];
 [Examples Array][[Example Number]] = [Example Number]

Porovnejte ji s tradičním příkladem:

 var ExampleNumber = 5;
 ExampleNumber = ExampleNumber + 5;
 print(ExampleNumber);

 int[] ExamplesArray = new int[25];
 ExamplesArray[ExampleNumber] = ExampleNumber;

Jsem si jistý, že jste si všimli, že napětí, které váš mozek čte druhý příklad, bylo mnohem nižší.

Pokud povolíte mezery na identifikátoru, budete muset označit začátek a konec slova pomocí jiného prvku jazyka. Tito oddělovači nutí mozek, aby provedl další rozbor a v závislosti na tom, který vyberete, vytvoří pro lidský mozek zcela novou řadu otázek nejednoznačnosti.

Pokud neuvedete oddělovače a pokusíte se odvodit, o jakém identifikátoru mluvíte, když píšete kód pouze podle kontextu, zvete jiný typ červů:

 var Example = 5;
 var Number = 10;
 var Example Number = Example + Number;

 int[] Examples Array = new int[25];
 Examples Array[Example Number] = Example Number;

 Example Number = Example Number + Example + Number;
 print text(Example Number);

Dokonale proveditelné.

Celková bolest pro přizpůsobení mozku.

Tyto příklady je bolestivé číst nejen kvůli výběru slov, která vybírám, ale také proto, že váš mozek potřebuje nějaký čas navíc, aby zjistil, co je každý identifikátor.

Zvažte ještě pravidelnější formát:

 var Example = 5;
 var Number = 10;
 var ExampleNumber = Example + Number;

 int[] ExamplesArray = new int[25];
 ExamplesArray[ExampleNumber] = ExampleNumber;

 ExampleNumber = ExampleNumber + Example + Number;
 printText(ExampleNumber);

Všimnete si něčeho?

Názvy proměnných jsou stále hrozné, ale napětí ke čtení to šlo dolů. Stává se to proto, že váš mozek má nyní přirozenou kotvu, která identifikuje začátek a konec každého Slova, což vám umožní odtrhnout tuto část vašeho myšlení. Už se nemusíte starat o tento kontext - v textu vidíte zlom, víte, že přichází nový identifikátor.

Když čtete kód, váš mozek moc nečte slova tolik, jak se to shoduje s tím, co máte ve své mysli právě teď. Ve skutečnosti nepřestáváte číst „ExampleWord“. Vidíte celkový tvar věci, ExxxxxxWxxd, srovnáte ji s tím, co jste si uložili do své mentální hromady, a oni pokračují ve čtení. Proto je snadné vynechat chyby jako „ExampleWord = ExapmleWord“ - váš mozek to opravdu nečte. Jednoduše porovnáváte podobné věci.

Ještě jednou zvažte následující skutečnosti:

 Example Word += Example  Word + 1;

Nyní si představte, že se pokoušíte tento kód ladit. Představte si, kolikrát vám bude v „Příkladovém slově“ chybět. Špatně umístěné písmeno je již na první pohled těžké detekovat jako vidličku; další prostor je o řád horší.

Nakonec je těžké říci, že povolením mezer by se text stal čitelnějším . Je pro mě těžké uvěřit, že přidané potíže s extra terminátory a další režie v mém mozku by stálo za to použít tento typ funkcí, pokud by jazyk, s nímž pracuji, měl.

Osobně to považuji za špatný design - ne kvůli problémům s překladačem, tlumočníkem nebo čímkoli, ale proto, že můj mozek cestuje po těch prostorech a myslí si, že je to nový identifikátor, který se chystá začít, když tomu tak není.

V jistém smyslu, náš mozek trpí stejnými problémy než naše procesory, pokud jde o predikce větve .

Prosím, buďte laskaví k našim myšlenkovým vlakům. Nedávejte na vaše identifikátory mezery.

101
T. Sar

Je to špatný design pro programovací jazyk, který umožňuje mezery v identifikátorech?

Krátká odpověď:

Možná.

Mírně delší odpověď:

Design je proces identifikace a zvážení protichůdných řešení složitých problémů a vytváření dobrých kompromisů, které odpovídají potřebám zúčastněných stran. Neexistuje žádný „špatný design“ nebo „dobrý design“ s výjimkou v kontextu cílů těchto zúčastněných stran a vy jste neřekl, jaké jsou tyto cíle , takže otázka je příliš vágní na odpověď.

Ještě delší odpověď:

Jak jsem zmínil výše, záleží na cílech volebního obvodu, na které se návrhář jazyků zaměřuje. Podívejme se na dva jazyky, které jsem obeznámen s: lidsky čitelnou formou MSIL, nízkoúrovňovým „přechodným jazykem“, do kterého C # kompiluje, a C #.

C # je zamýšlen jako jazyk, díky kterému jsou vývojoví pracovníci v oblasti podnikání vysoce produktivní v prostředích, které Microsoft považuje za strategicky důležité. V C # je identifikátor posloupnost jednoho nebo více znaků UTF-16, kde jsou všechny znaky klasifikovány jako alfanumerické nebo _ a první znak není číslo.

Tato lexikální gramatika byla pečlivě vybrána tak, aby měla vlastnosti, které odpovídají potřebám těchto strategicky důležitých vývojářů LOB:

  • Je jednoznačně lexovatelný jako identifikátor; 1e10 nesmí například být právním identifikátorem, protože je lexically dvojznačný s dvojitým.
  • Podporuje idiomy běžně používané v C, C++ a Java, jako je pojmenování soukromého pole _foo. C # byl navržen tak, aby apeloval na vývojáře, kteří již znali běžný jazyk LOB.
  • Podporuje identifikátory psané téměř v jakémkoli lidském jazyce. Chcete napsat var φωτογραφία = @"C:\Photos"; v C #, jdete přímo dopředu. Díky tomu je jazyk dostupnější pro vývojáře, kteří nejsou rodilými mluvčími angličtiny.

C # však nepodporuje mezery v identifikátorech.

  • Zkomplikovalo by to lexikální gramatiku a představilo by nejasnosti, které musí být vyřešeny.
  • Ve velké většině interop situací to není nutné. Nikdo nemá své veřejné členy, aby v nich měli mezery.

Byl to dobrý nápad zakázat jiné znaky než písmena a čísla v identifikátorech C #.

V MSIL naopak můžete funkci pojmenovat téměř cokoli, včetně vložení mezer nebo jiných „divných“ znaků do názvů metod. A kompilátor C # to ve skutečnosti využívá! Bude generovat „nevýslovná jména“ pro metody generované kompilátorem, které nesmí být přímo vyvolávány uživatelským kódem.

Proč je to dobrý nápad pro MSIL a ne pro C #? Protože případy použití MSIL jsou zcela odlišné:

  • MSIL není navržen jako primární vývojový jazyk; jedná se o mezilehlý jazyk, takže hlavní případ použití je pro vývojáře kompilátoru, kteří se snaží porozumět výstupu jejich kompilátoru.
  • MSIL je navržen tak, aby byl schopen spolupracovat s jakýmkoli starým vývojovým prostředím společnosti Microsoft, včetně pre-.NET Visual Basic a dalších OLE) = Automatizační klienti, kteří povolili mezery v identifikátorech.
  • Jak je uvedeno výše, schopnost generovat „nevyslovitelné“ jméno pro funkci je vlastnost, ne chyba.

Je tedy dobrý nápad povolit mezery v identifikátorech? Záleží na případech použití jazyka. Máte-li k tomu solidní případ použití, povolte to všemi prostředky. Pokud ne, ne.

Další čtení: Chcete-li příklad fascinujícího jazyka, který výborně využívá složité identifikátory, viz Inform7 , DSL pro textové dobrodružné hry:

The Open Plain is a room. 
"A wide-open grassy expanse, from which you could really go any way at all."

Tím se deklaruje nový objekt typu room s názvem The Open Plain a tento objekt pak lze v celém programu označit jako takový. Inform7 má velmi bohatý a komplexní analyzátor, jak si můžete představit.

Zde je složitější příklad:

Before going a direction (called way) when a room (called next location) is not visited:
  let further place be the room the way from the location;
  if further place is a room, continue the action;
  change the way exit of the location to the next location;
  let reverse be the opposite of the way;
  change the reverse exit of the next location to the location.

Všimněte si, že way a next location a further place a reverse jsou identifikátory v tomto jazyce. Všimněte si také, že next location a the next location jsou aliasy. (Cvičení: co tento kód dělá se strukturou dat, která udržuje mapu místností ve hře?)

Inform7 má volební obvod, který chce jako zdrojový kód plně anglický přirozený anglický jazyk. Zdálo by se divné psát tento Inform7 jako

  change the way exit of the location to the_next_location;

Je to ponoření, aby to bylo možné. V kontrastu s T. Sar (vynikající) odpověď, která dělá kontrastní bod - to je ponoření pro vývojáře v LOB jazycích, aby se pokusili mentálně rozebrat, kde jsou identifikátory. Znovu jde o kontext a cíle.

59
Eric Lippert

Jeden relativně dobře známý příklad je nějaký Fortranův kód, ve kterém jeden překlep zcela změnil význam kódu.

Bylo zamýšleno opakovat část kódu 100krát (s I jako čítačem smyčky):

DO 10 I = 1,100

Čárka však byla napsána jako tečka:

DO 10 I = 1.100

Protože Fortran umožňuje mezery v identifikátorech (a protože automaticky vytváří proměnné, pokud nebyly deklarovány), je druhý řádek naprosto platný: implicitně vytvoří falešnou skutečnou proměnnou nazvanou DO10I a přiřadí jí číslo 1.1. Program tedy kompiloval pokutu bez chyb; prostě se nepodařilo spustit smyčku.

Dotčený kód ovládal raketu; jak si dokážete představit, taková chyba mohla být katastrofální! Naštěstí v tomto případě došlo k chybě při testování a žádná kosmická loď nebyla poškozena.

Myslím, že to ukazuje docela dobře jedno z nebezpečí v uvolnění mezer v identifikátorech ...

15
gidds

Je to špatný design pro programovací jazyk, který umožňuje mezery v identifikátorech?

Zapomněli jste důležité podrobnosti implementace:

co je zdrojový kód pro vás?

Líbí se mi definice FSF : preferovaná forma, na které vývojáři pracují. Je to sociální definice, nikoli technická definice.

V některých jazycích a jejich implementaci v 80. letech minulého století (myslet na originální Smalltalk a 1980 Smalltalk stroje) nebyl zdrojovým kódem posloupnost znaků. Byl to abstraktní syntaktický strom a byl manipulován uživatelem pomocí myši a klávesnice pomocí nějakého GUI.

V jistém smyslu Common LISP přijímá mezery ve svých symbolech.

Dalo by se rozhodnout (to je šarže práce) co-design obou programovací jazyk (dokumentováno v nějaké zprávě dává obě syntaxe a - sémantika ), jeho implementace (jako nějaký software) a jeho editor nebo IDE (jako nějaký software).

Přečtěte si staré diskuse o tunes.org . Přečtěte si starou práci na INRIA dne

@TechReport{Jacobs:1992:Centaur,
 author =       {Jacobs, Ian and Rideau-Gallot, Laurence},
 title =        {a {\textsc{Centaur}} Tutorial},
 institution =  {\textsc{Inria} Sophia-Antipolis},
 year =         1992,
 number =       {RT-140},
 month =        {july},
 url =          {ftp://www.inria.fr/pub/rapports/RT-140.ps}
}

a

@techreport{donzeaugouge:inria-mentor,
 TITLE =        {{Programming environments based on structured
                 editors : the \textsc{Mentor} experience}},
 AUTHOR =       {Donzeau-Gouge, Véronique and Huet, Gérard and Lang,
                 Bernard and Kahn, Gilles},
 URL =          {https://hal.inria.fr/inria-00076535},
 TYPE =         {Research Report},
 NUMBER =       {RR-0026},
 INSTITUTION =  {{INRIA}},
 YEAR =         1980,
 PDF =
              {https://hal.inria.fr/inria-00076535/file/RR-0026.pdf},
 HAL_ID =       {inria-00076535},
 HAL_VERSION =  {v1},
}

Viz také moje Bismonův návrh zprávy a http://refpersys.org/

Mým snem RefPerSys je navrhnout takový deklarativní programovací jazyk s programem Nice IDE). Vím, že by to mohlo trvat i deset let. my jsme!

Z hlediska použitelnosti je zbarvení syntaxe a automatické doplňování důležitější než mezery v identifikátorech (podívejte se do obou GtkSourceView a CodeMirror) pro inspiraci). Vizuálně podtržítko _ vypadá blízko znaku mezery. A pokud kódujete své vlastní IDE, můžete přijmout ctrlspace jako vstup pro "mezery uvnitř jmen". Můj názor je, že ℕ a ∀ by měla být „klíčová slova“, otázkou je, jak je zadáte. Snil jsem o psaní (inspirováno LaTeXem) \forallESC získat ∀ (a slyšel jsem o nějakém emacs submode za to).

Pozn .: Nesnáším Python (a Makefile - s)), protože tam jsou významné mezery (nebo tabulátory).

8

Není přirozeně špatný design povolit mezery v názvech symbolů. To lze znázornit jednoduchým příkladem.

Kotlin umožňuje mezery ve jménech. Má také oficiální konvence kódování, které uvádějí kdy je možné tuto funkci použít :

Názvy pro zkušební metody

V testech (a pouze v testech) je přijatelné používat názvy metod s mezerami uzavřenými v backtickech.

Příklad:

class MyTestCase {
     @Test fun `ensure everything works`() { /*...*/ }

„Dobrá“ a „špatná“ je samozřejmě subjektivní, ale použití mezer v názvech testovacích metod činí testovací kód mnohem příjemnějším pro čtení a také výsledky testů, které je hezké číst, aniž by se testovací kodér musel opakovat tím, že bude mít ošklivý název metody a samostatně čitelný popis zkoušky.

Důležitým bodem je, že tyto metody obvykle nebudou výslovně vyvolávány z kódu psaného lidmi, takže pouze místo, kde se název nachází, je v definici metody. Myslím, že se jedná o důležitý rozdíl při zvažování, kdy by mezery mohly být dobrým nápadem v názvech symbolů: pouze pokud je symbol napsán programátorem pouze jednou.

6
hyde

Pravidlo:

Chyby jsou úměrné času potřebnému k nahrání kódu.

Cokoli, co zvyšuje počet otevřených závorek, úzkých závorek, otevřených složených závor, úzkých složených závor, otevřených závorek, závěsných závorek ... zvýší počet chyb v kódu.

To je jeden z důvodů, proč * je hvězdička nebo ikona, nikoli hvězdička. # je ššš! je třesk. Matematici, u kterých mám podezření, mají také krátké slovní výrazy pro své symboly.

To je důvod, proč se technologická pole vyplňují zkratkami a zkratkami: Myslíme slovy. Máme omezenou pozornost a můžeme v hlavě držet jen tolik symbolů. Seskupujeme a hromadí věci dohromady.

ReallyReallyLongIdentifier může udělat totéž. Tam je kompromis mezi zapamatováním si, pro co je, a zapletením se do našich myšlenkových procesů. Ale ReallyReallyLongIndentifer je stále lepší než QzslkjfZslk19

Čím dále je používána, tím více musí být zapamatovatelná. Tedy, i, j, k použité pro konstrukty smyčky - jako jepice, které žijí po celý život smyčky, a tato smyčka začíná a končí na stejné obrazovce.

To platí i pro kódování:

A = FunctionAlpha (21, $ C, $ Q)

B = FunctionBeta ($ A, $ D, $ R)

je čistší než

B = FunctionBeta (FunctionAlpha (21, $ C, $ Q), $ D, $ R)

Myslím, že toto je jeden z důvodů, proč mají tabulky šíření takovou propastnou chybovost špatné kódování: Kromě přidání dočasných buněk/řádků/sloupců neexistuje žádný způsob, jak se vyhnout chaotickým vnořeným příkazům.

3
Sherwood Botsford

Trvalo mi dlouho, než jsem se opravdu zaregistroval, že nikdy nebude opravdu nejlepší jazyk. Pro programovací tým jsou nejdůležitějšími aspekty, že jazyk musí být dobře známý, podporovaný mnoha nástroji, měl by mít minimální syntaxi jazyka a měl by vás překvapit co nejméně zřídka.

Pro jeden kodér je skvělý výkonný jazyk, který umožňuje rychlé cykly testování/běhu.

Pro administrátory je klíčový jazyk přizpůsobený jazyku Shell operačního systému.

Pro některé pracovní jazyky sdílené mezi obory mohou být DSL pěkné.

Existuje místo pro jazyk s mezerami - pravděpodobně. Porušuje nepřekvapivá pravidla, ale velmi dobře zapadá do cílů DSL.

Jedna věc si ale nemyslím, že by se o ní někdo zmínil - s vlastním IDE) byste mohli mít skutečně tvrdý a měkký prostor. Vypadali by podobně (možná mají v IDE různé odstíny) .

V tom případě to můžete udělat hned s jakýmkoli jazykem - stačí na svém IDE) přepnout, aby se podtržítka zobrazovaly jako mezery. Každý, kdo vytvoří pluginy Eclipse, by to pravděpodobně mohl udělat za hodinu .

Je také možné pragmaticky převést velbloud na "slova s ​​mezerami", vaše IDE to může udělat za vás, ale bylo by to trochu podivnější).

0
Bill K