reset() von zwei foreach Schleifen

[Christian Kruse]

Hallo dedlfix,

• macht den Code schlechter lesbar und erhöht die Komplexität

Letzteres ja, über ersteres kann man streiten.

Das denke ich nicht. Es gibt schon einen common sense in der Entwickler-Gemeinde.

Es gibt so viele Dinge in Code, die quotiert werden müssen, [...]

Eben, und jedes weitere notwendige quoten mach den Code schlechter lesbar. Bei einer Tabelle mit fünf Feldern mag das noch irrelevant sein, aber wenn wir jetzt 15 oder 20 Felder haben, ist die Feld-Liste deutlich schlechter lesbar.

Daran muss man sich als Programmierer gewöhnen.

Das halte ich für die falsche Einstellung und für ein schlechtes Argument. Damit werden die Dinge nie besser.

• macht das SQL weniger portabel (weil ist nicht Standard-gerecht escaped)

YAGNI! Gern gebracht dieses Argument, aber wie oft kommt das denn im Leben vor, dass man das DBMS wechselt [...]

Öfter als man denkt. Ich habe allein schon selbst geschriebene Software bereits drei mal portiert, von MySQL auf PostgreSQL. Von Patches für FLOSS will ich gar nicht erst reden.

und dann noch dazu nur standardkonforme Dinge und keine auch anderswo reservierten Wörter verwendet hat?

Natürlich wird man immer Dinge anpassen müssen, aber der Aufwand steigt ins unermessliche wenn jede beschissene Feld-Liste angepasst werden muss.

Das Argument suggeriert, dass man quasi einfach den Verbindungsaufbau ändert und fertig ist mit der Migration [...]

Wenn du das denkst, dann hast du mich nicht verstanden :)

Wenn man dieses Argument als Pro für Standardgerechtes Quotieren (Escapen ist das Maskieren innerhalb von String-Literalen) interpretiert, widerspricht das aber deinen beiden anderen Argumenten.

Wenn man quoten muss, dann lieber standard-konform. Wenn man nicht quoten muss, dann bitte nicht tun. Das war die Botschaft.

• ist in den meisten Fällen überflüssig; in den Fällen, in denen es nicht überflüssig ist, sollte man lieber den Bezeichner ändern, denn das gibt erfahrungsgemäß sonst nur Probleme

Da fallen mir grad keine ein, wenn man konsequent die Bezeichner quotiert.

Du bist meistens nicht der einzige, der mit der Datenbank arbeitet. Du ersparst deinen Kollegen oder Nachfolgern eine Menge Kopfschmerzen, wenn du reservierte Wörter, Leerzeichen und ähnliche Nickeligkeiten einfach nicht verwendest. Der common sense ist nunmal, dass man nicht überall quoted, damit sollte man rechnen und mit einbeziehen.

Andererseits muss man alle reservierten Wörter aller SQL-Dialekte kennen, um nicht in die Keyword-Falle spätestens beim Migrieren (YAGNI) zu tappen.

Das Subset an Keywords ist in den DBMSen recht ähnlich, die Wahrscheinlichkeit ist also gering. Ich muss also nicht wissen, dass ich int1, int2, int4 nicht verwende, sondern dass ich int* nicht verwende (nicht auf die Goldwage legen, du weisst sicher, was ich meine). Ansonsten sind Überraschungen natürlich immer möglich, klar, aber auch hier gilt wieder: der Aufwand steigt, je mehr man seinen eigenen Kopf durchsetzt und sich nicht an common sense hält.

Was würdest du beispielsweise als Ersatz für das reservierte Wort language verwenden, wenn man die Sprache meint, in der ein Text verfasst ist oder die ein Besucher spricht?

Ich würde entweder abkürzen (lang) oder spezifischer werden (user_language, text_language). Das hängt davon ab, ob sich die Sprache auf den ganze Datensatz bezieht oder nur auf ein einzelnes Datum.

Ich habe schon oft in anderen Datenbanken arbeiten müssen, für Kundenprojekte bei denen wir direkt auf die DB zugegriffen haben, bei FLOSS-Projekten, usw, pp. Haben sich die Leute nicht an den common sense bei Bezeichnern gehalten (bei einem Kunden waren z.B. Leerzeichen besonders beliebt), dann hat das immer zu mehr Komplexität und mehr Aufwand geführt. Ich würde davon immer abraten.

LG,
CK