regelnummer afhankelijk configuratie bestand, anti-pattern?

[BdR]

Veel software ontwerp fouten zijn terug te herleiden tot een anti-pattern (zie wiki). Ik vroeg me af, is het onderstaande ook een anti-pattern oid?

Hier op het werk hebben we een meetapparaat met bijbehorend software. De bijbehorend applicatie heeft een configuratie bestand en enkel en alleen het regelnummer bepaalt om welk configuratie item het gaat. Dwz regel 1 is het laatst gelezen bestand, regel 2 is de output folder, regel 3 bevat hoelang de buzzer op het apparaat afgaat in ms etc. Ziet er ong. zo uit:

confdata.txt:

code:

READER00043
C:\Program Files\Reader\Data\
100
1
1
1
C:\Program Files\Reader\logo.bmp
1
etc.

Niet erg handig, want bij wijzigingen moet je maar net weten welke regel wat betekent en een foutje is zo gemaakt. De regelnummers staan overigens wel in de technische documentie, dat wel.
Maar goed, logischer zou zijn om er een inifile of XML file van maken, dus bijv zoiets:
confdata.ini

code:

lastfile=READER00043
outputdir=C:\Program Files\Reader\Data\
buzzerms=100
repeatmeasure=1
toolbarvisible=1
outputserialno=1
reportlogo=C:\Program Files\Reader\logo.bmp
patientreport=1
etc.

Anti-pattern, of komt dit in de praktijk wel vaker voor?

[Caelorum]

Uch, waarom het de eindgebruiker moeilijk maken als het ook makkelijk kan? Het is niet alsof het veel werk is om zo'n inifile parser te maken... Zou het zelf wellicht niet als anti-pattern beschouwen (want zo vaak komt het niet voor vermoed ik), maar zou wel sterk gaan afvragen wat de ontwikkelaars dachten toen ze dat stuk hebben geschreven. Ga je je toch afvragen of de kwaliteit van de code wel ok is

[efan]

Gezien de anti-pattern-wiki zou ik zeggen "Gold plating"

[.oisyn]

BdR schreef op vrijdag 20 juni 2014 @ 17:11:
Anti-pattern, of komt dit in de praktijk wel vaker voor?

Dat is een tegenspraak . Lang niet iedere design flaw is meteen een anti-pattern. Een pattern is een standaard oplossing voor een bepaald probleem, een anti-pattern is zo'n standaardoplossing die eigenlijk meer fout dan goed doet. Als het niet vaker voorkomt kun je niet echt spreken van een pattern en kan het dus ook geen anti-pattern zijn

De discussie of je een design-flaw als anti-pattern kunt klassificeren lijkt me een beetje nutteloos, maar dat is denk ik ook niet echt het onderliggende idee van je topic. Wat betreft dit specifieke probleem lijkt me het inderdaad wat onhandig want een fout sluipt er zo in. Maar het zal in de praktijk geheid wat vaker voorkomen, het parsen van zo'n configfile is natuurlijk extreem simpel. Tegelijkertijd is er vandaag de dag geen enkel excuus meer om niet gewoon voor een meestal out-of-the-box beschikbare ini, xml of json parser gebruik te maken.

[alienfruit]

Als het werkt... waarom veranderen?

[NMe]

alienfruit schreef op vrijdag 20 juni 2014 @ 18:02:
Als het werkt... waarom veranderen?

Mogelijk omdat "het" weliswaar werkt maar er bijvoorbeeld continu menselijke fouten uit voortkomen.

Overigens is dit natuurlijk niet veel meer of minder dan een comma separated file zonder headers. Dat er toevallig een enter tussen de velden staat in plaats van een (punt)komma doet daar natuurlijk niet aan af.

[Daos]

Misschien is het vanuit het programma gedacht en niet vanuit de gebruiker. Of het is gewoon gemakszucht.

Een tekstbestand inlezen en op volgorde met de regels iets doen is een fluitje van een cent. ini lezen is een stuk lastiger (zowel zelf maken als zoeken en aanroepen van een library).

[NMe]

Daos schreef op maandag 23 juni 2014 @ 19:48:
Misschien is het vanuit het programma gedacht en niet vanuit de gebruiker. Of het is gewoon gemakszucht.

Een tekstbestand inlezen en op volgorde met de regels iets doen is een fluitje van een cent. ini lezen is een stuk lastiger (zowel zelf maken als zoeken en aanroepen van een library).

Ook bij een ini-file zou je als extra beperking kunnen opleggen dat de volgorde vaststaat en dus op dezelfde manier alles hardcoden met als bijkomend voordeel dat alles wel human-readable is.

[Emiel L]

NMe schreef op maandag 23 juni 2014 @ 19:56:
[...]

Ook bij een ini-file zou je als extra beperking kunnen opleggen dat de volgorde vaststaat en dus op dezelfde manier alles hardcoden met als bijkomend voordeel dat alles wel human-readable is.

Dat is helemaal verwarrend, juist omdat een ini file suggereert dat de regelvolgorde niet van belang is...

[Standeman]

alienfruit schreef op vrijdag 20 juni 2014 @ 18:02:
Als het werkt... waarom veranderen?

Omdat de support afdeling het beu wordt

[NMe]

Emiel L schreef op dinsdag 24 juni 2014 @ 14:49:
[...]

Dat is helemaal verwarrend, juist omdat een ini file suggereert dat de regelvolgorde niet van belang is...

Dan nog is het beter dan wat ze nu gebruiken zonder beduidend anders te werken.

[Vishari Beduk]

BdR schreef op vrijdag 20 juni 2014 @ 17:11:
confdata.txt:

code:

READER00043
C:\Program Files\Reader\Data\
100
1
1
1
C:\Program Files\Reader\logo.bmp
1
etc.

Anti-pattern, of komt dit in de praktijk wel vaker voor?

Of dit wel of niet een anti-pattern is doet er niet toe. Het is gewoon heel erg fout.
Ten eerste omdat het gewoon niet gebruikers vriendelijk is.
Ten tweede is zijn 'harde' paden als 'C:\Program Files' ongewenst, beter is environment variables te gebruiken.
Ten derde is schrijven naar de program files directory tegenwoordig sowieso niet toegestaan.
En ten vierde is het beter om de uitvoer naar de user environment te schrijven.

edit / on second thought: waarschijnlijk is dit programma al meer dan 10 jaar oud, is de source code verdwenen, de oorsprongkelijke programmeurs vertrokken en de compiler niet meer beschikbaar
dus sowieso helaas, pindakaas

[ Voor 13% gewijzigd door Vishari Beduk op 24-06-2014 16:36 ]