Wie lang sollten Variablen/Funktions/Klassen-namen maximal sein?

[Variablenbenner]

Hi,

wie lang sollten Variablen/Funktions/Klassen-namen in der Regel maximal sein,
oder was hat sich bewährt. Momentan neige ich zum Beispiel dazu,
dass ich Sachen wie

Container.GetFirstElementIterator()

schreibe. Man weiß zwar immer sofort was die Funtkion macht, aber die
Namen sind einfach manchmal extrem lang.

[camper]

Wenn es bestehende Konventionen gibt, solltest du dich daran orientieren. Die betreffende Funktion könnte zum Beispiel auch begin heißen, wenn es sich um einen STL-artigen Container handelt.

[maximal..]

40cm

[Swordfish]

So kurz wie möglich aber so lang wie nötig...

cheers, Swordfish

[ascda]

maximal.. schrieb:

40cm

lol

[Variablenbenner]

Würde euch denn der Name
Container.GetFirstElementIterator()
aufregen, oder wäre der noch ok?

[relateur]

Kommt auf die Sprache an.

Tendenziell ok.

[ja]

Methodennamen klein, also getE...

[Badestrand]

Mir wäre er zu lang, einfach weil sich deshalb Funktionsaufrufe unheimlich in die Länge ziehen können,z.B. obj.doThisOrThaT( cont.getFirstElementIterator(), cont.getLastElementIterator(), true, 17 );

[Gast]

Hallo

Ich finde lange Namen besser als welche, die nichts aussagen. Wenn man mit einer vernünftigen IDE arbeitet gibt es ja eh IntelliSense und da muss man nicht alles selber tippen.

chrische

[Badestrand]

chrische5 schrieb:

Ich finde lange Namen besser als welche, die nichts aussagen.

Das natürlich, aber "GetFirstElementIterator" erinnert doch stark an das von camper erwähnte "begin" aus der STL.

chrische5 schrieb:

Wenn man mit einer vernünftigen IDE arbeitet gibt es ja eh IntelliSense und da muss man nicht alles selber tippen.

Ich wollte auf's Lesen hinaus Solch lange Zeilen kann ich eben nur schwer überfliegen, also "fliegenden Auges" den Sinn erkennen.

[Gast]

Hallo

Ich habe weniger auf konkrete Beispiel abgezielt, als vielmehr allgemein geantwortet. Fliegend etwas zu lesen, ist sicher hilfreich, aber nur, wenn der Name auch die Funktion erläutert. Also lieber lang und sinnvoll, als kurz und besser lesbar.

chrische

[Dravere]

Also von der Länge her, würde ich knapp "GetFirstElementIterator" noch durchgehen lassen, aber das ist so ziemlich das oberste Maximum. Zudem finde ich den Namen etwas zu übergenau. Ein Iterator geht normalerweise immer über die Elemente. Daher ist ElementIterator eigentlich zweimal das Gleiche. Was den Funktionsnamen schon mal auf "GetFirstIterator" reduzieren würde. Auch den Namen würde ich noch zu lange finden und eher sowas wie "start" oder "begin" nehmen. Vor allem wenn man an die STL, bzw. StdLib, denkt, dann wäre "begin" schon das Vernünftigste.

Aktuelle plage ich mich auch mit so einem Funktionsnamen rum, "set_move_in_date(...)". Eindeutig eigentlich auch zu lang, aber da die Funktion nicht oft verwendet wird, werde ich es wohl dabei bleiben lassen.
Ich denke das ist auch noch wichtig, wie oft eine Funktion schlussendlich wohl verwendet wird. Zentrale Funktionen sollten kurz und eindeutig sein, nicht so zentrale Funktionen können ruhig auch mal etwas länger sein.

Grüssli

[Heinzelotto]

schreibt einfach in maschinencode, da habt ihr das problem nicht

[pumuckl]

Dravere schrieb:

Zentrale Funktionen sollten kurz und eindeutig sein, nicht so zentrale Funktionen können ruhig auch mal etwas länger sein.

Wenn "zentral" bei dir gleichbedeutend ist mit "häufig benutzt und allseits bekannt" dann stimme ich dem zu. Auf jeden Fall sollte gelten: je kürzer der Name, desto ausführlicher die Dokumentation. Bei einem "GetFirstElementIterator" weiß man sofort vom Namen her Bescheid, ein "begin" kann vieles bedeuten. Selbst wenn man das begin von STL-Containern kennt kann man nicht davon ausgehen dass das begin bei einer anderen Klasse die selbe Semantik hat.

ein gutes Beispiel für aussagekräftige lange Klassennamen findet man in der Humor-Rubrik: http://www.c-plusplus.net/win98_sources.htm
Es ist sofort klar was gewollt ist, keine zusätzliche Doku nötig

[~fricky]

Badestrand schrieb:

chrische5 schrieb:

Ich finde lange Namen besser als welche, die nichts aussagen.

Das natürlich, aber "GetFirstElementIterator" erinnert doch stark an das von camper erwähnte "begin" aus der STL.

das zeigt doch gerade, dass längliche namen vorteilhafter sind. nur wer stl kennt, könnte vermuten, dass 'GetFirstElementIterator' und 'begin' was ähnliches machen. aber wer die STL nicht kennt, käme nie im leben darauf, in welchem zusammenhang das schlichte wörtchen 'begin' dort verwendet wird.

[EXDW]

NamePropertyChangeEventHandler
DependencyPropertyConverter

mit der .Net geht schon einiges #gg

public static readonly DependencyProperty TitleProperty = DependencyProperty.Register("Title", typeof(string), typeof(ClassName), new UIPropertyMetadata(ClassName.TitleValueChanged));
private static void TitleValueChanged(DependencyObject d, DependencyPropertyChangedEventArgs e)

[zwutz]

naja... begin() bei einer Iteratorklasse ist relativ eindeutig.

genauso wie ein clear() bei einer Liste nicht removeAllElementsFromListAndSetSizeToNull() heissen muss

wie jemand hier bereits gesagt hat: so kurz wie moeglich, aber so lang wie noetig.
Auf biegen und brechen kurze Methodennamen ist genauso kontraproduktiv wie eine halbe Doku als Methodenname

[DEvent]

Badestrand schrieb:

Mir wäre er zu lang, einfach weil sich deshalb Funktionsaufrufe unheimlich in die Länge ziehen können,z.B. obj.doThisOrThaT( cont.getFirstElementIterator(), cont.getLastElementIterator(), true, 17 );

first = cont.getFirstElementIterator();
last = cont.getLastElementIterator();
obj.doThisOrThaT( first, last, true, 17 );

Edit:
Wenn wir schon ueber guten Stil reden:
http://blog.choonkeat.com/weblog/2007/08/true-false-para.html

True False parameters

Every so often, I get the chance to use functions that accepts a nondescript boolean as parameter... or *gasp* a sequence of nondescript booleans.

api.connect( true )

It's a chore for the maintainer (usually my future self) to have to look up what "true" meant. IDEs might be helpful at this point, bringing up code hints and what not.. unless of cos the function declaration itself isn't exactly perfect...

def connect(bool)
...
end

I've finally come round to do myself a favor (ok, I AM going to be the maintainer) by using self-explanatory truthy / falsey values instead

api.connect( :auto_retry ) # true
api.connect( !:auto_retry ) # false

Reads better. No?

Die STL oder allgemein C/C++ Libs-Funktionen sind ganz besonders schlimm. Z.B. strncpy oder vsprintf, gibt aber noch schlimmere Namen. Diese Namen kommen halt aus einer Zeit ohne Autovervollstaendigung, aus einer Zeit in der Programmierer noch mit einfachen Texteditoren programmiert haben.

Der Name einer Funktion/Methode sollte so lang sein das man ohne die Dokumentation sehen kann was sie macht. Z. B.

strcpy > copyString(dest, source)
strncpy > copyString(dest, source, num)
vsprintf > formatPrint(string, format, arg)
vprintf > formatPrint(format, arg)

So wuerde es aussehen, wenn man in C Funktionen ueberladen koennte, was ja leider nicht geht. Man sollte immer beachten dass man Programme fuer Menschen schreibt und nicht fuer den Computer/Compiler. Es ist die Aufgabe des Compilers das Programm dann fuer den Computer zu uebersetzen.

[~fricky]

DEvent schrieb:

Die STL oder allgemein C/C++ Libs-Funktionen sind ganz besonders schlimm. Z.B. strncpy oder vsprintf, gibt aber noch schlimmere Namen.

mein favorit ist immer noch 'strpbrk()'