2009-11-16 9 views
17

Abhängig von Ihrer Interpretation kann dies eine rhetorische Frage sein oder nicht, aber es verblüfft mich wirklich. Welchen Sinn macht diese Konvention? Ich verstehe, dass Namenskonventionen nicht notwendigerweise einen Sinn oder Grund haben müssen, aber warum weichen sie von der bereits bekannten camelCase ab? Gibt es einen Reim und Grund hinter lower_case_with_underscores, die ich irgendwie vermisse? (und ja, ich habe PEP 8 in seiner Gesamtheit gelesen, und ja, ich verstehe, dass es nur ein Vorschlag, ein Führer, etc. ist)Aus welchem ​​Grund haben wir die Namenskonvention "lower_case_with_undscores"?

Ich nehme an, meine eigentliche Frage wäre das: Ich schreibe ein Python Bibliothek. In der Tat, mit etwas Glück, kann es eine ziemlich große Bibliothek sein, relativ zu meinen anderen Projekten. Ich versuche schon, so viel wie möglich an PEP 8 zu halten, und bis jetzt habe ich sogar lower_case_with_underscores als PEP 8 instruiert für Funktions- und Methodennamen. Aber es nervt mich, dass ich daran denken muss, camelCase für Twisted, camelCase für logging und so gut wie alles andere zu verwenden. Welche Namenskonvention sollte ich verwenden und warum?

Es würde wahrscheinlich die Leute verblüffen, dass mir so viel am Namen liegt, genug, um eine lange Frage darüber zu stellen, und es erstaunt mich auch. Vielleicht habe ich eine kleine OCD, wenn es um diese Dinge geht. Ich habe nicht viel von einer "persönlichen Meinung" darüber, da ich dazu tendiere, einfach das zu wählen, was am meisten benutzt wird, was in diesem Fall CamelCase wäre - aber es ärgert mich noch mehr, das herauszufinden Ich breche wahrscheinlich einige ewige Gesetze über explizite oder implizite und das Zen von Python in Stein geschrieben oder so.

+5

"aber warum weichen sie von der bereits beliebten camelCase ab?" Ich glaube, dass lower_case_with_undscores viel älter ist als camelCase. Auch ich persönlich verabscheue CamelCase jeglicher Art von MixedCase mit brennender Leidenschaft. Verwenden Sie die Konvention, die Sie bevorzugen. –

+1

Verwenden Sie Systeme Ungarisch. : P Aber im Ernst, es würde die Leute überhaupt nicht erstaunen - Codierungsstilkonventionen sind ebenso ein religiöser Krieg wie jeder andere Aspekt der Programmierung. Sie werden viele Fragen zu SO finden, die sich darauf konzentrieren, wo geschweifte Klammern oder das Zen von Leerzeichen platziert werden. – Xiaofu

+1

Wie soll Ungarisch mit Ducktyping arbeiten? : p –

Antwort

47

camelCase und/oder CamelCase (und das ist eine Debatte in seinem eigenen Recht ;-) kann für die Art von Umgebungen überwiegend beliebtesten sein Sie am besten vertraut sind mit, aber das macht kaum universal sie - oder Sie haben nie von der obskuren Sprache namens C++ mit seinen std::find_first_of und std::replace_copy_if Algorithmen und so weiter gehört ?!

Also gibt es keine "Abweichung", wie Sie in PEP 8 - einfach eine Wahl in Richtung der C++ - Standard-Konventionen gegen die in etwa Java oder C# beliebteren Konventionen.

Was Sie für Ihren eigenen Code tun sollten, wählen Sie einfach eine Konvention und bleiben Sie dabei - Konsistenz ist wichtiger als andere Überlegungen. Mein Arbeitgeber verwendet eine CamelCase Konvention über alle Sprachen für alle internen Quellen (obwohl nicht unbedingt, wenn es darum geht, öffentliche APIs freizugeben, was ein separates Problem ist), ich persönlich verabscheue es (Ich wünschte, ich könnte alle Vertrauen auf Groß-und Kleinschreibung das Programmieruniversum! -), aber ich bleibe dabei, und helfe ihm tatsächlich bei (code reviews), denn Einheitlichkeit ist wichtig.

Ich denke, Sie werden verstehen, warum sich auf die Groß-/Kleinschreibung zu verlassen nur dann eine schreckliche Idee ist, wenn Sie sich auf einen Bildschirmleser verlassen müssen, um Code zu lesen und es gibt keinen wirklich guten Weg, keine starke oder einfache Konvention, um Fallunterschiede in einfache akustische Hinweise umzuwandeln (während das Übersetzen von Unterstrichen in "Klicks" in einem gut konfigurierbaren Bildschirmleser ein Kinderspiel macht). Für Menschen ohne jegliche Sehbehinderung, die ohne Zweifel 90% oder mehr ist, müssen Sie sich nicht kümmern (außer Sie wollen inklusiv sein und Menschen helfen, die nicht teilen Ihr Geschenk der perfekten Vision ... naah , wer interessiert sich für diese Jungs, richtig ?!).

Aber Konsistenz ist immer noch wichtig und hilft _every_body.

+12

Wow! Niemals habe ich Namenskonventionen als Barrierefreiheitsproblem betrachtet. +1 nur um meine Augen dafür zu öffnen. – gotgenes

+3

@gotgenes, tx - und ungefähr zur gleichen Zeit, jemand anderes anonym - ich glaube, manche Leute mögen es einfach nicht ** daran erinnert zu werden, dass nicht jeder perfektes Augenlicht hat, also, Erwähnung dieses kleine Detail wird auch herabstimmen (unter dem Deckmantel und dem Schutz der Anonymität, natürlich, durch anonyme Feiglinge, die froh sind, so zu sein ;-). Aber, sogar eine gute Person wie Sie zu machen (jemand, der sich dieses Problems bewusst ist und sich dessen nicht bewusst ist), der sich jetzt bewusst ist und wahrscheinlich in Zukunft darüber nachdenken wird, ist es wert, was auch immer meine Downvotes kommen! –

+1

Ich zweite, dass ich nie zuvor über das Problem der Barrierefreiheit gedacht hatte. Danke, dass Sie mich (uns) aufgeklärt haben. – dav

2

Verwenden Sie die Namenskonvention, die Ihr Geschäft verwendet.

Wenn sie zustimmen, dass die bestehende Konvention dorky ist (oder sie haben keinen Standard), und nichts dagegen haben, ein wenig Arbeit auf eine neue und verbesserte (mehr Standard) Konvention, dann aufräumen Das kannst du machen.

15

Ich habe gehört, es in anderen Kontexten angegeben, dass words_with_underscores für nicht-englische Leser besser als wordByCamelCase zu trennen sind. Visuell erfordert es weniger Aufwand, die einzelnen Fremdwörter zu parsen.

+0

Einfachere visuelle Trennung * ist * der explizit für die Programmiersprache Eiffel genannte Grund. Sie haben auch diesen Unterstrich_Separator_Standard. Es hilft wahrscheinlich auch für englische Muttersprachler :-) –

+0

Es ist auf jeden Fall einfacher zu lesen. Beweis des Konzeptes: TheQuickBrownFoxJumpsOverTheLazyDog vs the_quick_brown_fox_jumps_over_the_lazy_dog. Der letzte kann mit normaler hoher Geschwindigkeit gelesen werden, während das Gehirn in den super langsamen Konzentrationsmodus wechselt, wenn es versucht, die erste Alternative zu entschlüsseln. – hlovdal

+3

Hmm - ich glaube ich habe den ersten schneller analysiert als der letztere. Ich bin jedoch ein englischer Muttersprachler. –

5

Der Kleinbuchstabe mit Unterstreichung geht bis auf Unix Apis zurück. Ihr gesamter Systemaufruf steht in dieser Konvention.

+3

Es geht weiter zurück - Lisp erlaubt Bindestriche in Bezeichnern, und mehrere Wortfunktionsnamen in Lisps sind mit Bindestrichen getrennt, genauso wie moderne Sprachen Unterstriche verwenden. Ich würde sagen, dass dies zumindest das gleiche Konzept ist (mit einem Ersatzzeichen, da Leerzeichen nicht erlaubt sind). –

2

Was auch immer Sie tun, ich denke, es ist wichtig, dass Sie konsequent sind. Ich habe ein paar Style-Guides gesehen (zum Beispiel Google Python Style Guide), die dir sagen, dass du Unterstriche verwenden sollst.

Ich persönlich denke, dass die Verwendung von Kleinbuchstaben mit Unterstrichen den Code leichter lesbar macht.

Sie verwenden camelCasing? Es macht mir nichts aus! Es gibt immer Glasses Mode. :)

0

Fühlen Sie sich frei zu tun, was Ihnen am besten passt, aber ziehen Sie in Betracht, eine der populären Konventionen zu verwenden. Es erleichtert anderen Entwicklern, sich mit Ihrem Code vertraut zu machen.

Denken Sie daran, dass im Laufe des Projekts mehr Zeit für das Lesen des Codes aufgewendet wird als für das Schreiben.

6

Ein Grund könnte in der Vergangenheit sein, viele Computer hatten keine gemischten Fallfähigkeiten. In den Tagen von COBOL, Programme waren alle Großbuchstaben. In den frühen 80er Jahren kamen viele "Personal Computer" nur mit Großbuchstaben. Zum Beispiel könnten Sie eine Kleinbuchstaben-Extender-Karte für den Apple II + erhalten. Als die Programme begannen, einen gemischten Fall zuzulassen, war der Kamelfall nicht populär. Viele Programme nahmen, was früher in Großbuchstaben geschrieben war, und wurden nur in Kleinbuchstaben konvertiert. Bis in die 80er Jahre haben verschiedene Sprachen dem Fall Bedeutung gegeben, und in den 90er Jahren popularisierte Java die camelCase-Syntax. Sprachen, die eine ältere Geschichte haben oder enger mit der Unix-Systemprogrammierung verbunden sind, vermeiden es, eine semantische Verwendung von Groß- und Kleinbuchstaben zu machen.

1

War es Meyers, die mit aLongAndTotallyUnreadableMethodeName vs einem_even_longer_but_perfectly_readable_method_name Vergleich kam?

Wenn Sie bereits an eines gewöhnt sind, wird Ihre Lieblingskonvention natürlicher aussehen. Aber neue Programmierer bevorzugen Unterstreichungen (Stichprobengröße N = ich, im Jahr 2001).

Ich denke, einige Sprachen verwenden CamelCase, weil ihre API wirklich schrecklich sein kann. Sie benötigen zusätzlichen Speicherplatz, damit der Code ohne Umbruch in die IDE passen kann.

Zum Beispiel:

poly = geometryLibrary.polygonGenerator.createFromPointSet(myList.listContentsToPointset()) 
+0

Nicht sicher, ob der Beispielcode ein Argument gegen den Schlangenfall ist, da er nicht gut mit dem Demeter-Gesetz übereinstimmt. – Juliet

+1

Ein gültiges Beispiel! –

11

LowerCaseWithUnderScoresAreSuperiorBecauseTheTextYouNormallyReadInABookOrNewsPaperForExampleIsNotWrittenLikeThis. .

+11

but_its_not_written_like_this_either_so_I_dont_see_your_point –

+40

@Scott: Dein Kommentar war aber * viel * einfacher zu lesen. –

+0

@Steve, dein Kommentar war der einfachste, der von allen gelesen wurde – Dennis

2

Es ist nur eine Konvention, aber eine nützliche, wenn Sie mit vielen Abkürzungen arbeiten.

Wie hast du EmailConfig geschrieben (oder war es EMailConfig)? HTTP-Anforderung? email_config und http_request sind dann viel klarere Konvention.

Verwandte Themen