2013-01-10 16 views
43

Uważam, że byłoby użyteczne mieć konwencję nazewnictwa dla zmiennych JavaScript, które posiadają obietnicę. Generalnie nie lubię ani nie zalecam konwencji nazewnictwa wykraczających poza standardy programowania, ale w stylu programowania, w którym obietnice są przekazywane jako argumenty funkcyjne, często trudno jest stwierdzić na pierwszy rzut oka, czy zmienna zawiera obietnicę, czy "rzeczywistość".Konwencja nazewnictwa JavaScript dla obietnic?

Osobiście użyłem promiseOfFoo i pFoo, ale uważam, że ten pierwszy jest nieco gadatliwy, a ten drugi daje mi retrospekcje z języka węgierskiego.

Czy istnieje powszechnie stosowana konwencja?

+1

co z 'fooPromise'? – jbabey

+13

co z 'Froomise'? – elclanrs

+0

Jako dodatkowe uzasadnienie mojego głosowania, aby zamknąć: podczas gdy są z pewnością konwencje, to pytanie prawdopodobnie doprowadzi do wielu dyskusji na temat zalet i wad różnych zastosowań słów i skrótów, a jako takie nie ma a * pojedyncza * faktyczna odpowiedź. Ale nadal uważam to za dobre pytanie (może nie dla SO), więc byłem rozdarty. I dlatego też +1. –

Odpowiedz

15

To zależy bardziej od tego, w jaki sposób zamierzasz z nich korzystać, prawda?

Jeśli Twój kod wygląda następująco:

var imageLoading = loadImage(url); // returns promise 
imageLoading.done(showImage); 

// imageLoading.done 
// imageLoading.error 
// imageLoading.then 
// imageLoading.success 
// imageLoading.fail 
// ... whatever your library supports 

Następnie, mógłbym zasugerować nazwanie czegoś obietnica jak prezent-napięta czasownika ...

ale jeśli jesteś budowy biblioteki, która zależy od odroczone obiekty

// accepts a promise 
var showImage = function (promise) { 
    promise.done(function (img) { /* ...... */ }); 
}; 

Wtedy nie ma nic szczególnie złego nazewnictwa zmienną jako rzeczownik, tak długo jak nie ma zrozumienia, co do których metody wziąć obietnic a które nie.

var image = loadImage(url); // returns promise 
showImage(image);   // acts on promise 

Teraz Twoje interfejsy są naprawdę czyste i możesz napisać kod, który wygląda na 100% proceduralny. ... buuuut, musisz wiedzieć, które funkcje/metody używają obietnic i które używają obiektów.

Jeśli jesteś przejazdem obietnic jak wywołania zwrotne, wewnątrz metod obiektowych, można szczęśliwie nazwać je promise lub tweetLoading lub dataParsing lub cokolwiek sens w kontekście tej konkretnej sytuacji.

Dla definicji showImage wybrany parametr to flat-out o nazwie promise, więc jeśli pracujesz nad tą funkcją lub potrzebujesz debugowania łańcucha rzeczy, możesz zobaczyć, kiedy wyglądasz na to, że wziął obiekt obietnicy.

+2

+1. Podoba mi się obecny pomysł na bierkę ("verb-ing"), choć miałoby to zastosowanie tylko wtedy, gdy ** akcja ** jest ważna dla znaczenia obietnicy (jak "dataParsing"). Często obietnice dotyczą wyniku końcowego (danych), więc w tych przypadkach nie tak dużo. Podoba mi się również pomysł nazywania parametru funkcji po prostu "obietnica" i wnioskowanie o znaczeniu z kontekstu. Dobre pomysły, ale żadnych konwencji. – jevakallio

+0

@fencliff obietnice są często związane z efektem końcowym, ale biblioteki-API dla subskrypcji obietnicy skupiają się wokół akcji 'tweet.done (callback)' kontra 'loading.done (callback)', odraczając dostępność wartości zależy od jakiegoś działania (nawet jeśli jest to po prostu sondowanie po pewnym czasie). To prawie uniwersalne. Jeśli chodzi o konwencje, naprawdę ich nie widzę. Napisz, co czyta dobrze, zamiast wymuszać nowe węgierskie lub przyjmując prefiks/przyrostek '_00_p' jako standardową konwencję. Więcej ludzi będzie w stanie zrozumieć 'loading.finished();' niż 'prefix_X.done();' – Norguard

+0

Jeśli myślisz o tym, nazywając je imiesłowem teraźniejszym ('loading', 'fetching', 'saving') skutecznie używasz konwencji sufiksowej ("ing") w przeciwieństwie do konwencji prefiksu ("p_" lub cokolwiek innego). Bez większych różnic, z wyjątkiem prawdopodobnie stopnia czytelności dla osób posługujących się językiem angielskim. Wiele innych języków nie ma lub nie wykorzystuje, przedstawia imiesłów, więc nie jestem pewien, czy jest to dobra konwencja do wykorzystania na całym świecie. –

0

nie wiem od konwencji publicznego, ale używali następujących w moim kodu:

  • var dfrd: odroczonym przedmiot (nie mam potrzeby przypomnieć dwa lub więcej takie same kiedykolwiek zakres)
  • var p: Promise
  • var p_foo: jeden z kilku wymienionych Promises
  • var promises: tablica lub zwykły przedmiot zawierający Promises

Wyjątkiem jest obiekt o nazwie jqXHR, który nazwie var jqXHR (ponownie, nie przypominam sobie, że potrzebuję dwóch lub więcej w tym samym zakresie).

+0

Za krótko - choć trochę blisko Węgierskiej Notacji (https://en.wikipedia.org/wiki/Hungarian_notation) –

Powiązane problemy