Wie „selbsterklärend“ kann Code, ohne aufdringlich zu sein? [geschlossen]

Question

Ich bin nicht sicher, was die besten Praktiken hier sind, aber ich sehe oft Variablennamen besonders abgekürzt, wenn der Bereich klein ist. So (einfache Ruby-Beispiele zu verwenden) statt def add_location(name, coordinates), ich sehe Dinge wie def add_loc(name, coord)-und ich könnte sogar so etwas wie def add_loc(n, x, y) sehen. Ich stelle mir vor, dass längere Namen könnte eine Person ermüden, wenn sie sehen, Abkürzungen gewohnt sind.

Gibt es Hilfe Lesbarkeit Ausführlichkeit, oder ist es nur alle Augen weh? -Haben Menschen es vorziehen, Abkürzungen und verkürzte Namen über längere Namen?

Answer 1

Persönlich würde ich viel lieber längere Namen sehen, die tatsächlich etwas bedeuten, ohne den Kontext zunächst zu bestimmen zu haben. Natürlich Variablen, die, wie Zähler nicht wirkliche Bedeutung verleihen, verwende ich immer noch kleine bedeutungslose Variablennamen (wie i oder x), aber ansonsten Ausführlichkeit ist Klarheit die meiste Zeit. Dies gilt vor allem mit öffentlichen APIs.

Dies kann zu weit gehen, aber. Ich habe einige VB-Code in der Vergangenheit lächerlich diese Weise gesehen. Moderation wie alles andere auch!

Answer 2

Ich benutze lange Variablennamen die ganze Zeit, nachdem alle modernen IDEs und Texteditoren Abschluss haben, so gibt es nichts falsch mit der Verwendung von index statt, wenn i. Die einzige Ausnahme, die ich habe, ist, wenn sie mit Koordinaten b / c x und y machen am meisten Sinn dort zu tun.

Answer 3

Nie Abk.

Answer 4

Es sollte eine Variable, um den kürzest möglichen Namen geben, der seinen Zweck angemessen vermittelt.

Über-Ausführlichkeit neigt Syntax zu verbergen, und die Syntax ist wichtig.

Durch ein ganzes Programm (oder Anwendung / System) Variablen sollten mit einheitlichem Stil und ähnliche Dinge benannt werden sollten ähnlich benannt werden. Wenn eine Konvention innerhalb der Sprachgemeinschaft vorhanden ist, sollte beachtet werden, (so tun camelCaseRubyVariableNames nicht), es sei denn es etwas zwingender Grund ist es nicht zu tun.

Abkürzungen, falls verwendet, sollte konsequent überall und wenn domänenspezifische, sollte irgendwo aufgezeichnet angewendet werden. Wenn jemand eine nützliche Menge an Zeit mit dem Code verbringen wird dann werden sie bald erfahren.

Wenn Sie so viele wie fünf oder sechs Worte zu kombinieren, um eine Variable zu nennen, dann würde ich vorschlagen, dass Sie bei einem suchen können Code Geruch und die Routine, die Sie gerade arbeiten kann von einer wenig Arbeit profitieren.

Vor allem aber, wenn Sie der Gefahren bewusst sind und eigentlich denken über das, was Sie schreiben, sind die Chancen, dass Ihr Code angemessen sein wird. Stellen Sie sich die Beschreibung der Funktion, die Sie gerade arbeiten, um einen neuen Kollegen -. Je weniger Sie denken, Sie würde sagen müssen, desto besser ist der Code wahrscheinlich ist

Answer 5

Versuchen Sie Ihr eigenes Code 1 Jahr später zu lesen. Sie werden sowohl den Wert der Selbst Dokumentieren Variablennamen und den Wert der Code-Kommentare (und speziell den Wert sauberen Code) finden Sie unter

Wenn Sie jemand anderes Quellcode packen und Sie nicht verstehen, es ist es einfach, zu denken: „Na ja, er ist nicht so gut programer wie ich bin“ Aber wenn man bedenkt, dass Sie Ihre eigenen Code schwer ist, dass Sie wie gehen zu lesen: " was thinkng ich? "

Auf lange Sicht Ausführlichkeit hilft Wartbarkeit. Für kurze eine Zeile Skript, können Sie immer noch „setLocNm“ anstelle von setLocationName "

Jeder Narr kann Code schreiben, der ein Computer verstehen kann. Gute Programmierer schreiben Code, den Menschen verstehen. -Martin Fowler

Answer 6

Ich persönlich finde Ausführlichkeit eine gute Sache, aber es ist einfach allzu weitschweifig zu sein, was eine schlechte Sache ist. Es besteht ein Gleichgewicht, und Abkürzungen können auch in dieses Gleichgewicht kommen.

Das sind meine allgemeinen Regeln:

• Iteratoren kann ein Buchstabe, das heißt sein. i, j, k, etc.
• Andere ein Wort Variablen wie boolean schaltet, was Sie haben nie abgekürzt, dh. installing, done, etc.
• Mehrere Wortvariablen und Funktionsnamen sind Kandidaten für eine Abkürzung, aber nur, wenn sie rediculously lange zu erhalten beginnen (etwa 20-25 + Zeichen). Intelligente Abkürzung ist hier der Schlüssel. function => func zum Beispiel, aber nie fun, f oder functi

Answer 7

ich durchgeblättert die Antworten, aber ich sehe nicht, wenn die folgende abgedeckt ist. Hier geht es ...

Ob Sie abkürzen oder verbose, nur sicherstellen, dass Sie nicht mehr Worte verwendet haben, als nötig und die Bedeutung ist verdammt offensichtlich.

Aber auch nach dieser Filterung, wenn Ihr Identifikatoren ausführlichen aussieht, haben Sie einen Fehler in Ihrem Design.

def initialize_report_template()
end

sein sollte ...

class ReportTemplate
    def initialize()
    end
end

Answer 8

Längere Namen sind viel besser. Sie erwähnen, dass Sie oft abgekürzte Namen in kleinen Teleskopen zu sehen. Wer ist der Umfang zu sagen, wird klein bleiben, da die Software wächst?

Natürlich ist XCoordinateForCurrentLocationOfSelf ein lächerlicher Name, also nur sinnvoll sein. Vor allem, wenn Sie in ein Projekt zu Fuß sind Sie haben nicht gearbeitet, werden Sie jemand danken, die verwendet beschreibende Funktion und Variablennamen.

Answer 9

Ich denke, es ist in Ordnung abzukürzen, wenn der Name Lesbarkeit verletzen würde oder einfach nur überflüssig.

. Beispiel 1: Ein Argument auf ein Verfahren, wo der Typ allready alle Informationen vermittelt notwendig

Beispiel 2: Eine Variable, die eine Menge in nahe liegender Weise sein verwenden

StringBuilder sb = ...
sb.append(...
sb.append(...
return sb.toString();

Beispiel 3: Idiomatic Abkürzungen. i, j, k hat allready erwähnt. „Sb“ oben ist ein in unserem Code, und jedes Team hat wahrscheinlich ein paar mehr.

Answer 10

Ziel für kürzere und nicht länger, sondern dem Leser das Verständnis sollte Trumpf Faulheit geben jedes Mal .

Wie schon andere gesagt haben, Variablenname Länge sollte nicht darüber hinwegtäuschen Logik oder der Algorithmus. Zum Beispiel in der Arithmetik, wir schreiben

( 1 + 5 ) * 3 = 18

statt

three multiplied by the sum of one and five equals eighteen

, weil wir versuchen, die Aufmerksamkeit auf andere Dinge als die Klarheit der Elemente in der Expression beteiligt zu ziehen.

Ich neige dazu, Variablen 02.59 Worte zu halten, Abkürzen nur, wenn ich länger als 24 Zeichen oder so. Je weniger häufig eine Variable verwendet wird, desto wahrscheinlicher Ich bin zu fühlen uns frei, lange die Variablennamen zu machen. Häufiger Variablen verwendet werde ich kürzer machen.

Answer 11

Max Kanat-Alexander, der Chefarchitekt von Bugzilla, sagt dies in seinem Blog:

  

-Code selbst Raum im Verhältnis einnehmen sollte, wie viel Sinn es hat.

     

Im Grunde winzige Symbole, die bedeuten, dass ein   lot macht Code schwer zu lesen. Sehr lang   Namen, die nicht viel auch bedeuten, machen   Code schwer zu lesen. Die Menge an   Bedeutung und der Raum aufgenommen sollte   werden eng miteinander verwandt sind.

http://www.codesimplicity.com/post/readability-and -naming-things /

Es ist ein sehr interessanter Beitrag über die Dinge zu benennen. Ich fordere alle, es zu lesen!

Answer 12

Das einzige Mal, dass ich Abkürzungen akzeptieren ist für lokale Variablen, die nur im Rahmen für einen kleinen Zeitraum sind.

Bedeutung sollten sie in Rahmen mit einer sehr lesbaren Methode oder Konstruktor kommen.

Answer 13

Ich bin mit Kilhoffer; Ich ziehe es in fast jedem Kontext beschreibende Variablennamen zu sehen. Ich werde abkürzen, wenn meine Variablennamen sind länger als 20 Zeichen oder so, in der Regel mit Worten in den Variablennamen (zB: „SomeVeryLongVarValue“).

Natürlich, ich benutze auch ungarische Notation, wann immer ich kann, so könnte ich gut in den anderen Extrem Lagern sein zu versuchen, meine Variablennamen übermäßig beschreibend zu machen, je nach Perspektive.

Answer 14

Ich werde wahrscheinlich völlig ausgepfiffen werden, aber ich wollte diese Ansicht, um sicherzustellen, war zu hören.

Während mehr Variablennamen mehr beschreibend sein können, können sie beginnen, die ursprüngliche Absicht des Programms mire. Ich glaube, dass auf API-Elementen ist es wichtig, klare und aussagekräftige Namen im Kontext zu haben, dass sie verwendet werden.

Innerhalb jeder Funktion oder Methode ist dies oft eine andere Geschichte. Ich versuche, weniger zu schreiben und halten sie sehr kurz und bündig. Dies ist bekannt als spartanisch Programmierung al ein Mr. Atwood und diese geschicktes Beispiel. Ja, das Beispiel eindeutig in Ordnung gebracht, aber es tut zeigen, wie etwas weniger Zeremonie mit tatsächlich das Programm machen kann leichter zu lesen.

Viel Glück.

Answer 15

Bei der Programmierung Sie die Syntax verwenden, so dass die Menschen es lesen kann, ist die Länge der Variablennamen, Methoden, etc ... sind wirklich irrevelant.

Die ausführlichere desto besser in der Regel mit einer guten Entwicklungsumgebung sollten Sie Code-Vervollständigung ohnehin haben, so können Sie einfach Hit „add_l“ + TAB den Methodenaufruf zu beenden.

Answer 16

Ich denke, dass das Hauptproblem mit Abkürzungen ist, dass nicht alle Menschen auf die gleiche Weise kürzen , also, wenn Sie mit vielen Menschen arbeiten sie nur die Fehlerwahrscheinlichkeit erhöhen, wenn Codierung. Zum Beispiel, wenn Sie eine Konstante, die SOMETHING_INTERFACE genannt werden kann, vielleicht einige Entwickler würden es als SOMETHING_INTFACE abkürzen, andere als SOMETHING_IFACE oder SOMETHING_IF, SMTHING_IFACE ...

Mit nur zwei Wörter können Sie mindestens ein halbes Dutzend mehr oder weniger „logisch“ möglich Abkürzungen haben, so dass ich denke, es ist besser, in den meisten Fällen ohne Abkürzungen zu schreiben und mit mehr Gründe, wenn Sie selbst haben wollen -docummented Code.

Sehr lange Namen manchmal lästig sein können, können aber auch in sehr lokalen Bereichen mit auxiliar Variablen abgekürzt werden.

Answer 17

Die meisten Menschen Anblick zu lesen, dauert es nicht mehr ein Wort zu lesen, dann einen individuellen Brief zu lesen. Also immer aussagekräftige Namen verwenden. Müssen sie komplett 7 Wort Beschreibungen sein, nein, aber sie müssen nicht mehr genug, um zu verstehen.

Ich konnte add_loc (Name, coord) akzeptieren, da sie lang genug sind, kann ich sagen, was sie sind. In add_loc (n, x, y), würde ich Objekt zu 'n' anstelle von Namen. Ich konnte mit X leben und Y, da diese die akzeptierten Namen von Koordinaten sind.

Für jemand nicht vertraut mit Koordinatensystemen kann ich sehen, wo add_location (Name, Koordinaten) wäre sinnvoller.

Im Zweifelsfall verwenden längere Namen.

Answer 18

"Es ist OK Mord Geheimnisse, um herauszufinden, aber Sie sollten Code nicht herausfinden, müssen Sie in der Lage sein sollten, es zu lesen.." - Steve C. McConnell

Das heißt, wenn Sie denken, dass Sie noch sonst jemand allzu explizite Variablennamen muss und so weiter, fühlen sich frei, sie zu verkürzen.

Answer 19

Ich schlage vor, einen minimalistischen Ansatz. Verwenden Sie ein wenig wie möglich bei gleichzeitiger Gewährleistung des Code bleibt klar, prägnant und auf den Punkt.

Answer 20

Out of scope Dinge wie Konstanten und Globals sollten lange beschreibende Namen haben. Manchmal ist ein wirklich langer Name wird es „riechen“ macht gerade genug, um zu signalisieren, es ist Gegenwart als unerwünscht zu sein. Dies ist eine gute Sache, becuase es wird 1 - Leute es vermeiden machen, 2 -. Die pressue erhöhen den Code Refactoring, um es verschwinden lassen