Löschen von Items bei for .. in Durchlauf

Wenn du dir nicht sicher bist, in welchem der anderen Foren du die Frage stellen sollst, dann bist du hier im Forum für allgemeine Fragen sicher richtig.
lunar

maxwell hat geschrieben:Ja "ol" & "nw" stehen für "old" & "new". Was das betrifft, kenne ich eigentlich nur solch "short names". ich mags einfach nicht wenn man - wie ich in unzähligen beispielen der OOP gesehen habe - selbst klassenbezeichnungen mit "dies_ist_meine_klasse_a" oder noch besser "DiesIstMeineKlasseA" bezeichnet. [...] Als Programmierer sollte man schon wissen was da gemacht wird. Auch wenn es auf den ersten Blick nicht ersichtlich ist. Denn das ist ja nun mal kein riesen Quelltext und wir lesen ja keine Märchengeschichte. :P
Wie heißt es so schön: Jeder kann Quelltext für Computer schreiben, gute Programmierer aber schreiben Quelltext für Menschen.
Benutzeravatar
HerrHagen
User
Beiträge: 430
Registriert: Freitag 6. Juni 2008, 19:07

außerdem bin ich von natur aus "tippfaul".
Da bist du bei Python ja genau richtig. Der Code ist in Python im Schnitt etwa um den Faktor 6-10 kürzer als in C. Die gewonnene Zeit nutzt man halt unter anderem gern dazu ordentliche Namen zu vergeben. :wink:

Führ mal folgenden Code aus:

Code: Alles auswählen

import this
Wenn du wirklich die Sprache lernen willst, musst du dich auf die neue Sprache einlassen und nicht versuchen C in Python zu schreiben.
maxwell
User
Beiträge: 69
Registriert: Samstag 11. Juli 2009, 15:36
Wohnort: am Fernsehturm in B.

@lunar
Jeder kann Quelltext für Computer schreiben, gute Programmierer aber schreiben Quelltext für Menschen.
wer das gesagt hat, hat einen sehr schlechten tag gehabt! :lol:

Code: Alles auswählen

	unsigned long i, *s, *m, x;
	int sig = 0;
	
	s = pending->signal.sig;
	m = mask->sig;
	switch (_NSIG_WORDS) {
	default:
		for (i = 0; i < _NSIG_WORDS; ++i, ++s, ++m)
			if ((x = *s &~ *m) != 0) {
				sig = ffz(~x) + i*_NSIG_BPW + 1;
				break;
			}
		break;

	case 2: if ((x = s[0] &~ m[0]) != 0)
			sig = 1;
		else if ((x = s[1] &~ m[1]) != 0)
			sig = _NSIG_BPW + 1;
		else
			break;
		sig += ffz(~x);
		break;

	case 1: if ((x = *s &~ *m) != 0)
			sig = ffz(~x) + 1;
		break;
	}
näääna! :P

@HerrHagen

werde ich machen...[/code]
be or not to be
EyDu
User
Beiträge: 4881
Registriert: Donnerstag 20. Juli 2006, 23:06
Wohnort: Berlin

maxwell hat geschrieben:
Jeder kann Quelltext für Computer schreiben, gute Programmierer aber schreiben Quelltext für Menschen.
wer das gesagt hat, hat einen sehr schlechten tag gehabt! :lol:
Und Ahnung hat Martin Fowler auch keine :lol:
Das Leben ist wie ein Tennisball.
BlackJack

@maxwell: Das Du so ganz ohne OO ausgekommen bist, glaube ich nicht. Vielleicht war es Dir nicht bewusst, aber bei vielen guten Softwarearchitekturen findet man die Grundzüge wieder, auch bei Programmiersprachen, die keine spezielle Unterstützung für das Konzept bieten.

Natürlich soll man keine unnötig langen Namen verwenden, aber welche die verständlich sind. Bei `ol` und `nw` hast Du je *einen* Buchstaben gespart, und die Kosten sind, dass zumindest ich nicht auf den ersten Blick die Bedeutung verstanden habe. `DiesIstMeineKlasseA` ist ein schlechter Name, weil der nichts darüber aussagt, was die Klasse denn nun eigentlich repräsentiert.

Grundsätzlich finde ich Abkürzungen in Namen schlecht, solange sie nicht sehr eindeutig, d.h. allgemein bekannt sind. Es verlangsamt den Lesefluss, weil man entweder raten oder suchen muss, ob die Abkürzung vielleicht in irgendeinem Kommentar erklärt wird. Und in gewisser Weise sind Quelltexte "Märchen". Die sollen von Menschen gelesen und verstanden werden, also was ist so schlimm daran, wenn man sie halbwegs flüssig lesen kann? Das ist jetzt kein Plädoyer für superlange und ausschweifende Namen, denn das behindert den Lesefluss dann ja auch wieder. Abr Knsnntn innrhlb vn Wrtrn wglssn, nur um möglichst kurze Namen zu haben, ist Mist. Ich kenne selber noch die Zeiten von BASICs auf Heimrechnern, die nur zwei Buchstaben in Bezeichnern berücksichtigt haben und die Einschränkungen der ersten C-Compiler auf 16 Zeichen. Ich habe heute sogar noch regelmässig mit einer Programmiersprache von IBM aus den 90ern zu tun, die nur die ersten 8 Zeichen von Bezeichnern berücksichtigt. Diese willkürlichen, technischen Beschränkungen gibt es aber heute $GOTT sei Dank bei den modernen Sprachen nicht mehr, und man ist nicht mehr zu kryptischen Kürzeln gezwungen.

Was das tippfaul angeht: Ich verwende einen einfachen Editor, der mit Autovervollständigung aus allen Worten der offenen Texte anbietet. Also noch nicht einmal spezifisch für Python. Da brauche ich jeden "langen" Namen nur einmal in ganzer Schönheit tippen.

Vielleicht sollte man als Programmierer mit den Bitoperationen umgehen können -- Anwendungsentwickler stolpern da bei modernen Sprachen allerdings eher selten drüber -- aber auf der anderen Seite sollte man solche "Spezialitäten" IMHO auch ordentlich "verstecken" und möglichst weit nach "unten" verdrängen. Wenn ich wissen will, ob ein Signaltyp in einer bestimmten Menge an Signaltypen enthalten ist, dann ist ein ``if signal.type in allowed_signals:`` einfach eleganter als ``if ``if allowed_signals >> signal.type & 1:``. Und auch flexibler, denn das ``in`` kann sowohl mit Bitoperationen, als auch mit Mengen umgesetzt werden. Solche Abstraktionen sind nicht neu -- Pascal hat dafür z.B. einen Bitset-Typ, der im Hintergrund genau diese Bitoperationen macht, aber verständlicheren Quelltext ermöglicht.
maxwell
User
Beiträge: 69
Registriert: Samstag 11. Juli 2009, 15:36
Wohnort: am Fernsehturm in B.

@EyDu:
Und Ahnung hat Martin Fowler auch keine
Das habe ich nicht gemeint/gesagt! :wink:

@all:

ok, ok ich werde micht in zukunft bessern.
8) sollten meine quelltexte hier dem lesenden nicht schlüssig erscheinen -> nackenschelle an mich!

vg. chr. & schönes we

:wink:
be or not to be
Antworten