Archief - [ALG] hoe verder gaan

Jormungand · 19 nov 2005

1. ik heb nergens gezegd dat ik op 2 dagen GOEDE OO systemen kon ontwerpen, dat heb jij er van gemaakt.

2. ik had het over het PRINCIPE van OO, dat had ik op 2 dagen volledig door. Dat is niet meer dan een klik die je moet kunnen zetten. Toch blijkt die niet zo heel eenvoudig blijkbaar. Als ik soms zogezegde OO code zie op internet staat die toch nog vol met imperatieve code gemengd met een paar classes enzo. Excuse me maar zo'n code kwam er bij mij na 2 dagen niet meer uit...

Ik weet niet hoor, maar iedereen dacht dat je dat weldegelijk bedoelde, ik ben niet de enige die dacht als je de reacties leest. Bij deze heb je jezelf dus kunnen verduidelijken.

Ik reageerde eigenlijk voornamelijk op jou post omdat je nogal spottend met iemand om ging...

3. plz spreek me niet over boeken bestuderen en UML diagrammen en collaboratiediagrammen en use cases en software engineering en aplicaties van 1000den regels code, refactoring, ik heb het allemaal gezien en gedaan...
daarmee moet ik je teleurstellen ja maar in die eerste 2 dagen heb ik toch meer opgedaan van OO programming dan die volgende 30 boeken later, dat zijn details, de fundamenten liggen in die eerste 2 dagen voor mij...

Ten eerst doe iets aan de opbouw van je zinnen, zo vaak 'en' bij elkaar trekt er niet echt op he. Voor de rest, ik ben blij om te horen dat je van het echte programmeer werk kan (hebt kunnen) proeven, alhoewel wat technische termen uitspuwen niks bewijst natuurlijk.

jij bent wel lachen "waar ik mee bezig ben hoe kan ik dingen schrijven in zo weinig mogelijk regels code."... Weetje dat dat argument nog maar voor 1 soort programmeren geldt en dat is wanneer je puur op performance en da's enkel STUKKEN uit game code en enkele zeer specifiek gerichte zaken die performance nodig hebben (OS design enzo) ... BIJ AL DE REST IS DAT DIKKE BULLSHIT.
'Any fool can write code that a computer can understand. Good programmers write code that humans can understand.' , dus bol em eens af met uw "zo weinig mogelijk regels code" als ge het hebt over alle soorten programma's...
Trouwens die regel gaat helemaal niet op, zo kan je stukken veel korter gaan schrijven met recursie ofzo, en noem je dat dan performance gericht ?

Hier ben ik het dus ook helemaal mee eens, je neemt me bijna de woorden uit de mond. Veel eeder, in een van mijn posts, heb ik reeds gezegd dat zogezegd 'slim' geschreven code veel moeilijker is om de snappen, te debuggen en correct te krijgen. Andersom, duidelijk geschreven code is veel beter te onderhouden, en correct te krijgen. Daarna kan je veel makkelijker die code ook nog eens gaan optimaliseren (kwa performance) indien dit na verschillende profiling sessies blijkt nodig te zijn. Dit past veel beter in het defensive programming plaatje dan die zogenaamde 'slimme' code.

Leesbare, onderhoudbare code hebben prioriteit boven alles, optimaliseren kan daarna nog altijd gebeuren, waar nodig blijkt. Een mens kan onmogelijk voorspellen waar precies de performance bottlenecks zullen zitten in een software systeem. Als je dat wel probeert te doen en dus al energie in zo optimaal mogelijke code steekt, dan kan je wel eens voor verrassingen komen te staan als blijkt dat je inschatting helemaal niet klopt. En geloof me, diegene die de 'slimme' code heeft geschreven, heeft na een 4 - 6 tal maanden zelf problemen om zijn eigen code terug te begrijpen (je vraagt jezelf vaak af wat je op dat moment toch maar aan het denken was!), zeker als je ondertussen met vele andere dingen bezig bent geweest. Wat dus zeker het geval is met pro programmeurs. Programmeurs die priorteit leggen om code 'slim' te schrijven zijn voor mij de rotte appels van het software team!

Unzip Attack · 19 nov 2005

Jormungand zei:
Ik weet niet hoor, maar iedereen dacht dat je dat weldegelijk bedoelde, ik ben niet de enige die dacht als je de reacties leest. Bij deze heb je jezelf dus kunnen verduidelijken.

Ik reageerde eigenlijk voornamelijk op jou post omdat je nogal spottend met iemand om ging...

okido misverstand. twas niet spottend bedoelt, eerder al lachend *2 en half jaar gaat iemand echt niet doen eer ie php kan he ;D*

Jormungand zei:
Ten eerst doe iets aan de opbouw van je zinnen, zo vaak 'en' bij elkaar trekt er niet echt op he. Voor de rest, ik ben blij om te horen dat je van het echte programmeer werk kan (hebt kunnen) proeven, alhoewel wat technische termen uitspuwen niks bewijst natuurlijk.

die opbouw met 'en' is eerder euhm om te aan te geven dat ik echt wel van die kaas heb gegeten en weet waarover ik spreek ;-) nuja tzijn idd een hoopje technische termen maar ik kan je evengoed een lijstje geven met dingen waar ik al aan gewerkt heb, praktisch heb ik het ook gedaan ja *ook in relatief grote projecten ja*

anyway genoeg gezever daarover, who cares anyway...

Jormungand zei:
En geloof me, diegene die de 'slimme' code heeft geschreven, heeft na een 4 - 6 tal maanden zelf problemen om zijn eigen code terug te begrijpen (je vraagt jezelf vaak af wat je op dat moment toch maar aan het denken was!), zeker als je ondertussen met vele andere dingen bezig bent geweest. Wat dus zeker het geval is met pro programmeurs. Programmeurs die priorteit leggen om code 'slim' te schrijven zijn voor mij de rotte appels van het software team!

daar kan ik me helemaal in terug vinden... Inwerken in je eigen code na maanden aan de kant te laten liggen is soms al moeilijk, laat staan dat je je moet inwerken in zogezegde 'slimme' code van iemand anders, da's een regelrechte ramp...

rotte appels als ze in team moeten werk ja, daar zeg je het...

Howitzer · 19 nov 2005

Oh djeezes, ik was van plan om later(zit in 't 4de) in KDG applicatie ontwikkeling te studeren en C++ proberen zelf te leren(lukt niet echt vlot -_- ).
En als ik iedereen hier bezig zie over OO, ben ik echt bang dat ik dat gewoon niet ga doorhebben en dan 3j verneuken aan KDG

S3cT0r · 19 nov 2005

Hola hola unzip attack, ik ga hier wel akkoord met h@voc_!nc, ik schrijf liever ook minder regels dan meer regels, jij gebruikt daar zo het spreekwoord 'Any fool can write code that a computer can understand. Good programmers write code that humans can understand.', maar als ik gvd zie wat sommige (wat zeg ik, de mééste) OO programmeurs van een paar simpele taken maken dan vloek ik eens heel hard zen. En ja, om die reden gebruik ik ook liever recursie dan looping, omdat de conversie meestal zo'n code expansie vereist dat je toch bij ongeveer dezelfde performance blijft maar dat de code onleesbaar word (probeer bijvoorbeeld door het windows filesysteem te gaan met FindFirstFile en FindNextFile zonder recursie te gebruiken, en je zal zien hoeveel ingewikkelder de code word, gewoon niet te doen). Het is echter wel zo dat ik, als het ongeveer dezelfde moeilijkheidsgraad heeft, liever looping gebruik, uit performanceoverwegingen (voor élke soort applicatie, zeg me niet dat het niet nodig is, sommige programmeurs denken dat met resources te smijten valt).

Unzip Attack · 20 nov 2005

S3cT0r zei:
Hola hola unzip attack, ik ga hier wel akkoord met h@voc_!nc, ik schrijf liever ook minder regels dan meer regels, jij gebruikt daar zo het spreekwoord 'Any fool can write code that a computer can understand. Good programmers write code that humans can understand.', maar als ik gvd zie wat sommige (wat zeg ik, de mééste) OO programmeurs van een paar simpele taken maken dan vloek ik eens heel hard zen.

Weetje in tijden waar patches, beta versies, extra aanpassingen, mods, ... maar ook engineers die bedrijf verlaten na verloop van tijd, programmeurs die van bedrijf naar bedrijf springen,... regel zijn, is het gewoon ONDENKBAAR dat je van de instelling "zo weinig mogelijk regels" uitgaat.
Het heeft ZEKER zijn nut om een afweging te maken om iets meer code te nemen om bijvoorbeeld een betere OO structuur te krijgen. Zo zal je ACHTERAF als er iets moet bijkomen of aangepast wordt in zo'n code enorm veel tijd winnen tov dat 'zo weinig mogelijk regels' principe. En vermits tijd = money, is dat vandaag gewoon DE regel PUNT. in EENDER welk zichzelf respecterend bedrijf. Software engineering is geen bijzaak meer geworden die zo eens tussenin kan gedaan worden, in elk groot project is dat gewoon de enige manier die werkt.
En dat spreekwoord is zo waar als maar kan zijn, al zijn er veel te weinig programmeurs die echt heel goed OO kunnen programmeren (merk op , ik zeg _niet_ dat ik fijnloos OO kan programmeren en de perfectie ben)

KeaTs · 20 nov 2005

Ik denk dat jij verkeerdelijk uitgaat van het idee dat zo weinig mogelijk regels code per sé wil zeggen zo onduidelijk/complex mogelijk. Als je uitgaat van een goed design kan je er gerust naar streven zo weinig mogelijk regels code te hebben zonder onleesbaar te worden. Ik denk echt niet dat ze met zo weinig mogelijk regels code bedoelen dat ze alle syntaxtruukjes gebruiken om uw aantal regels te beperken (dàt soort programmeurs mogen ze idd tegen een muurke plaatsen

), maar eerder zo veel mogelijk overbodige code te vermijden door een beter design. Daar ga ik toch van uit

Programmeurs die zo slim mogelijk willen schrijven in jouw opvatting van het woord ben je liever kwijt dan rijk, volledig mee eens; maar ik ken ook heel wat programmeurs die veel overbodige/dubbele code schrijven door een gebrekkig design, en die kunnen wel wat efficientie gebruiken.

Trouwens, als je in team werkt of tussen projecten switch staat of valt uw begrip van nieuwe code echt niet door het aantal regels code, wel door de documentatie van de oorspronkelijke programmeur. Het zelfde gaat op voor code die je zelf schrijft en een aantal jaar later zelf weer opvist. Goed gedocumenteerde code leest als een boek, zelfs al is de code zelf complex.

Howitzer: zeker niet tegenop zien, OO programmeren is net eenvoudig eens je de onderliggende principes wat doorhebt, en dat is heus niet zo moeilijk. OO zorgt er net voor dat complexe problemen heel eenvoudige oplossingen kunnen hebben.

Unzip Attack · 20 nov 2005

KeaTs zei:
Ik denk dat jij verkeerdelijk uitgaat van het idee dat zo weinig mogelijk regels code per sé wil zeggen zo onduidelijk/complex mogelijk. Als je uitgaat van een goed design kan je er gerust naar streven zo weinig mogelijk regels code te hebben zonder onleesbaar te worden. Ik denk echt niet dat ze met zo weinig mogelijk regels code bedoelen dat ze alle syntaxtruukjes gebruiken om uw aantal regels te beperken (dàt soort programmeurs mogen ze idd tegen een muurke plaatsen ), maar eerder zo veel mogelijk overbodige code te vermijden door een beter design. Daar ga ik toch van uit Programmeurs die zo slim mogelijk willen schrijven in jouw opvatting van het woord ben je liever kwijt dan rijk, volledig mee eens; maar ik ken ook heel wat programmeurs die veel overbodige/dubbele code schrijven door een gebrekkig design, en die kunnen wel wat efficientie gebruiken.

Trouwens, als je in team werkt of tussen projecten switch staat of valt uw begrip van nieuwe code echt niet door het aantal regels code, wel door de documentatie van de oorspronkelijke programmeur. Het zelfde gaat op voor code die je zelf schrijft en een aantal jaar later zelf weer opvist. Goed gedocumenteerde code leest als een boek, zelfs al is de code zelf complex.

tis maar hoe je "zo weinig mogelijk regels" interpreteerd. in "zo weinig mogelijk regels" zit ook het ontbreken van commentaar, het verkorten van constructies die veel duidelijker zijn als ze uitgeschreven zijn, ... ben ik gewoon radicaal tegen

wlibaers · 20 nov 2005

S3cT0r zei:
Hola hola unzip attack, ik ga hier wel akkoord met h@voc_!nc, ik schrijf liever ook minder regels dan meer regels, jij gebruikt daar zo het spreekwoord 'Any fool can write code that a computer can understand. Good programmers write code that humans can understand.', maar als ik gvd zie wat sommige (wat zeg ik, de mééste) OO programmeurs van een paar simpele taken maken dan vloek ik eens heel hard zen. En ja, om die reden gebruik ik ook liever recursie dan looping, omdat de conversie meestal zo'n code expansie vereist dat je toch bij ongeveer dezelfde performance blijft maar dat de code onleesbaar word (probeer bijvoorbeeld door het windows filesysteem te gaan met FindFirstFile en FindNextFile zonder recursie te gebruiken, en je zal zien hoeveel ingewikkelder de code word, gewoon niet te doen). Het is echter wel zo dat ik, als het ongeveer dezelfde moeilijkheidsgraad heeft, liever looping gebruik, uit performanceoverwegingen (voor élke soort applicatie, zeg me niet dat het niet nodig is, sommige programmeurs denken dat met resources te smijten valt).

Hangt ervan af. Voor een probleem dat van nature goed recursief te behandelen is zullen de prestaties wel meevallen (het enige probleem is een stack overflow als je echt diep gaat), vooral omdat je de overhead die je elimineert door van recursie af te stappen gedeeltelijk terugkrijgt door je eigen stack te maken. Staartrecursie kan je best wel elimineren (sommige compilers doen dit trouwens automatisch).

Unzip Attack zei:
tis maar hoe je "zo weinig mogelijk regels" interpreteerd. in "zo weinig mogelijk regels" zit ook het ontbreken van commentaar, het verkorten van constructies die veel duidelijker zijn als ze uitgeschreven zijn, ... ben ik gewoon radicaal tegen

Ik denk dat met "minder regels" eerder bedoeld wordt de code eenvoudig te houden. Het aantal regels zegt in de meeste talen niet veel over de complexiteit van een programma, omdat de syntax van de meeste talen niet erg gevoelig is voor nieuwe lijnen en je dus gewoon alle regels van een programma op een enkele lijn zou kunnen gooien.

De hoeveelheid commentaar beperken is wel een goed idee. Commentaar gebruik je best alleen als er dingen zijn die niet meteen duidelijk zijn in de code. Als je code moet aanpassen moet de commentaar ook aangepast worden, wat extra werk betekent. En als mensen onder zware tijdsdruk staan "vergeten" ze misschien de commentaar aan te passen, waardoor die iets anders beweert dan wat de code eigenlijk doet.

Verkeerde commentaar is erger dan geen commentaar. Iedereen die denkt dat hijzelf of collega's slechte beslissingen i.v.m. variabelen zouden nemen als bepaalde zaken niet afgedwongen worden met het "private" keyword, moet zich eigenlijk ook over dit probleem zorgen maken, met dit verschil dat je geen keyword hebt om comments te controleren (commentaar in de vorm van assert macro's of iets degelijks is wel afdwingbaar, maar alleen commentaar over bijvoorbeeld toegelaten invoerwaarden of resultaten kan je in die vorm in de code zetten, je verklaart er geen werking mee).

H@voc_!nc. · 21 nov 2005

@Jormungand : Je m'excuse

@ Unzip Attack
Zo weinig mogelijk regels zijn zo weinig mogelijk regels en nie minder tot int idiote, performance veeg ik persoonlijk mijn reet aan... geef mij is 2 dingen die performance verbeteren? Kent ge assembler? MIL? leg me eens uit...

minder regels code = minder mogelijke bugs.

Code moet:
Compact zijn.
Goed Leesbaar.
Zelf documenterend.
(zo het enige waar dak nu op kan komen)

blokken commentaar van een half scherm krijg ik de kriebels van

Unzip Attack · 21 nov 2005

H@voc_!nc. zei:
Zo weinig mogelijk regels zijn zo weinig mogelijk regels en nie minder tot int idiote, performance veeg ik persoonlijk mijn reet aan... geef mij is 2 dingen die performance verbeteren? Kent ge assembler? MIL? leg me eens uit...
minder regels code = minder mogelijke bugs.

Code moet:
Compact zijn.
Goed Leesbaar.
Zelf documenterend.
(zo het enige waar dak nu op kan komen)

blokken commentaar van een half scherm krijg ik de kriebels van

ja ik ken assembler (het programma zelf heb ik ooit moeten schrijven, de taal heb ik ooit een paar dagen mee moeten werken), en nee MIL ken ik niet.

zelf documenterend is vrij ruim begrip als je het mij vraagt, als daarmee wordt bedoelt dat UML ofzo nutteloos (is in principe geen onderdeel van de code en toch documenterend) is het bullshit. zelf documenterend in de zin van dat code duidelijk is op zich oke daar is iedereen toch voor ? blokken commentaar van een half scherm is relatief, als de main klasse van een groot programma een blok commentaar bevat met een kort overzicht over alle samenhang tss klasses zie ik daar het probleem niet van in... zulke blokken tussen 'normale' code is idd fout.
compact is relatief. als je dingen als

try {
code
}
catch {
blabla
}

wil gaan vervangen door enkel "code" om het compacter te maken is dat gewoon fout.
Zo heb ik ooit code voorgekregen met "switches" tot 3 niveaus in elkaar genest, met als uitleg "ja we wouden alles zo overzichtelijk en tegelijk compact mogelijk hebben"... daar heb ik toch mijn bedenkingen bij

eneuhm

minder regels code = minder mogelijke bugs.

gaat ook niet altijd op. Als je regels hebt van

if(object.function(object3.getfunction(object.function("23").getvalue().toString).toString).equals(object3.getfunction(object2.property)) == 0) {
...
}

om minder regels te krijgen is dat vrij fout in mijn ogen, je verliest namelijk veeeeel meer tijd in debuggen in bovenstaande dan een wat uitgesplitstere versie

H@voc_!nc. · 21 nov 2005

Mijn procedures zijn nooit meer dan enkele regels lang dat is wa dak bedoel
ik hebbet met documenteren niet over UML

maar zoals bvb dit (is wel een beetje er over maar toch) :
//Geeft het adres trug
public string GetA(){

}
maak daarvan GetAddress();

is gewoon ronduit belachelijk (en komt meer voor dan da ge denkt)

en met compacte code bedoel ik nie crappy code
want
"if(object.function(object3.getfunction(object.func tion("23").getvalue().toString).toString).equals(o bject3.getfunction(object2.property)) == 0) {"

is gewoon ronduit verkeerd daar gade Acces Violations tegen de hel op krijgen en veel succes met ze de vinden

met compacte code bedoel ik kort duidelijke blokken van code opgesplits in eenduidige procedures...

bon ik schij der hier mee uit...

laatste post

zwaar off topic

ben nog wel op uw 2 performance tips aan het wachten

Unzip Attack · 21 nov 2005

H@voc_!nc. zei:
ben nog wel op uw 2 performance tips aan het wachten

ah sorry vergeten

euhm

1. vermijden van recursie -> performance omhoog als je diep gaat werken
2. vermijden van algoritmen van exponentieele complexiteit

S3cT0r · 21 nov 2005

Dat is natuurlijk wel heel wat makkelijker gezegd dan gedaan Unzip Attack

H@voc_!nc. · 21 nov 2005

ik werk bijna nooit met recursie is te moeilijk om aan uit te kunnen en is zeer slecht voor performantie zeker vanaf dat ge meer dan 2 parameters meegeeft... en moeilijke wiskunde functies moette sowieso bijna nooit gebruiken

wlibaers · 21 nov 2005

H@voc_!nc. zei:
ik werk bijna nooit met recursie is te moeilijk om aan uit te kunnen en is zeer slecht voor performantie zeker vanaf dat ge meer dan 2 parameters meegeeft... en moeilijke wiskunde functies moette sowieso bijna nooit gebruiken

Verschillende methoden voor het doorzoeken van boomstructuren gebruiken wel een stack, en zijn dus goede kandidaten voor recursie.

zarathustra · 21 nov 2005

Unzip Attack zei:
zulke blokken tussen 'normale' code is idd fout.

en wij maar commentaar schrijven een tijd terug.(Object gericht programmeren in 2de kan burgie)

al uw postcondities ven elke methode formeel en informeel bespreken, etc. Ik ben er zeker van dat er in ons practicum toen 70% commentaar stond >_<

Waarmee ik maar wil zeggendat men soms precies wel veel belang hecht aan commentaar.

wlibaers · 21 nov 2005

zarathustra zei:
en wij maar commentaar schrijven een tijd terug.(Object gericht programmeren in 2de kan burgie)

al uw postcondities ven elke methode formeel en informeel bespreken, etc. Ik ben er zeker van dat er in ons practicum toen 70% commentaar stond >_<

Waarmee ik maar wil zeggendat men soms precies wel veel belang hecht aan commentaar.

Pre- en postcondities in de mate van het mogelijke in assert-macro's of iets gelijkaardigs stoppen. Dan heb je meer kans dat ze up to date gehouden worden als de code aangepast wordt.

Unzip Attack · 24 nov 2005

zarathustra zei:
en wij maar commentaar schrijven een tijd terug.(Object gericht programmeren in 2de kan burgie)

al uw postcondities ven elke methode formeel en informeel bespreken, etc. Ik ben er zeker van dat er in ons practicum toen 70% commentaar stond >_<

Waarmee ik maar wil zeggendat men soms precies wel veel belang hecht aan commentaar.

tja voor educatieve doeleinden is dat niet zo slecht. je kan er namelijk een eerste controle mee doen of het eigen geschreven code is en verder moet het gewoonte worden om hier en daar een regel commentaar te schrijven. 70% commentaar is natuurlijk totaal ridicuul ;D wat moest je trouwens maken ?

Unzip Attack · 24 nov 2005

wlibaers zei:
Verschillende methoden voor het doorzoeken van boomstructuren gebruiken wel een stack, en zijn dus goede kandidaten voor recursie.

idd recursie kan zeker zijn nut hebben en zeker als je weet dat je stack beperkt blijft, heeft die methode voorrang bij mij. Recursie is goed als je ze op een goeie manier gebruikt. Same for backtracking dat heel effectief kan zijn voor AI enzo...

Archief - [ALG] hoe verder gaan

Jormungand

Legacy Member

Unzip Attack

Legacy Member

Howitzer

Legacy Member

S3cT0r

Legacy Member

Unzip Attack

Legacy Member

KeaTs

Legacy Member

Unzip Attack

Legacy Member

wlibaers

Legacy Member

H@voc_!nc.

Legacy Member

Unzip Attack

Legacy Member

H@voc_!nc.

Legacy Member

Unzip Attack

Legacy Member

S3cT0r

Legacy Member

H@voc_!nc.

Legacy Member

wlibaers

Legacy Member

zarathustra

Legacy Member

wlibaers

Legacy Member

Unzip Attack

Legacy Member

Unzip Attack

Legacy Member