Funktion nimi, joka sisältää and on väärällä abstraktiotasolla .

Kallistun kohti addResponseIdToDB(), koska muuten sivuvaikutus on täydellinen yllätys. Kuitenkin:

responseIds = addResponseIdToDB(); 

ei yllättä ketään.

Komennon komentokyselyvastuuerotteluperiaate väittää, että tämän ei pitäisi olla ainoa tapa saada responseId-objekti. Lisäksi pitäisi olla kysely, joka ei muuta DB: tä, joka voi saada tämän objektin.

Päinvastoin kuin Bertrand Meyer , en usko, että tämä tarkoittaa, että lisäyksen on palautettava mitätön. Tämä tarkoittaa vastaavan puhtaan kyselyn olemassaoloa ja se on helppo löytää, joten tietokantaa ei turhaan väärinkäytetä tilanvaihtokyselyjen avulla.

_{Kun otetaan huomioon, että getResponseIds() pitäisi olla olemassa eikä puhua tietokannan kanssa, molempia tekevän menetelmän paras nimi on todella addToDB(getResponseId()). Mutta se on vain, jos haluat saada siitä kaiken toiminnallisen koostumuksen.}

Kommentit

• Lisätään sanottuun, mutta lisäämällä sana, jota ei ole käytetty ’ t, sanoisin, että ” ja ” on tarkoituksenmukainen, kun funktio tekee jotain, joka on atomia . Jos kahdesta atomisesti / yhdessä / kerralla tapahtuvasta asiasta on hyötyä, on selvää, mitä nämä kaksi asiaa ovat funktiossa nimi on hyvä. Joten olen samaa mieltä ensimmäisen lausuntosi kanssa, mutta olen eri mieltä ilman pätevyyttä.
• ” … ei jätä ketään yllättynyt. ”. Olen eri mieltä, olen ’ m lähtenyt yllättynyt siitä, että looginen muuttuja on nimeltään responseIds ja minun on sitten tehtävä henkinen muutos ymmärtääkseni, että se lisää ja saa kaikki yhteen. Mutta olen eri mieltä @tintintongin kanssa siitä, että getAndAddResponseIdsToDB on liian pitkä; se ’ on noin puolet pitkistä monista funktionimistäni. Jos funktio tekee kaksi asiaa, sano se sen nimessä.
• @Luaan OK, mihin nimität sitten getAndIncrement? otherIncrement?
• @Luaan Joten minkä arvon Increment palauttaa, arvon ennakko- tai lisäysarvon? ’ ei ole selvää, mikä se olisi ilman sukellusta asiakirjoihin.Mielestäni incrementAndGet ja getAndIncrement ovat paljon parempia menetelmien nimet, mikä mielestäni on hyvä tapaus ” JA ” menetelmien nimissä, ainakin niiden menetelmien erityistapauksissa, joilla on sivuvaikutuksia, jotka voivat vaikuttaa palautusarvoon ..
• @Luaan Kun sanot ” Inkrementti palauttaa inkrementoidun arvon ” tarkoitatko lisäyksen arvoa? Gotcha, ymmärsin sinut aluksi väärin .. mikä on todella hieno esimerkki miksi getAndIncrement ja incrementAndGet ovat parempia nimiä kuin vain increment, vaikka niitä tarkastellaan erikseen

Kuten muut ovat maininneet, and -toiminnon käyttäminen funktion nimessä tarkoittaa automaattisesti, että funktio tekee vähintään kahta asiaa, mikä yleensä tarkoittaa, että se tekee liikaa tai tekee jotain väärässä paikassa.

and -lausekkeen käyttäminen funktion nimessä voi kuitenkin kokemukseni mukaan olla järkevää, kun tietyssä vuossa on joitain vaiheita, jotka täytyy suorittaa peräkkäin tai kun koko laskennasta tulee merkitystä.

Numeerisessa laskennassa tämä voi olla paljon järkevää:

normalizeAndInvert(Matrix m)

Tarkoitan, kuka tietää, eikö? Jos joudut laskemaan joitain … esimerkiksi valaistusreittejä tietokonegrafiikassa ja tietyssä paikassa vaiheessa sinun on normalisoitava ja käännettävä tietty matriisi, ja huomaat jatkuvasti kirjoittavan:

m = normalize(m), jota seuraa invert(m), aivan kuten yksinkertainen esimerkki normalisoinnin ja kääntämisen abstraktin käyttöönotosta, voi olla hyvä luettavuuden näkökulmasta.

Semanttisesti puhuen esimerkiksi divideAndConquer() jne., ei todennäköisesti kannata kirjoittaa nimenomaisesti, mutta no, siellä oleva And on periaatteessa välttämätön.

kommentit

• Toiminnot tekevät säännöllisesti useampaa kuin yhtä asiaa, mutta näiden pitäisi olla pieniä asioita, jotka muodostavat yhden suuren asian, joka ’ on mielekästä korkeammalla tasolla. normalizeAndInvert voi olla computeLighting ja divideAndConquer voi olla applyMachiavelli
• Ilmeisesti 🙂 Ilmoitetaan vain, että ensin luodaan funktio, jonka nimessä on ” ja ” voi tulla luonnollinen abstraktio, joka perustuu tiettyyn kontekstiin. Refaktorointi ” Nimeä uudelleen -menetelmän avulla ” tulisi tulla heti sen jälkeen;)
• @BrunoOliveira Paitsi, että nämä kaksi vaihetta ovat itsensä monien asioiden komponentti, nimeä uudelleen ’ t oikea lähestymistapa. Ja sen pitäisi olla harvinaista, mutta koskaan käyttämättä sitä tarkoittaa, että ’ toistat itsesi uudelleen.

Todellakin, että ”kysymykseen on vaikea vastata, koska useat kommentit voivat todistaa. Ihmisillä näyttää olevan ristiriitaisia mielipiteitä ja neuvoja mikä on hyvä nimi.

Haluaisin lisätä 2 senttini tähän 2 kuukauden ikäiseen säikeeseen, koska luulen voivani lisätä värejä jo ehdotettuihin.

Nimeäminen on prosessi

Kaikki tämä muistuttaa minua erinomaisesta 6-vaiheisesta oppaasta: Nimeäminen prosessina .

Huono funktion nimi on yllättävä ja huomaat, ettet voi luottaa. Hyvää nimeämistä on vaikea saada oikein ensimmäisessä laukauksessa. Kokemuksen avulla se on helpompaa.

6 toistettavaa vaihetta hyvän nimen rakentamiseksi

1. Korvaa yllättävä nimi ilmeisellä hölynpölyllä kuten appleSauce(). Kuulostaa typerältä, mutta se on väliaikaista ja se tekee selväksi, että nimeen ei voida luottaa.
2. Rehellinen nimi sen perusteella, mitä ymmärrät toiminnon toiminnasta. Oletetaan, ettet vielä ymmärtänyt lisäystä DB-osaan, getResponseIdsAndProbablyUseDb olisi vaihtoehto.
3. Hae täysin rehelliseen , joten funktion nimi kertoo kaiken toiminnon (getAndAddResponseIdsToDB tai getResponsesButAlsoAddCacheOfTheResponsesToTheDb @ @ Fattie ovat hyviä esimerkkejä)
4. Pääset ”tekee oikein” , joka on pohjimmiltaan osa, jossa jaoit funktion ”JA” -merkillä. Sinulla on siis getResponseIds ja addResponseIdsToDb.
5. Siirry ”Tarkoituksen paljastava” -nimeen , joka ratkaisee ”Haluan aina saada vastaustunnuksen I lisätty DB: hen sen jälkeen kun olen tehnyt niin ”. Lopeta ajatteleminen toteutuksen yksityiskohdista ja rakenna abstraktio, joka käyttää kahta pienintä toimintoa rakentaakseen jotain muuta. Tämä on @candied_orange mainitsema korkeamman abstraktion taso. xample createResponseIds voisi tehdä sen, ja siitä koostuu getResponseIds ja addResponseIdsToDb.
6. Siirry verkkotunnuksesi abstraktioon . Tämä on vaikeaa, se riippuu yrityksestäsi. Yrityksen kielen kuunteleminen vie aikaa päästäksesi oikeaan. Lopulta saatat päätyä käsitteeseen Response ja Response.createIds() olisi järkevää. Tai ehkä ResponseId on jotain arvokasta, ja sinulla olisi tehdas luomaan monia. Lisäys DB: hen olisi tietovaraston toteutustiedot jne. Kyllä. Suunnittelu olisi abstraktimpi. Se olisi rikkaampi ja antaisi sinun ilmaista enemmän. Kukaan tiimisi ulkopuolella ei voi kertoa sinulle, mitä oikean verkkotunnuksen tulisi olla tilanteessasi. Se riippuu .

Sinun tapauksessasi olet jo selvittänyt 1 ja 2, joten sinun pitäisi todennäköisesti mennä ainakin kohtaan 3 (käytä ”AND”) tai pidemmälle. Mutta pidemmälle meneminen ei ole vain nimeämiskysymys, vaan itse asiassa jaat vastuun.

Siksi eri ehdotukset ovat kelvollisia

Pohjimmiltaan:

• Kyllä, yllättävät funktioiden nimet ovat kauheita, eikä kukaan halua käsitellä sitä.
• Kyllä, ”AND” on hyväksyttävä funktion nimessä, koska se on parempi kuin harhaanjohtava nimi
• Kyllä, abstraktiotaso on liittyvä käsite ja sillä on merkitystä

Sinun ei tarvitse mennä heti vaiheeseen 6, on hyvä pysyä vaihe 2, 3 tai 4, kunnes tiedät paremmin!

Toivon, että siitä olisi hyötyä, kun annettaisiin erilainen näkemys ristiriitaisista neuvoista. Uskon, että kaikki pyrkivät samaan päämäärään ( ei-yllättäviä nimiä), mutta pysähtyvät eri vaiheissa heidän omien kokemustensa perusteella. 🙂

Funktiollasi on kaksi asiaa:

1. Hankkii joukon tunnuksia muunnoksen kautta ja palauttaa ne soittajalle.
2. Kirjoittaa kyseisen tunnistetiedoston tietokantaan.

Muista tässä yhden vastuun periaate: sinun tulisi pyrkiä toimintoon olla yksi vastuu, ei kahta. Sinulla on kaksi vastuuta, joten sinulla on kaksi toimintoa:

getResponseIds – Hankkii joukon tunnuksia muunnoksen kautta ja palauttaa ne soittajalle
addResponseIdToDB – Ottaa joukon tunnuksia ja kirjoittaa ne tietokantaan.

Ja koko asia siitä, mitä kutsutaan yhdeksi funktioksi, jolla on useita vastuita, katoaa ja kiusaus laittaa and funktioiden nimiin myös katoaa.

Lisäbonuksena, koska sama toiminto ei enää ole vastuussa kahdesta etuyhteydettömästä toiminnasta, getResponseIds voitaisiin siirtää repokoodistasi (mihin se ei kuulu) koska se ei tee mitään tietokantaan liittyvää toimintaa), erilliseen yritystason luokkaan / moduuliin jne.

Kommentit

• Että ’ on varmasti totta, mutta huomaat toistavan koodinpätkää näiden kahden SRP-menetelmän avulla monta kertaa, sinun pitäisi luultavasti kirjoittaa triviaali menetelmä tekemällä niin, että KUIVAAT, shouldn ’ t sinä?
• @maaartinus, jos huomaat kutsuvasi näitä kahta menetelmää monissa paikoissa, sinulla on todennäköisesti ongelma koodisi koheesion puutteesta. ” DRY ” -funktion luominen vain peittää tämän yhteenkuuluvuuden puutteen.

Yhdistetyn funktion nimen saaminen on hyväksyttävää, joten käyttämäsi nimeämismalli riippuu kontekstistasi. On puristeja, jotka käskevät sinua hajottamaan sen, mutta väitän toisin.

On kaksi syytä yrittää välttää sellaisia asioita:

• Puhtaus – toiminto joka tekee kaksi asiaa, tulisi muuntaa kahdeksi toiminnoksi, jotka tekevät yhden asian.
• Leksikaalinen koko – bigUglyCompositeFunctionName on vaikea lukea.

Puhtausargumentti on tyypillisesti se, johon keskitytään. Epämääräisenä yleisenä heuristisena toimintojen hajottaminen on hyvä asia. Se auttaa jakamaan tapahtumia osiin, mikä helpottaa ymmärtämistä. Olet vähemmän todennäköisesti tekemässä ”älykkäitä” temppuja muuttujien jakamisen kanssa, mikä johtaa kahden käyttäytymisen yhdistämiseen.

Joten itsellesi kysyttävää on ”pitäisikö minun tehdä se joka tapauksessa?” Sanon, että asioiden hajottaminen on epämääräistä heuristista, joten tarvitset oikeastaan vain kunnollisen argumentin vastustamaan sitä.

Yksi tärkeimmistä syistä on, että on hyödyllistä ajatella kahta operaatiota yhtenä. Loppujen lopullinen esimerkki tästä löytyy atomitoiminnoista: compare_and_set. compare_and_set on atomien peruskulma (joka on tapa tehdä monisäikeinen ilman lukituksia), joka on riittävän menestyvä, että monet ovat halukkaita ajattelemaan sitä the kulmakivi. Siellä on ”ja” siinä nimessä. Tähän on erittäin hyvä syy. Tämän operaation koko tarkoitus on, että se tekee vertailun ja asetuksen yhtenä jakamattomana operaationa. Jos hajoitit sen osiin compare() ja set(), hävisit koko syyn, miksi toiminto oli olemassa, koska kaksi compares() voi tapahtua taaksepäin ennen set() s.

Näemme tämän myös suorituskyvyssä. Suosikkiesimerkkini on fastInvSqrt . Tämä on Quaken kuuluisa algoritmi, joka laskee 1 / sqrt (x). Yhdistämme käänteiset ja neliöjuuret, koska se antaa Meillä on valtava suorituskyvyn parannus. He tekevät Newtonin likiarvon, joka suorittaa molemmat operaatiot yhdessä vaiheessa (ja sattuu tekemään se kokonaislukumatematiikassa eikä kelluvassa pisteessä, jolla oli merkitystä aikakaudella). Jos tekisit inverse(sqrt(x)), se olisi paljon hitaampaa!

Joskus tulos on selkeämpi. Olen kirjoittanut useita ohjelmointirajapintoja, joihin liittyy ketjuttaminen ja joissa on oltava pelottavan varovainen esimerkiksi umpikujasta. En halunnut, että käyttäjä tietäisi sisäisen toteutuksen yksityiskohdat (varsinkin kun voin muuttaa niitä), joten kirjoitin API: n muutama ”ja” toiminto, jotka estivät käyttäjää koskaan pitämästä lukkoa useamman kuin yhden toimintopuhelun yhteydessä. Tämä tarkoittaa, että heidän ei tarvinnut koskaan tietää, kuinka käsittelin monisäikeistä synkronointia hupun alla. Itse asiassa suurin osa käyttäjistäni ei edes tiennyt olevansa monisäikeisessä ympäristössä!

Joten vaikka yleinen sääntö on hajottaa asiat, voi aina olla syytä yhdistää heidät yhteen. Esimerkiksi , voiko käyttäjä rikkoa arkkitehtuurisi lisäämällä tietokantaan useita kertoja ilman ”saa” väliin? Jos jokaisella DB: ään kirjautuneella vastauksella on oltava yksilöllinen tunniste, voit joutua vaikeuksiin, jos käyttäjän on tehtävä ne tahattomasti Samoin, haluaisitko koskaan antaa käyttäjän ”saada” kirjautumatta tulosten tietokantaan? Jos vastaus on ”kyllä”, hajota ne niin, että käyttäjä voi käyttää ”get” -toimintoa. Jos kuitenkin sovelluksesi suojaus on rikki, jos käyttäjä voi ”saada” ilman tulosta kirjautumalla DB: hen, sinun on todella pidettävä toiminnot yhdessä.

Leksikaalisten ongelmien osalta funktion nimesi tulisi kuvata mitä käyttäjän on tiedettävä siitä. Aloitetaan ”get” -osiossa.Sen on melko helppo poistaa ”get” funktion nimestä, koska kaikissa esimerkeissäsi näkyy tehtävä: int id = addResponseIdToDB() ”. Kaikissa paikoissa, joissa toimintoa käytetään, lopetat dokumentoidaan, että funktio palautti arvon.

Samoin ”add” voi olla valinnainen. Käytämme termiä ”sivuvaikutus” kattavana terminä, mutta siinä on erilaisia sävyjä. Jos DB-merkinnät ovat vain loki, ei voi olla syytä korostaa sitä. Emme koskaan näe sellaisia toimintoja kuin playMusicAndSendPersonalInformationToOurCorporateServers. Se on vain playMusic, ja jos olet onnekas, dokumentaatiossa voidaan mainita jotain Internet-liitännästä. Toisaalta, jos käyttäjien odotetaan kutsuvan tätä toimintoa lisätäkseen asioita tietokantaan, lisäys on välttämätöntä. Älä ota sitä pois.

Nyt olen kirjoittanut paljon syitä tehdä kaikki mahdolliset yhdistelmät pyyntösi kanssa. En ole tarkoituksella vastannut kysymykseen, koska on tehtävä valinta. Sitä ei ole noudatettava sääntö. Teet uudelleen API: n.

Sanon kuitenkin, että vaistoni on, että addResponseIdToDB on todennäköisesti paras vastaus. Useimmissa tapauksissa ”get” -osa on riittävän ilmeinen sivuvaikutus, että se ei ansaitse ylimääräistä melua, joka syntyy kirjoittamalla se kaikkialle. On kuitenkin muutamia paikkoja, joissa voisin pitää sitä tärkeänä:

• Jos ”get” on kallista – Jos joudut suorittamaan ”get” -toiminnon, johon sisältyy jonkin haeminen Internetistä ja sen lisääminen sitten paikalliseen välimuistitietokantaan, ”get” on ehdottomasti tärkeä. Käyttäjä yrittää tehdä sitä.
• Jos sinun on tehtävä selväksi, että käyttäjän on kiinnitettävä huomiota arvoon. Jos käyttäjä haluaa käyttää muuttujaa, hän ymmärtää, että sovellusliittymä palauttaa sen ja käyttää sitä. Haluat kuitenkin varoa käyttäjää, joka ei tiedä tarvitsevansa sitä. Esimerkiksi, jos joudut ”sulkemaan” tämän toiminnon tunnuksella myöhemmin muistin vapauttamiseksi, sinun kannattaa kiinnittää huomiota siihen, että ”teen jotain. Näissä tapauksissa kannattaa ehkä tarkastella muuta verbiä kuin ”saada”. ”get” tarkoittaa usein idempotenttitoimintoja (sen kutsuminen uudelleen ei tee mitään). Jos se palauttaa resursseja, muut verbit, kuten ”create” tai ”hanki”, ovat mukavia. Tämä erityinen vikamekanismi on tärkeä kysymys C: ssä, kun tehdään poikkeusten käsittelyä C: ltä puuttuu C ++: n kiinniotto / heittomekanismi, joten se luottaa palautuskoodeihin. Kehittäjät ovat kuuluisia siitä, että he eivät yksinkertaisesti tarkista näitä palautuskoodeja ja joutuvat todella huonoon tilanteeseen, kuten puskurin ylivuotoon sen takia.
• Symmetria – Joskus suunnittelet sovellusliittymän siten, että siihen liittyy leksikaalinen symmetria. Asetat sanat siten, että ne tulevat pareittain, tai muita kuvioita, ja muotoilet komennot siten, että ne on helppo tunnistaa visuaalisesti onko mallia noudatettu vai ei. Sanon, että tämä on harvinaista, mutta se ei ole ennenkuulumatonta. XML-tunnisteiden sulkemisesta johtuen toistetaan tagin nimi (kuten < foo > ja < / foo >).

Kommentit

• Ihmisille, jotka eivät div id = ”6a2f57beef”>

Mikä on lopullinen szándus tämän metan od? Miksi nämä muunnetut tunnukset lisätään tietokantaan, onko se välimuistin tarkoitus? Työskentelen tämän oletuksen alaisuudessa.

Kuulostaa siltä, että menetelmän tarkoitus on oikeastaan vain saada muunnetut vastaustunnukset (joko tehdä muunnos tai saada ne välimuistista), ja niin siellä ” menetelmän nimi:

getTransformedResponseIds tai vähemmän sanallisesti getResponseIds()

Tämän niminen menetelmä voi tallentaa välimuistiin tai ehkä ei, ja se voidaan dokumentoida, mutta metodisi nimi ei saisi sitoa sinua tiettyyn toteutukseen; Entä jos päätät lopettaa tietokannan käytön ja välimuistittaa sen muualle, kuten vain väliaikaisesti muistissa?

Sivuvaikutusten tulisi olla juuri sellaisia, että sivuvaikutukset on todennäköisesti dokumentoitava, mutta niiden ei pitäisi todella vaikuttaa toiminnon ydintarkoitukseen (tai menestykseen) tai nimeen. Jos arvon saaminen välimuistista epäonnistuu (tai jos määrität ohittaa välimuistin), jonka ei pitäisi olla kriittinen ongelma, menetelmän tulisi vain laskea uudelleen läpinäkyvästi, välimuisti (tai ei) ja palauttaa uusi arvo.

Joskus ”AND”: n käytöstä on hyötyä tarkoituksen välittämisessä, kuten Java-menetelmillä getAndIncrement ja incrementAndGet se ei todellakaan ole pöydän ulkopuolella.

Sanot, että funktio palauttaa jotain ”muunnoksesta, ei mikä tahansa db-toiminto ”.

Tämä viittaa siihen, että funktio käyttäytyy enemmän kuin konstruktori kuin getter. -rakentajien ei myöskään pitäisi aiheuttaa sivuvaikutuksia (kiitos linkistä, @ MechMK1 ).

Toisaalta tehdasmenetelmät edellyttävät jo jonkin verran sotkuisuutta . Esimerkiksi yksi tehdasmenetelmien käyttämisen motivaatio on se, että tehdasmenetelmä:

Mahdollistaa luettavamman koodin tapauksissa, joissa on useita rakentajia, joista kukin on eri syystä. – wikipedia

Samoin

Jos sinun on tehtävä jonkin verran työtä sivuvaikutusten kanssa, tehdasmenetelmä voidaan nimetä siten, että on selkeämpää mitä sivuvaikutukset ovat. – ruakh

Harkitse funktion tekemistä tehdasmenetelmäksi käyttämällä termiä ”kirjautunut” varoittamaan ohjelmoijia tietokantatallennuksesta:

• Ilmoitus: createLoggedResponseid(...) {...} // log object to db
• Soita: responseid = createLoggedResponseid(...);

kommentit

• Rakentajien ei pitäisi aiheuttaa sivuvaikutuksia
• @ MechMK1 I ’ muokkain poistamaan konstruktori -ehdotuksen ja tarjoamaan enemmän tukea asianmukaisesti nimettyyn tehdasmenetelmään. Kerro minulle, mitä sinä ajatella.