Mehrere Bereiche in Test erkennen

[Zvoni]

Sehr seltsam. Ok, weiss ich dann auch nicht weiter

 

[CopWorker]

Hallo Zvoni,

kein Problem.
Ist da nicht so `ne Art OR Verknüpfung erforderlich.
Auch die Reihenfolge der TAGs im Suchstring sollt nicht bindend sein
um einen Erfolg zu erzielen.

Trotzdem vielen Dank.
Gruß CopWorker

 

[Zvoni]

Hallo Zvoni,

kein Problem.
Ist da nicht so `ne Art OR Verknüpfung erforderlich.
Auch die Reihenfolge der TAGs im Suchstring sollt nicht bindend sein
um einen Erfolg zu erzielen.

Trotzdem vielen Dank.
Gruß CopWorker

Autsch.
Ich glaube mich dunkel daran zu erinnern, dass man mit einem Positive Lookahead die "Reihenfolge" ignorieren kann.

Wenn aber die Reihenfolge egal/unterschiedlich sein kann, dann würde ich bei deinem ursprünglichen Ansatz bleiben: 4 separate Regex-Calls, und Basta (zumal das ja anscheinend funktioniert)

 

[CopWorker]

Hallo Zvoni,

4 separate Regex-Calls, und Basta (zumal das ja anscheinend funktioniert)

Ja, in dem Fall hast du Recht.
Ich bin halt gerade beauftragt das Codezeilen Aufkommen zu minimieren/optimieren.

Jetzt steht halt das Aufwand-/Nutzen-Verhältnis nicht im Gleichgewicht.
Das kann ich ja so begründen.

Passt.
Grüße CopWorker

 

[Zvoni]

btw: Deine 4 Aufrufe würde ich in eine separate Funktion auslagern.

So in der Art:
Dictionary (mit 4 Einträgen): Key=Capture-Group-Name (Bsp. "code"), Value=Das Pattern zu der Gruppe
Die Funktion hat ein Argument: Den Gruppen-Namen
Rückgabewert: ToArray

Funktionsaufruf würde dann irgendwie so aussehen:

liGroupTemp = MeineRegexFunktion("group");
liCodeTemp = MeineRegexFunktion("code");
liPosTemp = MeineRegexFunktion("pos");
liInvTemp = MeineRegexFunktion("inv");

 

[Spyke]

Ja, in dem Fall hast du Recht.
Ich bin halt gerade beauftragt das Codezeilen Aufkommen zu minimieren/optimieren.

Immer auch auf die Wartbarkeit achten.

Codezeilen aufkommen zu verringern ist eh ein schwachsinn
(außer man macht irgendwelche Hardware nahen sachen wo es wirklich wenig speicherraum gibt),
doppelte Aufrufe vermeiden ja, aber Code zu verkleinern nur weil es zu viele Zeilen sinn, schwachsinn.

Code refactorn, ja, wo es sinnvoll ist, aber nicht zwanghaft.

 

[CopWorker]

doppelte Aufrufe vermeiden ja, aber Code zu verkleinern nur weil es zu viele Zeilen sinn, schwachsinn.

Sehe ich ja auch so.
Muss mich bloß gegenüber meinem Auftraggeber rechtfertigen.
In der Begründung lass ich halt das Wort "schwachsinn" weg.
Dann wird alles gut.

Trotzdem vielen Dank.
Gruß CopWorker