Nimeämiskäytännöt: camelCase vs. alleviivattu_kotelo? mitä mieltä olet siitä? [suljettu]

Käytän joskus sekoitusta: module_FunctionName. Kaikki moduulien (ei-staattiset) toiminnot alkavat moduulin lyhenteellä.

Esimerkiksi toiminto puskurin sisällön lähettämiseksi I2C-väylälle:

i2c_BufferSend() 

Vaihtoehto i2c_buffer_send ei näytä riittävän suurta eroa etuliitteen ja funktion nimen välillä. i2cBufferSend sekoittuu etuliite liikaa (tässä moduulissa on melko paljon I2C-toimintoja).

i2c_Buffer_send saattoi kuitenkin olla vaihtoehto.

Vastaukseni on, että mukautut projektiisi parhaiten soveltuvaan (kieli, SW-arkkitehtuurisi jne.), Ja halusin huomauttaa, että näiden tyylien sekoittaminen voi olla hyödyllistä.

myGeneralOpinionIsThatNamesAreMuchHarderToReadInCamelCase. I_ respect_the_fact_that_some_could_think_otherwise_but_I_do_not_really_understand_why.

Kommentit

• +1 kahdelle viimeiselle riville, mutta en suosittele nimeämiskäytäntöjen yhdistämistä, sinun on pidettävä kiinni yhdestä taimuu.
• Niin kauan kuin yleissopimus on hyvin määritelty (etuliite + alaviiva + PascalCase) …
• Haluan käyttää alaviivoja erottamaan osan osat, jotka ovat semanttisesti irti erityisesti, jos kummankin puoliskon yhteisyys voi olla merkittävä. Esimerkiksi rutiinit Motor1_Start(), Motor2_Start(), Motor1_Stop() ja Motor2_Stop() on suhde, joka saattaa olla vähemmän selkeä ilman alaviivoja.

Henkilökohtaisesti , Pidän parempana camelCasesta, mutta joissakin kirjasimissa mielestäni alaviivoja on helpompi lukea.

Ehdotan, että jos sinun on käytettävä etuliitteitä muuttujien erottamiseen, sinun tulee käyttää kieltä, jonka avulla voit tehdä nimitiloja tai esineitä tai jotain näiden tietojen säilyttämiseksi.

myName = 7 bobsName = 8 // :( me.name = 7 bob.name = 8 // :D 

Vastaavasti, jos sinun on erotettava tyypit, miksi et käyttäisi kieltä, joka sallii niiden?

var intThingy = 7; // :( int thingy = 7; // :) 

Kun olet saanut suoran, etkä vain käytä nimeä metadatana, sinulla ei ole tarpeeksi pitkiä nimiä sillä on suuri merkitys, haluatko ylimääräisen näppäimen painamisen vai ei.

Kommentit

• Yksi syy camelCasen tai alaviivan_kotelon käyttämiseen on, että en ’ t täytyy löytää esineiden määritelmä havaitsemaan mikä se on.

Aluksi olen samaa mieltä dafmetalin kanssa . On erittäin tärkeää, ettet sekoita eri ohjelmointityylejä. Tämän tekeminen yhdessä ja samassa tiedostossa on pahin, mitä voit tehdä IMHO: lle. Eri tiedostoissa se on häiritsevää, mutta ei kohtalokasta.

Seuraava asia, jonka sinun on tehtävä, on nimetä säännöt, jotka ovat suosittuja kielelle, jolla kirjoitat. Oma C ++ -koodini instnacelle tulee näyttää ilmeisesti erilaiselta kuin jotain Pythonille (PEP8 on mukava opas täällä)

Voit myös käyttää erilaisia nimityskäytäntöjä viitataksesi erilaisiin asioihin, yhtä paljon kuin todennäköisesti käytät vakioille UPPER_CASE (tämä koskee vain tiettyjä tietysti kielillä), voit käyttää tätä_styleä paikallisten muuttujien nimille, kun taas esimerkiksi camelCase / jäsenmuuttujia. Tätä ei ehkä tarvita, jos sinulla on esimerkiksi self tai this.

Päivitä

Otetaan tapaus, jossa sinulla on foorumi, Foo noita ei suosittele nimeämiskäytäntöjä ja se on joukkueenjohtajan valinta valita yksi. Olet sen ryhmän johtaja, miksi valitsisit camelCasen tai miksi alaviiva_kotelo.

Yhdelläkään ei ole mitään etuja. Tämä asia on hyvin subjektiivinen, ja kun siitä on sovittu, se ei tee mitään. Näistä pienistä asioista käydään aina näitä uskonnollisia sotia. Mutta kun olet sopeutunut kumpaankin, keskustelut näyttävät olevan täysin tarpeettomia.

Lainatakseni Alex Martellia hyvin samankaltaisesta asiasta:

Toki väsyn Ruby-kirjoituksessa kirjoittamaan typerä ”pää” jokaisen lohkon loppuun (pikemminkin kuin vain purkautumatta) – mutta sitten minun on vältettävä kirjoittamasta yhtä typerää ”:” joka Python vaatii jokaisen lohkon alussa niin, että ”melkein pestään :-). Muut syntaksierot, kuten” @foo ”tai” self.foo ”, tai kirjainten suurempi merkitys Ruby vs. Python ovat oikeastaan melkein yhtä merkityksettömiä minulle.

Toiset perustavat epäilemättä ohjelmointikielen valinnan juuri tällaisiin asioihin, ja he synnyttävät kuumimmat keskustelut – mutta minulle se on vain esimerkki yhdestä Parkinsonin lain toiminnasta ( asiasta käytävän keskustelun määrä on kääntäen verrannollinen asian todelliseen merkitykseen ).

Lähde

Jos olet tiiminvetäjä, mene vain yhden kanssa. Koska yhdellä ei ole mitään etuja toiseen nähden, voit vain heittää noppaa tai valita haluamasi.

Luin useita vuosia sitten, että ohjelmoijille, jotka eivät puhu englantia ensi kielenä, on tapana löytää alaviivat helpommin ymmärrettävissä tuohon kamelitapaukseen – mutta en löydä viittausta, enkä tiedä, onko se totta.

Ohjelmointikielille, joita olen käyttänyt, kuten Java, Python, C ++, olen ottanut käyttöön selkeän muodon:

• ClassNamesArePascalCase
• methodNamesAreCamalCase
• variable_names_are_underscore
• CONSTANT_VARIABLES_ARE_CAPITAL_VARIABLES

Tämän ansiosta voin havaitse heti, mitä olen tekemisissä. Olen havainnut, että siitä on hyötyä ylläpitää itselleni, ja sen pitäisi olla helppo seurata jollekin muulle koodia lukevalle. Mielestäni yhtenäisyys on tärkeintä. Joten löydän muodoni jotta se olisi riittävän yksinkertainen ylläpitää ja samalla selkeästi erotella nimityyppien välillä. Voisin kuvitella käyttöliittymän_nimet_Are_Like_This ja Abstract_Classes_Are_Like_This mahdollisiksi laajennuksiksi, mutta ne näyttävät olevan monimutkaisempia seurata eivätkä ehkä ole yhtä hyödyllisiä erottelut. > Olen myös pitänyt hyödyllisenä olla tiukka ja nimetä PascalCasessa asioita, kuten HTML-jäsennin HtmlParseriksi HTMLParserin sijaan. HTMLparser. Koska mielestäni on helpompaa muistaa tiukka sääntö ja pitää sanarajat selkeämmin (valitettavasti se vaatii kirjoitusvirheitä, kuten HTML tai SQL). Vastaavasti camelCase, htmlParserMethod HTMLParserMethod tai HTMLparserMethod sijaan.

PÄIVITÄ :

Olen löytänyt käyttöä näiden sääntöjen laajentamiseen yksityisiin muuttujiin.- _private_variable_names_are_prefixed_with_an_underscore – _PRIVATE_CONSTANT_VARIABLES_ARE_PREFIXED_WITH_AN_UNDERSCORE

Java-tilassa tämä tarkoittaa, että yksityiset kentät ovat määritelmän mukaan eri nimiavaruudessa kuin paikalliset muuttujat, mikä tarkoittaa, että voit ohittaa iv01 kentät. Muut muodot, jotka olen nähnyt etuliitteellä ”m”, mutta nämä muodot käyttävät muuttujien nimissä myös camelCasea. Tämän ansiosta voin myös tehdä eron kenttien välillä, joita tulisi käyttää vain sisäisesti luokan mukaan (ja tehdä siitä super selväksi, kun se tapahtuu luokan ulkopuolella object._field_x erottuu).

Jos se riippuisi minusta, en pakottaisi tai vihjaisi minkä tahansa tietyn tyylin käyttö, koska ohjelmoijina voimme pystyä lukemaan symbolin IfItIsInCamelCase tai in_underscore_space tai jopa in_SomeOtherStyle ja ymmärtämään, mitä se tarkoittaa. Pienen ajan käyttäminen symbolin jäsentämisessä ei ole suuri piirustus suuressa järjestelmässä asioista.

Nyt yleiskokouksen pääargumentti on luultavasti se, että tiedät etukäteen funktion / muuttujan nimen muodon ja sinun ei tarvitse etsiä sitä – onko se LoadXMLFile, loadXMLFile , LoadXmlFi le, load_xml_file? Vastustan tätä väitettä sanomalla ”Hanki IDE, joka tukee intellisense-tyylin automaattista täydennystä!” (ei kuitenkaan aina mahdollista).

Loppujen lopuksi sillä ei kuitenkaan ole väliä mitä tyyliä käytät, sillä kääntäjä / tulkki ei välitä siitä. Tärkeää on, että nimi on hyödyllinen:

NumberOfPrisonersReleasedByAccident manufacturer_name distance_EarthToMoon 

Kolme erilaista tyyliä, mutta tiedät tarkalleen, mitä kukin tekee.

Kommentit

• Pyydän erimielisyyttä, lähteen ulkonäkö on tärkeä. Katso ” Käytännöllinen ohjelmoija ” ’ rikkinäisten ikkunoiden teoria. Nimitystavan vaihtelu pahentaa ulkonäköä. pragprog.com/the-pragmatic-programmer/extracts/software-entropy
• @Gauthier: Vaikka olen samaa mieltä ’ rikki ikkuna ’ idea, en mielestäni ’ usko, että symbolien isojen kirjainten käyttö on ’ rikki ikkuna ’. Satunnaisesti laadittu koodi on varmasti, ja nykyisessä projektissani on varmasti paljon sellaista, jonka yritän siivota aina kun pystyn.
• Olen samaa mieltä. Pystyn lukemaan kaikki kolme yhtä hyvin. Sillä ei ole ’ merkitystä. Käytän vain mitä tiedostoa käytetään, sitten mitä kieli ehdottaa (python) ja sitten mitä mielestäni projekti palvelee parhaiten. (Minulla oli tapana ohjelmoida gwbasicissa, ja kaikki olivat korkkeja – vanhoja hyviä aikoja!)

Saattaa tuntua typerältä, mutta en pidä alaviivoista, koska alaviiva on ohut ja piiloutuu useisiin viivateksteihin, ja kaipaan sitä. Lisäksi joissakin (monissa) tekstieditorissa ja / tai dev-ympäristöissä kaksoisnapsauttamalla tunnuksen nimi sen korostamiseksi kopioimiseksi tai vetämiseksi ja pudottamiseksi, järjestelmä ei korosta koko tunnusta, se korostaa vain yhden osan tunnuksesta vierekkäisten alaviivojen välissä. Se ajaa minut pähkinöiksi.

Minulla on tapana pitää parempana camelCasea siitä typerästä syystä, että teen suurimman osan kehityksestäni Eclipse-sovelluksessa (Java, PHP ja JavaScript) ja kun Ctrl + ← tai Ctrl + → sanojen kautta, se pysähtyy tosiasiallisesti camelCase-rajoille.

Eli: myIntVariable Eclipse käsittelisi 3 sanana, kun Ct rl + ←   → ” sen läpi.

Tiedän sen olevan outo oivallus, mutta mielestäni mieluummin pystyn muokkaamaan camelCase-nimen keskimmäisiä sanoja.