Sinn und Unsinn der ungarischen Notation

tfa

Jester schrieb:

klar, oder wenn man sich mit dem schwarz-grün monitor über die serielle schnittstelle an den mainframe hängt...

...oder man in einem Stapel Hollerith-Lochkarten nach einem Programmfehler sucht

DEvent schrieb:

personenNamen.put(:ehefrau, "Julia"); // personenNamen hat das Interface "put(key, value)", daran weis ich das es eine Map ist.
...
personenNamen.push("Julia"); // personenNamen hat das Interface "push(value)", daran merk ich das es eine Liste ist

also probierst du erst alles durch oder wie?

Artchi

DEvent meint wohl eher den Worst-Case: keine Doku, Codecompletion u.ä. vorhanden.
Aber ich will ja nichts sagen: in C++ hab ich immer eine Doku: die header-Datei! Da kann ich im schlechtesten Fall reinschauen und muß nichts raten. Noch ein Grund weniger für die UN.

Im Regelfall (sorry für die Notepad-Fanatiker) habe ich eine Codecompletion, die mir alle Methoden auflistet, wenn ich . oder -> eintippe. In der MSDN kann ich sogar on-the-fly-Doku einblenden lassen. Oder ich schaue (wenn das die IDE nicht kann) in die richtige Doku rein, die z.B. im Doxygen-Format vorliegt. Ist keine Docu vorhanden, benutze ich die Library auch nicht wirklich ist für mich gestorben! Oder ich jage halt Doxygen selber drüber und schau mir das im Browser an.

Ich bezweifel mal, das man in einer normalen Umgebung raten muß, wie ein Interface aussieht.

pointercrash**

Ich wollte Euch diese Schönheit nicht vorenthalten, leider ist sie nicht mehr ganz authentisch, man darf sich Kommentare wie

// aber Hallo!
// ++ ist Hochzählen
// bist Du der Zeiger?
// Du bists!

an beliebigen, möglichst unpassenden Stellen einstreuen, nicht vergessen, die Einrückungen wieder vogelwild zu stellen und man kommt dem vollen Erlebnis nahe. Das Projekt habe ich von einem Ex- Telekomiker geerbt, der in einem anderen Laden "so" zu programmieren begonnen hat. Ich habe jetzt nur ein Highlight herausgenommen, aber als der Typ gegangen ist, hat er etliche zehntausend Zeilen so hinterlassen. Es hat lange gedauert, anstelle dessen les- und wartbaren Code zu erhalten. Es macht also Sinn, Konventionen aufzustellen und einzuhalten. Ob in diesem Fall UN etwas gerettet hätte, wer weiß? OK, hier das Prachtstück:

struct ruck_zuck
{
	void (*ruck_zuck_zeig) (void);
	unsigned int idee;
	struct ruck_zuck  *vor_zuck;	//  ??
};

static struct ruck_zuck  *ruck_zuck_start = NULL;	//  ??
static struct ruck_zuck  *ruck_zuck_raus = NULL;	//  ??
static char ruck_zucks = 0;
static unsigned int ruck_zuck_idee = 0;

char TicktackNeuZuck( void (*zeig) (void) )
{
struct ruck_zuck  *ruck_zuck_zuck = malloc(sizeof(struct ruck_zuck)); //  ??
	if (ruck_zuck_zuck)
		{
			ruck_zuck_zuck->ruck_zuck_zeig = zeig;	
			ruck_zuck_zuck->idee = ++ruck_zuck_idee;
			ruck_zuck_zuck->vor_zuck = NULL;

			TICKTACKAUS
			if (ruck_zucks) ruck_zuck_raus->vor_zuck = ruck_zuck_zuck;
			else ruck_zuck_start = ruck_zuck_zuck;
			ruck_zuck_raus = ruck_zuck_zuck;
			ruck_zucks++;
			TICKTACKEIN
			return ruck_zucks;
		}
	else return 0;
}

#pragma INTERRUPT Ticktack	
void Ticktack(void)
{
struct ruck_zuck  *ruck_zuck_zahl;
	if (ruck_zucks)
	{
		ruck_zuck_zahl = ruck_zuck_start;
		while (ruck_zuck_zahl)		
		{
			(*ruck_zuck_zahl->ruck_zuck_zeig)();
			ruck_zuck_zahl = ruck_zuck_zahl->vor_zuck;
		}
	}
}

void zack(void)
{
	// ... sth
}

void main(void)
{
	// ...
	TicktackNeuZuck(zack);
	// ...
}

DEvent

@pointercrash() geil

Ich bin Java und Eclipse verwoehnt. Kompelieren On the Fly und Codeverfollstaendigung 4tw.

volkard

DEvent schrieb:

Mal eine Frage an die pro-UN: Wieso es wichtig ob eine Variable ein Pointer ist oder nicht?

bin nicht pro UN. aber ich kenne den grund.

siehe

int* derKleinere(int* a,int* b){
 if(a<b)
  return a;
 else
  return b;
}

und

int* derKleinere(int* pa,int* pb){
 if(pa<pb)//ah, hier ist *pa,*pb gefragt
  return pa;
 else
  return pb;
}

also der anfänger vermeidet dabei diesen fehler. und der kommt schon recht häufig vor bei den ersten zeiger-experimenten.

Ausserdem wieso in C++ nakte Zeiger anfassen? Das ist doch fast nie noetig, ein Interface sollte sowieso nie, nie, nie mit nakten Zeigern hantieren. In boost gibts es fuer jede denkbare Situation ein Zeiger-Wrapper und es gibt bei sowas 0 perfomance-Verlust.

natürlich benutzte ich zeiger. aber das ist eine andere geschichte.

DEvent

int* derKleinere(int* pa,int* pb){
 if(pa<pb)//ah, hier ist *pa,*pb gefragt
  return pa;
 else
  return pb;
}

Kommt da keine Warnung?

asc

volkard schrieb:

DEvent schrieb:

Mal eine Frage an die pro-UN: Wieso es wichtig ob eine Variable ein Pointer ist oder nicht?

bin nicht pro UN. aber ich kenne den grund.

siehe...

Wobei man hier nicht argumentieren kann das die UN an dieser Stelle unbedingt Sinn macht, da der Variablenname an sich schon nichts Aussagend gewählt wurde.

cu André

volkard

asc schrieb:

Wobei man hier nicht argumentieren kann das die UN an dieser Stelle unbedingt Sinn macht, da der Variablenname an sich schon nichts Aussagend gewählt wurde.

ändere es und nimm bessere namen. vielleicht so?

int* derKleinere(int* pDerEineWert,int* pDerAndereWert){ 
 if(pDerEineWert<pb)//ah, hier ist *pDerEineWert,*pDerAndereWert gefragt 
  return pDerEineWert; 
 else 
  return pDerAndereWert; 
}

wie aussagekräftig können variablennamen sein an kleinen funktionen wie swap?

ich erwarte von dir jetzt so gute namen, dass man die UN nicht braucht. wird es nur daraufhinauslaufen, daß du zeigerAufA statt pa nimmst?

asc

volkard schrieb:

...
wie aussagekräftig können variablennamen sein an kleinen funktionen wie swap?

ich erwarte von dir jetzt so gute namen, dass man die UN nicht braucht. wird es nur daraufhinauslaufen, daß du zeigerAufA statt pa nimmst?

Im Zweifel das, wobei man natürlich auch argumentieren kann das eine so kurze Funktionen auch garkeine Kennzeichnung für Zeiger brauchen. Wenn es wichtig ist das es sich um einen Zeiger handelt, dann schreibe ich dies auch im Namen rein.

Wobei ich gestehe das obwohl ich die UN ablehne 2 Dinge doch noch nach UN mache (I für Interface/Schnittstelle und bei so kleinen Funktionen tatsächlich noch manchmal p, aber klare Bezeichner ziehe ich dennoch vor - auch wenn es mehr Tiparbeit bedeuten kann).

Spätestens wenn es um Templates geht hat man aber hier sowohl mit einer sprechenden Benennung als auch mit der UN keine Chance mehr.

cu André

pointercrash**

asc schrieb:

Spätestens wenn es um Templates geht hat man aber hier sowohl mit einer sprechenden Benennung als auch mit der UN keine Chance mehr.

Jein, eigentlich schon vorher, dazu hatte ich ja das Beispiel aus der Praxis angeführt - der Code hat übrigens wirklich funktioniert. Den absoluten Urzustand habe ich nicht mehr gefunden, da hatte ich schon eingerückt, Makros auf Großbuchstaben umgestellt usw. und mich dann hingesetzt, um mit Unterstützung des Debuggers herauszufinden, was die Codeteile überhaupt tun, um dann nach den Konventionsblättchen aussagekräftige Namen zu vergeben.

Will sagen, hätte der Typ sein Zeug der UN folgend aufgezogen, wäre mir "pRuckzuckzuck" genauso kryptisch wie "ruck_zuck_zuck" geblieben. Gegen gewaltsam verunstalteten Code hilft UN also gar nix :p

Nehmen wir den Fall an, daß wir einen Coder haben, der alles richtig machen will, der wird aber häufiger Gewissensentscheidungen treffen müssen, welches Präfix jeweils das aussagekräftigere ist, das liegt im Tendenzbereich. Sicher wird der das Projekt Übernehmende tendenziell auf andere Dinge Wert legen als sein Vorgänger . Ob er die Präfixe des Vorgängers als Hilfe betrachten wird?

Was mich ad hoc gestört hat, daß man einerseits bei der UN auf Wertebereiche abzielt und dann aber andererseits Maschinenwortbreite festlegt. Schonmal eine zweite Inkonsistenzschwäche - es sind mehr zu finden. Kommt davon, wenn man für C, C++, Pascal usw. gemeinsam eine Konvention festlegen will.

Das größte Problem ist jedoch, schon von anderen erwähnt, daß bei kleinen Änderungen auch die Präfixe nachgepflegt werden wüssen und wer ist noch nie über eigene kleine Schlampereien dieser Art gestolpert? Damit kann die "Hilfe" sogar zusätzlich die Lesbarkeit verschlechtern.

UN soll eine Lesehilfe sein, mag sein, wenn jemand mit einem Editor und dem nackten Compiler bewaffnet unter DOS loszieht, aber wenn sogar IDEs für embedded- Prozessoren einem den ganzen Kontext als Tooltip beim Mouse- Flyover reindrücken, wird die UN nur Fleißarbeit für Tippselige.
Prädikat UNsinn