Naamconventies: camelCase versus underscore_case? wat vind je ervan? [gesloten]

Persoonlijk geef ik de voorkeur aan underscore_case omdat ik het leesbaarder vind, maar ik ben het eens met de andere antwoorders die erop wijzen dat consistentie met de bestaande codebase veel belangrijker is.

Ik heb echter een tegenvoorbeeld voor degenen die zeggen ” volg de conventie van uw taal en zijn bibliotheken “.

In het verleden hebben we C-code op Windows geschreven met underscore_case, en Win32-functies:

if (one_of_our_conditions_is_true()) { call_one_of_our_functions(); CallSystemFunction(); } 

Het visuele onderscheid tussen onze functienamen en de functienamen van Microsoft was eerder een hulp dan een belemmering, aangezien het liet duidelijk zien wanneer de code naar “systeemland” ging.

Bovendien was ik in staat om de regels voor syntaxisaccentuering van mijn editor te wijzigen om ze in verschillende kleuren weer te geven, wat verdere visuele aanwijzingen gaf bij het proberen begrijp onbekende delen van de code (of zelfs die van mijzelf).

Ik hou echt van Dylans gewoon-normale-streepjes-zoals-ze-gemakkelijk-te-typen-en-gemakkelijk zijn -to-read.

Like

result-code := write-buffer(file-stream, some-string) 

Maar ik denk dat, aangezien deze taal nogal obscuur is, dit een beetje off-topic is. .. 🙁

Reacties

• Ik ben ook moe om op shift te drukken voor het typen van onderstrepingstekens.
• Dit is meestal niet mogelijk voor variabelenamen, aangezien " – " meestal min betekent.

Ik heb op de universiteit camelCase geleerd. Ik heb de afgelopen jaren een paar verschillende conventies gebruikt, maar geef de voorkeur aan camelCase boven iets anders. Ik denk dat ik me herinner dat ik ergens gelezen heb dat camelCase eigenlijk het gemakkelijkst te lezen en te begrijpen is.

Opmerkingen

• nou, het ' is niet eenvoudiger omdat je ergens leest, het ' is eenvoudiger omdat het was de eerste waarmee je werkte en vooral omdat je er meer aan gewend bent, bijvoorbeeld i ' m meer vertrouwd met underscore_case.
• zoals in i ' heb gelezen dat er een onderzoek is gedaan en vond dat het beter was.

Ik gebruik soms een mix: module_FunctionName. Alle (niet-statische) functies in mijn modules beginnen met een module-afkorting.

Bijvoorbeeld een functie voor het verzenden van de inhoud van een buffer op de I2C-bus:

i2c_BufferSend() 

Het alternatief i2c_buffer_send laat een onvoldoende grote scheiding zien tussen prefix en functienaam. i2cBufferSend mengt zich in de prefix te veel (er zijn nogal wat I2C-functies in deze module).

i2c_Buffer_send zou echter een alternatief kunnen zijn.

Mijn antwoord is dat je je aanpast aan wat het beste werkt voor je project (je taal, je SW-architectuur, …), en ik wilde erop wijzen dat het combineren van deze stijlen nuttig kan zijn.

myGeneralOpinionIsThatNamesAreMuchHarderToReadInCamelCase. I_respect_the_fact_that_some_could_think_otherwise_but_I_do_not_really_understand_why.

Reacties

• +1 voor de laatste 2 regels, maar ik raad je niet aan om naamconventies te combineren, je moet bij een van deandere.
• Zolang de conventie goed gedefinieerd is (voorvoegsel + onderstrepingsteken + PascalCase) …
• Ik gebruik graag onderstrepingstekens om delen van een naam te scheiden die semantisch gescheiden zijn doeleinden, vooral als gemeenschappelijkheid op beide helften significant kan zijn. De routines Motor1_Start(), Motor2_Start(), Motor1_Stop() en Motor2_Stop() een relatie hebben die misschien minder duidelijk is zonder de onderstrepingstekens.

Persoonlijk , Ik geef de voorkeur aan camelCase, maar in sommige lettertypen denk ik dat underscores gemakkelijker te lezen zijn.

Ik zou willen voorstellen dat als je voorvoegsels moet gebruiken om sets variabelen te onderscheiden, je een taal moet gebruiken waarmee je naamruimten kunt maken of objecten of iets om die informatie vast te houden.

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

Evenzo, als u typen moet onderscheiden, waarom zou u dan geen taal gebruiken die ze toestaat?

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

Als je dat eenmaal duidelijk hebt, en je “gebruikt de naam niet alleen als metagegevens, dan heb je niet genoeg lange namen om maakt heel veel uit of u die extra toetsaanslag verkiest of niet.

Reacties

• Een van de redenen om camelCase of underscore_case te gebruiken is dat ik ' t moet de objectdefinitie vinden om te onderscheiden wat het is.

In eerste instantie ben ik het eens met dafmetal . Het is van het grootste belang dat u geen verschillende programmeerstijlen mengt. Dit in een en hetzelfde bestand doen, is het ergste dat u IMHO kunt doen. In verschillende bestanden is het afleidend, maar niet fataal.

Het volgende dat u moet doen, is het benoemen van regels die populair zijn voor de taal waarin u schrijft. Mijn C ++ code voor instnace zal zien er anders uit dan iets voor Python (PEP8 is hier een mooie gids)

Je kunt ook verschillende naamgevingsconventies gebruiken om naar verschillende dingen te verwijzen, net zoveel als je waarschijnlijk UPPER_CASE gebruikt voor constanten (dit is alleen van toepassing op bepaalde talen natuurlijk), kun je this_style gebruiken voor lokale variabelenamen, terwijl je camelCase gebruikt voor bijvoorbeeld / member-variabelen. Dit is misschien niet nodig als u zaken heeft zoals self of this.

Update

Laten we eens kijken naar een geval waarin het platform Foo heks geen naamconventies aanbeveelt en het de keuze van de teamleider is om er een te kiezen. Jij bent die teamleider, waarom zou je camelCase kiezen of waarom underscore_case.

Er zijn eigenlijk geen voordelen voor de een boven de ander. Deze kwestie is erg subjectief en als het eenmaal is overeengekomen, zal het geen verschil maken. Er zijn altijd religieuze oorlogen over deze kleine dingen. Maar als je eenmaal aan een van beide gewend bent, lijken de discussies volkomen overbodig te zijn.

Om Alex Martelli te citeren over een zeer vergelijkbare kwestie:

Natuurlijk word ik er in Ruby wel moe van om het dwaze einde aan het einde van elk blok te typen (in plaats van gewoon niet-inspringend) – maar dan moet ik het even dwaze : vermijden dat Python vereist aan de start van elk blok, dus dat “is bijna een wasbeurt :-). Andere syntaxisverschillen zoals” @foo “versus” self.foo “, of de grotere betekenis van case in Ruby versus Python, zijn eigenlijk net zo irrelevant voor mij.

Anderen baseren hun keuze van programmeertalen ongetwijfeld op zulke kwesties, en ze genereren de heetste debatten – maar voor mij is dat gewoon een voorbeeld van een van de Parkinsonswetten in actie ( het bedrag van de discussie over een kwestie is omgekeerd evenredig met het werkelijke belang van de kwestie ).

Bron

Als je de teamleider bent, ga je er gewoon voor. Aangezien de een geen voordelen heeft ten opzichte van de ander, kun je gewoon dobbelstenen gooien of kiezen wat je leuker vindt.

Ik las een aantal jaren geleden dat programmeurs die geen Engels als eerste taal spreken de neiging hebben om onderstrepingstekens gemakkelijker te begrijpen dan die kamelenkoffer, maar ik kan de referentie niet vinden en ik heb geen idee of het waar is.

Voor programmeertalen die ik heb gebruikt, zoals Java, Python, C ++, heb ik een duidelijk formaat aangenomen:

• ClassNamesArePascalCase
• methodNamesAreCamalCase
• variable_names_are_underscore
• CONSTANT_VARIABLES_ARE_CAPITAL_VARIABLES

Hierdoor kan ik onderscheid onmiddellijk waar ik mee te maken heb. Ik heb gemerkt dat dit nuttig is om voor mezelf te onderhouden, en het zou gemakkelijk te volgen moeten zijn voor iemand anders die de code leest. Ik denk dat, zoals anderen zeiden, consistentie het belangrijkst is. Dus ik vind mijn formaat om eenvoudig genoeg te zijn om te onderhouden, terwijl er duidelijk onderscheid wordt gemaakt tussen typen namen. Ik zou interface_Names_Are_Like_This en Abstract_Classes_Are_Like_This kunnen voorstellen als mogelijke extensies, maar het lijkt ingewikkelder om te volgen en misschien niet zo nuttig om een onderscheid te maken.

Ik vond het ook handig om strikt te zijn en dingen in PascalCase te benoemen, zoals een HTML-parser als HtmlParser in plaats van HTMLParser of HTMLparser. Omdat ik denk dat het gemakkelijker is om de strikte regel te onthouden en de woordgrenzen duidelijker te houden (helaas vereist het spelfouten zoals HTML of SQL). Evenzo met camelCase, htmlParserMethod in plaats van HTMLParserMethod of HTMLparserMethod.

UPDATE :

Ik heb sindsdien gebruik gevonden bij het uitbreiden van deze regels met privévariabelen.- _private_variable_names_are_prefixed_with_an_underscore – _PRIVATE_CONSTANT_VARIABLES_ARE_PREFIXED_WITH_AN_UNDERSCORE

In Java betekent dit dat privévelden zich per definitie in een andere naamruimte bevinden dan lokale variabelen, wat betekent dat je de iv idd = velden. Andere formaten Ik heb het voorvoegsel gezien met “m“, maar die formaten gebruiken ook camelCase voor de variabelenamen. Hierdoor kan ik ook een onderscheid maken tussen velden die alleen intern toegankelijk zijn door de klas (en het super duidelijk maken wanneer het buiten de klas gebeurt object._field_x valt op).

Als het aan mij lag, zou ik het niet afdwingen of erop duiden het gebruik van een bepaalde stijl, omdat we als programmeurs een symbool IfItIsInCamelCase of in_underscore_space of zelfs in_SomeOtherStyle zouden kunnen lezen en begrijpen wat het betekent. van dingen.

Nu, het belangrijkste argument voor een conventie is, denk ik, dat je van tevoren weet wat het formaat van een functie / variabelenaam is en dat je het niet hoeft op te zoeken – is het LoadXMLFile, loadXMLFile , LoadXmlFi le, load_xml_file? Nu zou ik dat argument tegengaan door te zeggen: “Koop een IDE die automatische aanvulling in intellisense-stijl ondersteunt!” (niet altijd mogelijk).

Uiteindelijk maakt het echter niet echt uit welke stijl je gebruikt, want het kan de compiler / interpreter niet echt schelen. Wat belangrijk is, is dat de naam nuttig is:

NumberOfPrisonersReleasedByAccident manufacturer_name distance_EarthToMoon 

Drie verschillende stijlen, maar je weet precies wat ze allemaal doen.

Opmerkingen

• Ik wil graag verschillen, het uiterlijk van de bron is belangrijk. Zie " De pragmatische programmeur " ' s theorie van gebroken vensters. Verschillende naamgevingsconventie maakt het uiterlijk erger. pragprog.com/the-pragmatic-programmer/extracts/software-entropy
• @Gauthier: hoewel ik het eens ben met de ' gebroken venster ' idee, ik denk niet ' niet dat hoofdlettergebruik van symbolen een ' gebroken venster '. Lukraak opgemaakte code is dat zeker, en mijn huidige project heeft zeker veel van die dingen die ik probeer op te ruimen wanneer ik maar kan.
• Ik ben het ermee eens. Ik kan ze alle drie even goed lezen. Het maakt ' niet uit. Ik gebruik gewoon wat het bestand gebruikt, wat de taal ook voorstelt (python) en dan alles waarvan ik denk dat het project het beste kan worden bediend. (Ik programmeerde vroeger in gwbasic, en het waren allemaal hoofdletters – vroeger!)

Klinkt misschien raar, maar ik hou niet van onderstrepingstekens omdat het onderstrepingsteken dun is en zich verbergt in tekst met meerdere regels en ik mis het. Ook in sommige (veel) teksteditors en / of ontwikkelomgevingen, als je dubbelklikt op een tokennaam om het te markeren om het te kopiëren of te slepen en neer te zetten, het systeem zal niet het hele token markeren, het markeert slechts een deel van het token, tussen aangrenzende onderstrepingstekens. Dat maakt me gek.

Ik geef de voorkeur aan camelCase vanwege de dwaze reden dat ik het grootste deel van mijn ontwikkeling doe in Eclipse (voor Java, PHP en JavaScript), en wanneer ik Ctrl + ← of Ctrl + → via woorden, het stopt eigenlijk bij de camelCase-grenzen.

Dat wil zeggen: myIntVariable zou door Eclipse worden behandeld als 3 woorden wanneer Ct rl + ←   → ” er doorheen.

Ik weet dat het een rare gril is, maar ik merk dat ik er de voorkeur aan geef de middelste woorden in een camelCase-naam te kunnen bewerken.