quote:LinuX-TUX schreef op dinsdag 22 juli 2008 @ 09:25:
[...]
offtopic:
Doet me denken aan: http://halbot.haluze.sk/images/2008-06/4231_idiots.png uit sh4d0wman in "Het grote grappige plaatjes topic deel 18"
Website
lordpalf of the flapdrols
Voor een klant ben ik bezig om een applicatie bugfree te maken. Het is een vrij uitgebreide, niet georganiseerd, niet object-georienteerde sequentieel geprogrammeerde applicatie. Paar ergenissen
Elke pagina heeft een eigen html opmaak zonder stylesheet en wordt in een frame geladen.
Tabellen hebben vrijwel nooit auto-increment key's. De key's zijn user-input
Er is NIET over nagedacht.
Ergenissen!
PHP:
| <?php
|
Catch22 wijzigde dit bericht 23-07-2008 12:19 (9%)
Koffie?
Ja, Lekker
Beetje vreemd ingesprongen ook.
Music is an expression of pure emotion
Ik zat pas geleden code te bekijken waar het eerste niveau 5 spaties ingesproken was, het 2e 8 spaties, en de rest 9 spaties, dus:quote:Michali schreef op woensdag 23 juli 2008 @ 15:31:
Beetje vreemd ingesprongen ook.
code:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
| if (true)
{
// 1e niveau
{
// 2e niveau
{
// 3e niveau
{
// 4e niveau
{
}
}
}
}
} |
Totaal onleesbaar.
AtleX wijzigde dit bericht 23-07-2008 15:39 (8%)
Reg. datum: 28 april 2000
To be, or not to be, those are the parameters
Reg. datum: 20 maart 2001
Tsja, hangt ervan af. Als jij een coding standaard hanteert die je tekstbreedte limiteert op 80 tekens en je spreekt af dat je onder normale omstandigheden maar max 2-niveaus diep mag gaan dan kan ik dit best begrijpen en heen ten dage ken ik nog steeds enkele bedrijven die dit soort coding standards aanhangen.quote:AtleX schreef op woensdag 23 juli 2008 @ 15:39:
[...]
Ik zat pas geleden code te bekijken waar het eerste niveau 5 spaties ingesproken was, het 2e 8 spaties, en de rest 9 spaties, dus:
code:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15if (true) { // 1e niveau { // 2e niveau { // 3e niveau { // 4e niveau { } } } } }
Totaal onleesbaar.
Zo hebben wij bijvoorbeeld voor svn exports een macro eraan hangen die indent op 2 spaces en afbreekt na 80 tekens. Op 1600x1200 is dit een ramp om te lezen ( deze macro hangt dus niet aan de checkout ) maar op een server-console van 80x40 is dit weer perfect te lezen.
Java:
1 | TermEnum terms = ir.terms()
|
Betrapte ik mijzelf net op (geschreven toen ik net bezig was met Java. Het is geen hele grote wtf, maar toch...
You can't have everything. Where would you put it?
terms.term()
term, terms, TermEnum... niet echt duidelijk wat nu een term, terms, etc. allemaal doen/zijn voor iemand die jou code aan gaat passen, of voor jezelf als je na 6 maanden weer eens naar je code kijkt.
In java is het toch gebruikelijk om get en set methoden te schrijven:
terms.getTerm(); etc.
Reg. datum: 29 november 2000
Ik vind je opmerking onzinnig en toepasbaar op elke willekeurige 6 regels code uit elk project. Jij weet niet wat de context is, en daarom ook niet wat met 'term' bedoeld wordt. Wat niet wegneemt dat 'term' wel een gewoon woord is wat in meerdere contexten gewoon valide gebruikt kan worden.quote:4of9 schreef op vrijdag 25 juli 2008 @ 13:39:
misschien moet je iets aan je naamgeving doen.
terms.term()
term, terms, TermEnum... niet echt duidelijk wat nu een term, terms, etc. allemaal doen/zijn voor iemand die jou code aan gaat passen, of voor jezelf als je na 6 maanden weer eens naar je code kijkt.
Dit nog even volledig naast het feit dat TermEnum waarschijnlijk niet eens z'n eigen klasse is: zoeken bij google naar 'TermEnum'
Assumption is the mother of all fuck ups
*kuch* Javadoc *kuch*quote:4of9 schreef op vrijdag 25 juli 2008 @ 13:39:
misschien moet je iets aan je naamgeving doen.
terms.term()
term, terms, TermEnum... niet echt duidelijk wat nu een term, terms, etc. allemaal doen/zijn voor iemand die jou code aan gaat passen, of voor jezelf als je na 6 maanden weer eens naar je code kijkt.
In java is het toch gebruikelijk om get en set methoden te schrijven:
terms.getTerm(); etc.
Elke class, method of field (iig public en protected) hoort dat gewoon te hebben, met een duidelijke uitleg over wat het doel is en bij methods wat ze doen.
Dat zou dus voor term() en TermEnum het geval moeten zijn.
Maar ik ben het ook met Salandur eens, dit zou gewoon een Iterator (of desnoods Enumeration) moeten zijn.
More than meets the eye
There is no I in TEAM... but there is ME
Stanzinist | system specs
Wat ik bedoelde is dat bijna alle variabelen en methoden etc. "Iets"met term erin hebben. term, terms, term(), TermEnum. Ik vind dat gewoon niet helder. Ik zie ook wel eens code waar heel veel ints in loopjes gebruikt worden , i, j, y, z en dat allemaal door elkaar gebruikt. Ik vind dat niet echt duidelijk. Zeker niet als je na 6 maanden weer naar je code kijkt en je moet er een bugje uithalen.quote:.oisyn schreef op vrijdag 25 juli 2008 @ 15:24:
[...]
Ik vind je opmerking onzinnig en toepasbaar op elke willekeurige 6 regels code uit elk project. Jij weet niet wat de context is, en daarom ook niet wat met 'term' bedoeld wordt. Wat niet wegneemt dat 'term' wel een gewoon woord is wat in meerdere contexten gewoon valide gebruikt kan worden.
Dit nog even volledig naast het feit dat TermEnum waarschijnlijk niet eens z'n eigen klasse is: zoeken bij google naar 'TermEnum'
Ik zeg ook niet dat term niet valide is, ik vind het alleen niet duidelijk. Maar dat is meer een discussie over onderhoudbare en leesbare code. Als je bijvoorbeeld het boek "code complete" leest staat daar erg veel over in.
quote:4of9 schreef op vrijdag 25 juli 2008 @ 19:27:
Wat ik bedoelde is dat bijna alle variabelen en methoden etc. "Iets"met term erin hebben. term, terms, term(), TermEnum. Ik vind dat gewoon niet helder.
Java:
1 | CustomerEnum customers = ir.customers()
|
Tja.... ik zie het verschil niet zo; kom dit dagelijks tegen (los van de WTF dan
We all get along with some glue and duct tape here and there - but when the sh*t hits the fan, don’t blame the duct tape.
Trotse papa van Luca! | Pick My Icon!
Idd, als je functie 8 pagina's beslaat en je gebruikt de variabele daarna nog eens dan is het wellicht handiger om wat specifieker te zijn in bepaalde situaties. Maar die situatie is hier niet evident, en als je functie 8 pagina's beslaat is er wel meer aan de hand. Mijn punt blijft dat je over deze 6 regels code zonder context weinig over naamgeving ('terms' en 'term', de rest is niet eens in de handen van de poster) kunt zeggen. Variabelen met een korte lifetime behoeven geen 30 karakter namen die hun doel tot in detail beschrijven - dat blijkt namelijk gewoon heel duidelijk uit de lokale code.
.oisyn wijzigde dit bericht 25-07-2008 20:29 (76%)
Dat heeft weinig of niets te maken met slechtste programmeervoorbeelden te maken, maar alles met beroerde quality assurance (testen!) en je klant(en) opzadelen met wijzigingen die nog niet eens 't beta stadium hebben gehaald.quote:HawVer schreef op dinsdag 22 juli 2008 @ 08:59:
#$%@#$ Collega van mij heeft een trigger gemaakt die automatisch verkoopregels opsplitst. Nou werkt het toewijzen van artikelen niet meer, automatisch bestellen werkt niet meer, voorraad wordt niet goed bijgehouden. Of we dat even willen aanpassen...![]()
Elke ontwikkelaar weet dat 'ie bij wijzigingen in de business logic andere dingen omzeep kan helpen, en kan dit testen voor 't deel dat 'ie kan overzien, maar da's meestal niet voldoende.
Vandaar het belang van unit tests, uitgebreide testscripts en 1 of meerdere personen buiten het ontwikkelteam die de wijziging vrijgeeft voor release nadat alle tests goed zijn doorlopen.
"Bonken op de muur helpt niet, een goedgericht nekschot wel" - Sjaak Bral
Ik ken jouw situatie verder niet, maar op mijn werk heeft geen enkele tabel een synthetische (auto-increment/identity/whatever) key.quote:Catch22 schreef op woensdag 23 juli 2008 @ 12:18:
Tabellen hebben vrijwel nooit auto-increment key's. De key's zijn user-input
Er is NIET over nagedacht.
Bij de dynamische tabellen wordt de key gegenereerd door een stored procedure, en bij de statische tabellen (stamgegevens) is 't idd aan de user om de key in te geven (wel met voldoende checks natuurlijk).
Niks mis mee om in bv een landentabel de landcode als PK op te nemen, of in een artikelentabel de PLU-code. Beiden dienen sowieso al uniek te zijn, dus zijn uitstekend geschikt om als primary key te dienen.
"Bonken op de muur helpt niet, een goedgericht nekschot wel" - Sjaak Bral
Reg. datum: 20 maart 2001
En je zal er versteld van staan hoeveel programmeerbedrijfjes hier nog nooit van gehoord hebben.quote:Afterlife schreef op zaterdag 26 juli 2008 @ 00:25:
[...]
Dat heeft weinig of niets te maken met slechtste programmeervoorbeelden te maken, maar alles met beroerde quality assurance (testen!) en je klant(en) opzadelen met wijzigingen die nog niet eens 't beta stadium hebben gehaald.
Elke ontwikkelaar weet dat 'ie bij wijzigingen in de business logic andere dingen omzeep kan helpen, en kan dit testen voor 't deel dat 'ie kan overzien, maar da's meestal niet voldoende.
Vandaar het belang van unit tests, uitgebreide testscripts en 1 of meerdere personen buiten het ontwikkelteam die de wijziging vrijgeeft voor release nadat alle tests goed zijn doorlopen.
Ik ken redelijk wat programmeurs en hun test-omgevingen. Ongeveer 90% van de test-omgevingen is niet reeel als ik het met een klant van hun vergelijk.
Mensen buiten het ontwikkelteam die wijzigingen vrijgeven is leuk in theorie, maar bij bedrijven met weinig personeel krijg je of een telefoniste die niet 100% snapt hoe het programma werkt of iemand van binnen het ontwikkelteam. En als je een beetje maatwerk doet en veel snel moet opleveren wordt het testen alleen maar erger...
Reg. datum: 20 maart 2001
In theorie kan een landcode veranderen en vaker voorkomen. Theoretisch kan je hier dus een probleem mee krijgen.quote:Afterlife schreef op zaterdag 26 juli 2008 @ 00:59:
[...]
Niks mis mee om in bv een landentabel de landcode als PK op te nemen, of in een artikelentabel de PLU-code. Beiden dienen sowieso al uniek te zijn, dus zijn uitstekend geschikt om als primary key te dienen.
PLU codes zijn voor zover ik weet altijd 100% tijdsgebonden, ze moeten uniek zijn op een enkel moment, maar als je de ene eruitgooit dan kan je er best een ander artikel aan hangen. Dus imho rampzalig voor je historisch overzicht...
Op zich is het allemaal niet erg als je het leuk vind om tussen je historie en je actieve data andere PK's te hebben voor dezelfde artikelen. Maar zolang je niet aan BI doet lijkt me dit alleen maar moeilijk doen... Neem gewoon een unieke PK die ook uniek blijft...
Jep, net als in alle andere OO omgevingen.quote:4of9 schreef op vrijdag 25 juli 2008 @ 13:39:
In java is het toch gebruikelijk om get en set methoden te schrijven:
terms.getTerm(); etc.
Maar als je dan terms.getTerm() gaat aanroepen (als je dat al kunt) ipv de terms.term property die zelf terms.getTerm() doet, ga je voorbij aan het hele OO idee.
Getters en setters zijn niet public, en horen aangesproken te worden door de bijbehorende property.
"Bonken op de muur helpt niet, een goedgericht nekschot wel" - Sjaak Bral
In theorie zou dat kunnen, maar dan vallen een aantal ISO standaards om. De kans daarop is dus erg klein.quote:Gomez12 schreef op zaterdag 26 juli 2008 @ 01:08:
In theorie kan een landcode veranderen en vaker voorkomen. Theoretisch kan je hier dus een probleem mee krijgen.
Artikel codes blijven hardnekkig PLU codes genoemd worden, maar zijn al lang niet meer gebonden aan een bepaalde toets op de kassa. En zowel op de database als client side is prima af te vangen dat een eenmaal ingesteld artikel niet vervangen kan/mag worden wanneer deze in het verleden al gebruikt is bij die PLU.quote:PLU codes zijn voor zover ik weet altijd 100% tijdsgebonden, ze moeten uniek zijn op een enkel moment, maar als je de ene eruitgooit dan kan je er best een ander artikel aan hangen. Dus imho rampzalig voor je historisch overzicht...
Dus het niet gebruiken van synthetische keys hoeft je statistieken / business intelligence / data mining routines absoluut niet te benadelen.
Bij het gebruik van auto increment / identity keys moet je in je applicatie ook zorgen dat je bv. geen doublures krijgt om je statistieken niet te vervuilen, dus dat maakt eigenlijk niks uit.
"Bonken op de muur helpt niet, een goedgericht nekschot wel" - Sjaak Bral
C++:
1 | for (int i=0; i<container2.size() - container1.size(); ++i) {
|
Oh, en deze zat er ook per ongeluk tussen
C++:
1 | for (size_t y=height-1; y >= 0; --y) { // do stuff } |
*zucht*
Zoijar wijzigde dit bericht 26-07-2008 10:44 (18%)
De 2e zie ik zo snel niet, tenzij height 0 is...
-niks-
Nee, height is niet 0. Die is dan ook lastig te zienquote:MLM schreef op zaterdag 26 juli 2008 @ 10:58:
Hmm, gevalletje meer koffie of meer slaap nodig. De eerste is inderdaad echt moeilijk te vinden, ZEKER als je em zelf geschreven hebt.
De 2e zie ik zo snel niet, tenzij height 0 is...

