[alg] Slechtste programmeervoorbeelden deel 4

[G70boX]

.oisyn schreef op dinsdag 20 december 2011 @ 16:18:
Als je nou gewoon eens mijn hele post las

[...]

Kunnen static analysis tools dit ook niet redelijk eenvoudig detecteren?

[RayNbow]

G70boX schreef op dinsdag 20 december 2011 @ 18:16:
[...]


Kunnen static analysis tools dit ook niet redelijk eenvoudig detecteren?

C heeft een static type system, dus zo moeilijk is dat niet.

[Tim]

Ik was aan het zoeken of Websockets ook compressie ondersteunen, en daarbij kwam ik de volgende post tegen:

quote: http://www.ietf.org/mail-...ybi/current/msg01824.html

We've wondered here at Google why so many requests come from browsers claiming not to support compression. After a lot of investigation (I was not involved with this work), we ran into client requests which contained headers like:
Accept-Xncoding: gzip, deflate

What is that?

Well, it turns out that some anti-virus providers didn't want to support compression in payloads. Doing so meant that sometimes they couldn't inspect the payloads, and they were too lazy to implement the basic, well-known compressors. So these anti-virus programs watched for outbound HTTP requests and intentionally mangled the browser's outbound "Accept-Encoding" header. This prevents the server from knowing the browser supports compression, and thus the anti-virus software can look through the result without having to do any decompress work. But what happened here? The poor user in this case just had the single-worst-thing happen to his browser - no compression at all!!! And all because of some lazy man-in-the-middle.

Dus als je je weer afvraagt waarom het internet opeens trager lijkt... Het zou me ook niet verbazen als het nog een stapje verder gaat en dat als een vijandelijke site gewoon de Accept-Xncoding header respecteert het resultaat niet door de virusscanner wordt gescand.

[.oisyn]

Sowieso, een virusscanner die niet in compressed containers kan kijken?

[Cartman!]

Ik had dat eens in een boek gelezen (Building Scalable Websites, O'Reilly) dat ze bij Flickr ook checken op zulke headers en dan inderdaad ook gzip/deflate toch toepassen.

[decipherer]

Wat ik net toch tegenkom in de code hier.. Dit zou een random waarde moeten genereren:

C#:

result.Referentienummer = 
"BLA" + new Random(1000).Next(100000000, 1000000000).ToString(CultureInfo.InvariantCulture);

[.oisyn]

Doet het toch ook?

Desalniettemin, ik vind het wel een design flaw dat er niet gewoon een standaard globale instance van Random bestaat. De seed weghalen uit die ctor maakt het namelijk niet heel veel beter, en als iedereen zijn eigen Random class 1 keer instantieert (bijv. in de static ctor van de class) loop je de kans dat verschillende systemen dezelfde reeks van randomwaarden genereren.

[ Voor 90% gewijzigd door .oisyn op 05-01-2012 11:29 ]

[PiepPiep]

Volgens mij is het net zo random als http://xkcd.com/221/

[.oisyn]

Ik denk net zo random als

[ Voor 6% gewijzigd door .oisyn op 05-01-2012 12:10 ]

[wjzijderveld]

Dat is toch altijd het probleem met random? Uiteindelijk is random nooit random, maar altijd ergens van afgeleid (9 van de 10 keer de tijd?).

[Caelorum]

Dat was de grap niet

[ Voor 85% gewijzigd door Caelorum op 05-01-2012 12:33 ]

[.oisyn]

Dat het ergens van afgeleid is maakt niet zoveel uit. Dat het de hele tijd hetzelfde is is vaak juist niet de bedoeling. Overigens bestaat er weldegelijk hardware dat daadwerkelijk random getallen produceert (meestal gebaseerd op de inherente onvoorspelbaarheid van quantummechanische processen, zoals de spin van een electron of polarisatie van een foton)

[ Voor 50% gewijzigd door .oisyn op 05-01-2012 12:35 ]

[wjzijderveld]

Caelorum schreef op donderdag 05 januari 2012 @ 12:32:
Dat was de grap niet

Nee klopt, was meer een hersenspinsel van me Geen reactie op de grap, meer op het fenomeen random.

.oisyn schreef op donderdag 05 januari 2012 @ 12:33:
Dat het ergens van afgeleid is maakt niet zoveel uit. Dat het de hele tijd hetzelfde is is vaak juist niet de bedoeling. Overigens bestaat er weldegelijk hardware dat daadwerkelijk random getallen produceert (meestal gebaseerd op de inherente onvoorspelbaarheid van quantummechanische processen, zoals de spin van een electron of polarisatie van een foton)

Dat wist ik niet, leuk om te weten!
Maar de meeste developers zullen zo'n apparaat niet thuis hebben staan
En het maakt inderdaad meestal niet uit de random ergens vanaf geleid wordt, zolang de situatie zoals in de Dilbert maar niet de praktijk is, is het in veel gevallen al goed.

[.oisyn]

wjzijderveld schreef op vrijdag 06 januari 2012 @ 11:17:
Maar de meeste developers zullen zo'n apparaat niet thuis hebben staan

Nee, maar daar heb je het internet voor: http://www.random.org/

[bwerg]

En binnenkort heeft iedereen er wel een.

[Davio]

.oisyn schreef op donderdag 05 januari 2012 @ 11:26:
Doet het toch ook?

Desalniettemin, ik vind het wel een design flaw dat er niet gewoon een standaard globale instance van Random bestaat. De seed weghalen uit die ctor maakt het namelijk niet heel veel beter, en als iedereen zijn eigen Random class 1 keer instantieert (bijv. in de static ctor van de class) loop je de kans dat verschillende systemen dezelfde reeks van randomwaarden genereren.

Dit heb ik ook altijd een aparte ontwerpkeuze gevonden...

[Onbekend]

Ik kwam er deze week in C# op Win7 achter dat als je in een loop (waarbij geen user-interactie is) snel achter elkaar new Random(); gedaan wordt de "random" waarden het zelfde zijn. Als er meer dan een 1ms tussen zit, geeft hij wel een andere random waarde.

Ik heb het maar opgelost door een globale variabele aan te maken die ik dan overal kan aanroepen.

[Aloys]

Onbekend schreef op zaterdag 07 januari 2012 @ 12:30:
Ik kwam er deze week in C# op Win7 achter dat als je in een loop (waarbij geen user-interactie is) snel achter elkaar new Random(); gedaan wordt de "random" waarden het zelfde zijn. Als er meer dan een 1ms tussen zit, geeft hij wel een andere random waarde.

Ik heb het maar opgelost door een globale variabele aan te maken die ik dan overal kan aanroepen.

Maar zo moet het nu juist ook zijn. In java erger ik mij er ook aan dat ik een new Random object moet aanmaken. Waarom? Zijn de nummers minder random als je alle methods in die Random-class static maakt? Nee, juist niet. * Aloys zwaait naar Oracle (eigenlijk nog de schuld van Sun)

Edit: In projecten waarbij ik dus random waarden nodig heb, maak ik een RandomFactory. Daarin maak ik static methoden die precies kunnen teruggeven wat ik wil, dus niet alleen int of bool ofzo. Is het ergens toch weer mooi opgelost . (Dit alles maakt natuurlijk gebruik van één interne Random instantie)

[ Voor 16% gewijzigd door Aloys op 07-01-2012 12:52 ]

[CoolGamer]

Aloys schreef op zaterdag 07 januari 2012 @ 12:50:
[...]

Maar zo moet het nu juist ook zijn. In java erger ik mij er ook aan dat ik een new Random object moet aanmaken. Waarom? Zijn de nummers minder random als je alle methods in die Random-class static maakt? Nee, juist niet. * Aloys zwaait naar Oracle (eigenlijk nog de schuld van Sun)

Ik denk dat dit de belangrijkste reden is voor de huidige implementatie van Random:

Nu is de gebruiker zelf verantwoordelijk voor synchronisatie tussen de threads. Maakt de implementatie van de Random class veel simpeler.

Hoe sla je de seed op als je een static Random maakt? Maak je automatisch de Random-objecten threadlocal, dan is het mogelijk dat ze dezelfde seed kiezen als je twee threads tegelijk maakt. Maak je het niet threadlocal, dan moet je er voor zorgen dat er niet tegelijk naar de seed wordt geschreven. Dit heeft weer negatieve gevolgen voor de performance.

Ik denk dat de huidige keuze het makkelijkst is en in de meeste situaties wel voldoet.

[.oisyn]

Aloys schreef op zaterdag 07 januari 2012 @ 12:50:
[...]

Maar zo moet het nu juist ook zijn. In java erger ik mij er ook aan dat ik een new Random object moet aanmaken.

Maar in Java heb je dan iig nog een globale random dmv Math.random()

@CoolGamer: niemand twijfelt hier denk ik over het bestaansrecht van een Random class. Er zijn tal van situaties waar je zelf een instance wilt beheren waar verder niemand aan mag zitten, en die bovendien serializable is. Maar dat houdt nog niet in dat er geen standaard globale 'instance' (in welke vorm dan ook) mag bestaan. Java heeft Math.random() (die thread-safe is), .Net heeft niets. Als je "gewoon even een random waarde wilt hebben" zonder enige poespas dan is het maintainen van een Random instance veel teveel hassle.

[ Voor 48% gewijzigd door .oisyn op 07-01-2012 17:20 ]

[CoolGamer]

Ik wou het huidige bestaansrecht niet beargumenteren. Ik bedoelde met huidige implementatie de implementatie zonder statische methoden.

Als libarymaker zou ik de afweging of er ook statische varianten van de Random-methodes moeten komen of niet ook beslissen met het achterwege laten van de statische methodes. De performance van de statische methodes is stuk lager, terwijl je er eigenlijk uiteindelijk maar één regel code mee bespaart.

[JohnStaakke]

Tim schreef op woensdag 04 januari 2012 @ 11:31:
Ik was aan het zoeken of Websockets ook compressie ondersteunen, en daarbij kwam ik de volgende post tegen:


[...]


Dus als je je weer afvraagt waarom het internet opeens trager lijkt... Het zou me ook niet verbazen als het nog een stapje verder gaat en dat als een vijandelijke site gewoon de Accept-Xncoding header respecteert het resultaat niet door de virusscanner wordt gescand.

Wow deze moet ik echt onthouden, zijn er Anti virus progs bekend die dit doen??

[Gamebuster]

Prachtige Ruby on Rails applicatie... kom je dit tegen:

code:

if ['piet', 'klaas', 'daan'].include?(current_user.username)

[ Voor 8% gewijzigd door Gamebuster op 27-01-2012 19:19 ]

[Vinnienerd]

Tim schreef op woensdag 04 januari 2012 @ 11:31:
Ik was aan het zoeken of Websockets ook compressie ondersteunen, en daarbij kwam ik de volgende post tegen:


[...]


Dus als je je weer afvraagt waarom het internet opeens trager lijkt... Het zou me ook niet verbazen als het nog een stapje verder gaat en dat als een vijandelijke site gewoon de Accept-Xncoding header respecteert het resultaat niet door de virusscanner wordt gescand.

Ik heb toen ik nog bij een bekende buitenlandse Internetprovider werkte ook ontelbaar vaak mensen geadviseerd Norton/McAfee/etc. er af te gooien. Al die anti-viruspakketten kutten met je dataverkeer.

[Alex)]

JavaScript:

    function letsBlur(thisone) {
        thisone.blur();
    }

[Otherside1982]

Alex) schreef op dinsdag 31 januari 2012 @ 11:05:

JavaScript:

    function letsBlur(thisone) {
        thisone.blur();
    }

JavaScript:

    function letsFire(thisDeveloper) {
        thisDeveloper.Fire();
    }

[Quinie]

Ik kwam dit vandaag tegen in een javascript..

Wat de eerste (in het geheel van de app) doet geen idee....

code:

      function doNothing(){
        return false;
      }
           
      function showTip(msg){
        if (msg){
            Tip(msg);
        }
      }

beide zatten ook nog eens in een file die hele andere dingen moet doen..

[PatrickH89]

De eerste moet vermoedelijk iets doen in de zin van:

HTML:

 <a href="http://bla" onclick="doNothing();">link</a>

Blijft natuurlijk wel een slecht programmeervoorbeeld

[ Voor 3% gewijzigd door PatrickH89 op 01-02-2012 15:00 ]

[Creepy]

Die doNothing() kan gebruikt worden om event bubbling en default acties van browsers tegen te gaan om zo bijv. een rechtermuisklik uit te schakelen zodat je browser geen menu toont.. Dus die kan wel degelijk nut hebben.

[skabouter]

code:

while(doNothing()){
  thisDeveloper.Fire();
}

[Quinie]

Creepy schreef op woensdag 01 februari 2012 @ 15:05:
Die doNothing() kan gebruikt worden om event bubbling en default acties van browsers tegen te gaan om zo bijv. een rechtermuisklik uit te schakelen zodat je browser geen menu toont.. Dus die kan wel degelijk nut hebben.

Bedankt voor dit inzicht. Das hier ook nog niet het geval.. zal is zoeken in de code of er uberhaubt een aanroep is naar deze functie

[.oisyn]

Creepy schreef op woensdag 01 februari 2012 @ 15:05:
Die doNothing() kan gebruikt worden om event bubbling en default acties van browsers tegen te gaan om zo bijv. een rechtermuisklik uit te schakelen zodat je browser geen menu toont.. Dus die kan wel degelijk nut hebben.

Maar doe dan gewoon onclick="false"

[Creepy]

Een onclick="false" vangt niet de rechtermuisknop af dus zul je een event moeten binden, en daar is die functie die false return wel nuttig voor.

[kenneth]

Naamgeving is geen raketwetenschap. Zou je zeggen.

C#:

public bool ValidateEmail(string address)

// ...

public bool CheckPersoon(PersoonEntity persoon)

// enz ...

Als CheckPersoon true retourneert, is de check dan goed gegaan, is persoon dan goed bevonden of is er een ongeldige waarde gevonden?

Van die code waar je om de tien minuten "OMG" roept ...

[Alex)]

Daarom, een enum:

C#:

public enum ValidationResult
{
    Success,
    Fail,
    FileNotFound
}

[Creepy]

Van die code waar je om de tien minuten "OMGWTF" roept ...

[Verwijderd]

Creepy schreef op woensdag 01 februari 2012 @ 16:52:
Een onclick="false" vangt niet de rechtermuisknop af dus zul je een event moeten binden, en daar is die functie die false return wel nuttig voor.

Met een 'onclick="false"' vang je ook een normale click niet af...

[.oisyn]

"return false" dan. Er stond ook geen "return doNothing()" dus wat dat betreft gedraagt het zich identiek.

[iH8]

nvt

[ Voor 97% gewijzigd door iH8 op 02-02-2012 13:18 . Reden: was niet wakker ]

[Grijze Vos]

kenneth schreef op donderdag 02 februari 2012 @ 10:56:
Als CheckPersoon true retourneert, is de check dan goed gegaan, is persoon dan goed bevonden of is er een ongeldige waarde gevonden?

Ik ben al blij als die functie dan niet een paar side effects heeft. In de codebase van een product waar ik aan bezig ben doet een CheckX functie makkelijk helemaal niks checken. In plaats daarvan worden er allemaal properties veranderd.

[Spockz]

Eigenlijk wil je een soort garantie hebben dat een functie geen side-effects heeft he? Een functie heeft standaard geen side-effect totdat je zegt dat dat zo is, door middel van een type oid.

[Janoz]

Grijze Vos schreef op donderdag 02 februari 2012 @ 13:13:
[...]


Ik ben al blij als die functie dan niet een paar side effects heeft. In de codebase van een product waar ik aan bezig ben doet een CheckX functie makkelijk helemaal niks checken. In plaats daarvan worden er allemaal properties veranderd.

Dat is ook een interpretatie. Gewoon alle in het object aanwezige booleans op true zetten . THis object is now fully checked.

[Verwijderd]

Spockz schreef op donderdag 02 februari 2012 @ 13:22:
Eigenlijk wil je een soort garantie hebben dat een functie geen side-effects heeft he? Een functie heeft standaard geen side-effect totdat je zegt dat dat zo is, door middel van een type oid.

Een functie heeft altjd een side-effect. Zelfs BCALL(_DoNothing) op TI-OS. Die doet niets anders dan clock cycles verspillen

[Olaf van der Spek]

PHP:

gmdate('Y-m-d H:s', $ctime);

Pas ontdekt na 5 jaar...

[Grijze Vos]

Spockz schreef op donderdag 02 februari 2012 @ 13:22:
Eigenlijk wil je een soort garantie hebben dat een functie geen side-effects heeft he? Een functie heeft standaard geen side-effect totdat je zegt dat dat zo is, door middel van een type oid.

Volgens mij snap je niet helemaal wat ik bedoel.

Janoz schreef op donderdag 02 februari 2012 @ 13:40:
Dat is ook een interpretatie. Gewoon alle in het object aanwezige booleans op true zetten . THis object is now fully checked.

Hehe, die is goed.

[RayNbow]

Spockz schreef op donderdag 02 februari 2012 @ 13:22:
Eigenlijk wil je een soort garantie hebben dat een functie geen side-effects heeft he? Een functie heeft standaard geen side-effect totdat je zegt dat dat zo is, door middel van een type oid.

Hoezo garantie?

Haskell:

unsafePerformIO :: IO a -> a

[Spockz]

Grijze Vos schreef op donderdag 02 februari 2012 @ 13:49:
[...]

Volgens mij snap je niet helemaal wat ik bedoel.

Jawel. Als je een functie ziet genaamd "CheckX" maar het type van die functie omvat dat hij een side-effect heeft weet je al dat je moet oppassen en dat er wellicht iets naars aan de hand is.

@RayNbow: Jaja... Die kon ik verwachten.

[kenneth]

Command-query separation dus Niet altijd heilig, wel een goed principe.

[PhoenixT]

Spockz schreef op donderdag 02 februari 2012 @ 13:22:
Eigenlijk wil je een soort garantie hebben dat een functie geen side-effects heeft he? Een functie heeft standaard geen side-effect totdat je zegt dat dat zo is, door middel van een type oid.

In C++ heb je toch gewoon const functies die geen member data mogen veranderen? (behalve als de member data specifiek als mutable is aangemerkt)

[Olaf van der Spek]

PhoenixT schreef op donderdag 02 februari 2012 @ 14:18:
In C++ heb je toch gewoon const functies die geen member data mogen veranderen? (behalve als de member data specifiek als mutable is aangemerkt)

Ja, maar er is meer dan member data. Veel meer.

[Spockz]

PhoenixT schreef op donderdag 02 februari 2012 @ 14:18:
[...]

In C++ heb je toch gewoon const functies die geen member data mogen veranderen? (behalve als de member data specifiek als mutable is aangemerkt)

Ja die heb je. Ik weet niet hoe het precies zit in C++ maar volgens mij als je een const pointer meekrijgt betekent dat alleen dat je de pointer niet mag aanpassen, maar dat je properties wel kunt veranderen. Maar dit weet ik niet zeker... Bovendien is het bij het gebruik van const andersom: alles is effectful behalve dingen die je met const aanmerkt. In Haskell is het andersom.

[Jegorex]

Spockz schreef op donderdag 02 februari 2012 @ 14:02:
[...]


Jawel. Als je een functie ziet genaamd "CheckX" maar het type van die functie omvat dat hij een side-effect heeft weet je al dat je moet oppassen en dat er wellicht iets naars aan de hand is.

@RayNbow: Jaja... Die kon ik verwachten.

Maar wat moet "CheckX" doen? Maakt het een rekening, zet het alles op true, of word er iets gecontrolleerd?

[DEiE]

PhoenixT schreef op donderdag 02 februari 2012 @ 14:18:
[...]

In C++ heb je toch gewoon const functies die geen member data mogen veranderen? (behalve als de member data specifiek als mutable is aangemerkt)

Stiekem mis ik dit soort constructies in talen als .net, ik vind dat const correctness een stuk nettere code oplevert, omdat je hiermee bovengenoemde problemen voorkomt.

[.oisyn]

Spockz schreef op donderdag 02 februari 2012 @ 14:25:
[...]

Ja die heb je. Ik weet niet hoe het precies zit in C++ maar volgens mij als je een const pointer meekrijgt betekent dat alleen dat je de pointer niet mag aanpassen, maar dat je properties wel kunt veranderen.

Met "const pointer" wordt meestal pointer-to-const bedoeld, en dan mag je de pointer wel aanpassen, maar niet het object waarnaar verwezen wordt (want die is const). Als de pointer zelf const is dan mag je de pointer niet aanpassen.

C++:

int a = 0, b = 1;
const int * p1 = &a;
int * const p2 = &a;
const int * const p3 = &a;

p1 = &b; // ok
*p1 = 3; // error

p2 = &b; // error
*p2 = 3; // ok

p3 = &b; // error
*p3 = 3; // error

[ Voor 3% gewijzigd door .oisyn op 02-02-2012 14:44 ]

[BikkelZ]

Vinnienerd schreef op zaterdag 28 januari 2012 @ 00:56:
[...]


Ik heb toen ik nog bij een bekende buitenlandse Internetprovider werkte ook ontelbaar vaak mensen geadviseerd Norton/McAfee/etc. er af te gooien. Al die anti-viruspakketten kutten met je dataverkeer.

Hehehe mijn vriendin had McAfee gekocht (zonder vooroverleg uiteraard) WANT het was een aanbieding. Gelukkig nog net geen Norton in ieder geval. Volgens mij kun je beter gewoon gratis virusscanners als Avira draaien, die proberen tenminste niet zo veel te doen waar je niet om gevraagd hebt.

Ze vroeg zich af waarom ik hem nog niet geinstalleerd had....

[Verwijderd]

BikkelZ schreef op donderdag 02 februari 2012 @ 15:22:
[...]


Hehehe mijn vriendin had McAfee gekocht (zonder vooroverleg uiteraard) WANT het was een aanbieding. Gelukkig nog net geen Norton in ieder geval. Volgens mij kun je beter gewoon gratis virusscanners als Avira draaien, die proberen tenminste niet zo veel te doen waar je niet om gevraagd hebt.

Ze vroeg zich af waarom ik hem nog niet geinstalleerd had....

Nee joh, je moet gewoon een Mac kopen, daar zijn geen virussen voor!

[Verwijderd]

Hoe niet te documenteren:

Reset when there is 10 bytes long no data

Bytes waarvan? Wat moet ik hiermee?

Delayed COUNTER_ONE_SEC_SEVEN(18) bit

Wat is COUNTER_ONE_SEC_SEVEN nou weer? Staat verder echt nergens beschreven.

[EddoH]

Java..

y u no support unmodifiable Stack !?

edit: oh, shit... dit is niet de coffeecorner...

[ Voor 43% gewijzigd door EddoH op 06-02-2012 12:04 ]

[Gaius]

Af en toe word ik zo verdrietig van de code hier. Op zich is het allemaal redelijk netjes, maar waarom nou alles in 1 class proppen en het aantal methods zo klein mogelijk houden.

Net dus 1 method van 300 regels in 19 stukken gehakt en in een eigen class geplaatst. 19 stukken die al netjes aangeduid waren met regions (C#) ook, dus de oorspronkelijke programmeur wist al dat het makkelijk in hapklare brokken gehakt kon worden.

Goed, nu staat er nog een method van 1200 regels te wachten. Feest.
* Gaius heeft een nieuwe muis nodig; scrollwieltje heeft het begeven.

[.oisyn]

Gaius schreef op maandag 06 februari 2012 @ 15:27:
Net dus 1 method van 300 regels in 19 stukken gehakt

Pff peanuts, ik zit nu in een method van 980 regels

[ Voor 9% gewijzigd door .oisyn op 06-02-2012 15:39 ]

[Remus]

EddoH schreef op maandag 06 februari 2012 @ 12:00:
Java..

y u no support unmodifiable Stack !?

edit: oh, shit... dit is niet de coffeecorner...

Why the hell zou je een unmodifiable Stack willen hebben? Gebruik dan gewoon een (unmodifiable) list...

[.oisyn]

Oh, zo'n stack. Ik dacht al, waarom zou je stackspace unmodifiable moeten zijn? Als container is een unmodifiable stack niet heel erg zinnig. Eigenlijk is dat gewoon alleen maar het bovenste element.

[BikkelZ]

Gaius schreef op maandag 06 februari 2012 @ 15:27:
Af en toe word ik zo verdrietig van de code hier. Op zich is het allemaal redelijk netjes, maar waarom nou alles in 1 class proppen en het aantal methods zo klein mogelijk houden.

Net dus 1 method van 300 regels in 19 stukken gehakt en in een eigen class geplaatst. 19 stukken die al netjes aangeduid waren met regions (C#) ook, dus de oorspronkelijke programmeur wist al dat het makkelijk in hapklare brokken gehakt kon worden.

Goed, nu staat er nog een method van 1200 regels te wachten. Feest.
* Gaius heeft een nieuwe muis nodig; scrollwieltje heeft het begeven.

Tja heel vreemd is dat. Alleen omdat het sequentieel in de zelfde class gebeurt wil het nog niet zeggen dat het dan allemaal in één functie moet. Als een functie niet meer in één scherm past doet hij waarschijnlijk al te veel. Wat zie je liever in een Initialize, vijf duidelijke functiecalls of 500 regels code voor het initialiseren van je Controls?

[Patriot]

Verwijderd schreef op maandag 06 februari 2012 @ 10:49:
Hoe niet te documenteren:


[...]


Bytes waarvan? Wat moet ik hiermee?

Dat klinkt sowieso als een Nederlander die geen knap Engels spreekt. Dat is ook vreselijk irritant

[MBV]

BikkelZ schreef op maandag 06 februari 2012 @ 15:54:
[...]


Tja heel vreemd is dat. Alleen omdat het sequentieel in de zelfde class gebeurt wil het nog niet zeggen dat het dan allemaal in één functie moet. Als een functie niet meer in één scherm past doet hij waarschijnlijk al te veel. Wat zie je liever in een Initialize, vijf duidelijke functiecalls of 500 regels code voor het initialiseren van je Controls?

1 duidelijke call met daaromheen "Don't touch this, this is visual studio generated code"

[mieJas]

Ben bezig met een slecht lopende SQL-query aan het debuggen. Een geneste query daaruit is:

SQL:

SELECT d.id
FROM deur d
LEFT OUTER JOIN gebouw g ON d.gebouwid = g.id
LEFT OUTER JOIN afdeling a ON d.afdelingid = a.id
WHERE g.id IN (SELECT s.id FROM gebouw s WHERE s.id = 1)

Took me a while...

[whoami]

MBV schreef op maandag 06 februari 2012 @ 16:31:
[...]

1 duidelijke call met daaromheen "Don't touch this, this is visual studio generated code"

Ik zie het liever niet. .

[kenneth]

mieJas schreef op maandag 06 februari 2012 @ 16:52:
Ben bezig met een slecht lopende SQL-query aan het debuggen. Een geneste query daaruit is:

SQL:

SELECT d.id
FROM deur d
LEFT OUTER JOIN gebouw g ON d.gebouwid = g.id
LEFT OUTER JOIN afdeling a ON d.afdelingid = a.id
WHERE g.id IN (SELECT s.id FROM gebouw s WHERE s.id = 1)

Took me a while...

Zie ik iets over het hoofd anders dan:

SQL:

WHERE g.id = 1

[.oisyn]

Gewoon

SQL:

SELECT 1

Al is er nog wel een verschil tussen wel en geen resultaat in de originele query

.edit: oh nee wacht, g.id != d.id

[ Voor 13% gewijzigd door .oisyn op 06-02-2012 17:11 ]

[Olaf van der Spek]

BikkelZ schreef op maandag 06 februari 2012 @ 15:54:
Wat zie je liever in een Initialize, vijf duidelijke functiecalls of 500 regels code voor het initialiseren van je Controls?

500 lines... met 5 duidelijke comments erboven

[Gaius]

Olaf van der Spek schreef op maandag 06 februari 2012 @ 17:21:
[...]

500 lines... met 5 duidelijke comments erboven

Hierin sta ik achter Robert Martin: Als je comments nodig hebt om je code uit te leggen heb je als programmeur gefaald. Heerlijk ongenuanceerd, maar een mooie richtlijn die je dwingt goed na te denken over de leesbaarheid van je code. Ik gebruik dus ook in principe geen comments, al zijn er altijd uitzonderingen natuurlijk.

Het project waar ik nu aan werk bevat in ieder geval veel te veel comments die niets toevoegen:

C#:

// instantieer businesslayer object
BusinessLayerObject businessLayerObject = new BusinessLayerObject(object meuk);

// voer validatie uit en stop resultaat in boolean
bool validationResult = businessLayerObject.ValidateMeuk();

// check of validatie goed gegaan is, zo ja -> update
if(validationResult == true)
{
   // voer update actie uit
   businessLayerObject.Update();
}
else
{
   // gooi exception
   throw new Exception("ValidatieFout");
}

Jeuk....
Dat soort comments voegt niets toe, behalve beheerwerk en potentiële fouten/verwarring omdat iemand vergeet de comments bij te werken na het fixen van een bug. Weg ermee.

Om dus terug te komen op de vraag van BikkelZ:
Indien het gegenereerde code is waar ik toch niet aan mag zitten wordt het maar lekker in een partial class in een aparte file weggestopt. Als het door mensen gemaakt is wil ik het in hapklare brokjes gehakt zien. De codestandaard die ik moet volgen zegt dat een method maximaal 150 regels mag zijn. Eigenlijk is dat natuurlijk al veel te veel.

[kenneth]

Commentaar is nuttig om te vertellen waarom je iets doet. Als je moet uitleggen wat of hoe je iets doet dan zit je op het verkeerde pad ja

[Verwijderd]

Gaius schreef op maandag 06 februari 2012 @ 18:23:
[...]


Hierin sta ik achter Robert Martin: Als je comments nodig hebt om je code uit te leggen heb je als programmeur gefaald. Heerlijk ongenuanceerd, maar een mooie richtlijn die je dwingt goed na te denken over de leesbaarheid van je code. Ik gebruik dus ook in principe geen comments, al zijn er altijd uitzonderingen natuurlijk.

Het project waar ik nu aan werk bevat in ieder geval veel te veel comments die niets toevoegen:

C#:

// instantieer businesslayer object
BusinessLayerObject businessLayerObject = new BusinessLayerObject(object meuk);

// voer validatie uit en stop resultaat in boolean
bool validationResult = businessLayerObject.ValidateMeuk();

// check of validatie goed gegaan is, zo ja -> update
if(validationResult == true)
{
   // voer update actie uit
   businessLayerObject.Update();
}
else
{
   // gooi exception
   throw new Exception("ValidatieFout");
}

Jeuk....
Dat soort comments voegt niets toe, behalve beheerwerk en potentiële fouten/verwarring omdat iemand vergeet de comments bij te werken na het fixen van een bug. Weg ermee.

Om dus terug te komen op de vraag van BikkelZ:
Indien het gegenereerde code is waar ik toch niet aan mag zitten wordt het maar lekker in een partial class in een aparte file weggestopt. Als het door mensen gemaakt is wil ik het in hapklare brokjes gehakt zien. De codestandaard die ik moet volgen zegt dat een method maximaal 150 regels mag zijn. Eigenlijk is dat natuurlijk al veel te veel.

Echt slecht is de code niet. Het commentaar is wat overbodig, maar zal de werking van het programma niet beïnvloeden.

Daarbij vind ik het beperken van een hoeveelheid code die een method mag hebben ook iets waar ik grote vraagtekens bij zet. Natuurlijk is met code hoe korter hoe beter (nee, soms is lange code zelfs sneller) maar in sommige gevallen kan je niet anders - of je moet nietszeggende methods gaan maken die maar door één andere method aangeroepen gaan worden. Nee, dan ben je lekker bezig...

Meestal als ik een hele lange method nodig heb zorg ik er voor dat die goed gedocumenteerd is maar ik ga zeker niet onnodig veel kleinere methods maken.

[ Voor 5% gewijzigd door Verwijderd op 06-02-2012 19:19 ]

[kenneth]

Dat soort zaken horen richtlijnen te zijn, wat mij betreft. Dus een methode met meer dan $random regels is niet fout maar je moet jezelf wel achter de oren krabben.

Then again, als ik bij een bedrijf werk waar die regel geldt ben ik pragmatisch genoeg om braaf te luisteren

[Verwijderd]

Ik vind dat je altijd bij code moet afwegen of het de juiste is. Maar ik vind ook dat je niet zomaar moet gaan zeggen van "je hebt meer dan 100 regels code in je method, dat kan beter!" Dan zeg ik weer van "ik heb meer dan 100 regels code nodig in die method om de gewenste situatie te bereiken." En daar draait het om, dat je een werkend product oplevert. Een opdrachtgever kijkt echt niet naar of je 50 methods van 10 regels of 5 methods van 100 regels hebt.

[Aloys]

Gaius schreef op maandag 06 februari 2012 @ 18:23:
[...]


Hierin sta ik achter Robert Martin: Als je comments nodig hebt om je code uit te leggen heb je als programmeur gefaald. Heerlijk ongenuanceerd, maar een mooie richtlijn die je dwingt goed na te denken over de leesbaarheid van je code. Ik gebruik dus ook in principe geen comments, al zijn er altijd uitzonderingen natuurlijk.

Het project waar ik nu aan werk bevat in ieder geval veel te veel comments die niets toevoegen:

C#:

// instantieer businesslayer object
BusinessLayerObject businessLayerObject = new BusinessLayerObject(object meuk);

// voer validatie uit en stop resultaat in boolean
bool validationResult = businessLayerObject.ValidateMeuk();

// check of validatie goed gegaan is, zo ja -> update
if(validationResult == true)
{
   // voer update actie uit
   businessLayerObject.Update();
}
else
{
   // gooi exception
   throw new Exception("ValidatieFout");
}

Jeuk....
Dat soort comments voegt niets toe, behalve beheerwerk en potentiële fouten/verwarring omdat iemand vergeet de comments bij te werken na het fixen van een bug. Weg ermee.

Om dus terug te komen op de vraag van BikkelZ:
Indien het gegenereerde code is waar ik toch niet aan mag zitten wordt het maar lekker in een partial class in een aparte file weggestopt. Als het door mensen gemaakt is wil ik het in hapklare brokjes gehakt zien. De codestandaard die ik moet volgen zegt dat een method maximaal 150 regels mag zijn. Eigenlijk is dat natuurlijk al veel te veel.

Ik geeft de voorkeur aan iets als dit:

C#:

BusinessLayerObject businessLayerObject = new BusinessLayerObject(object meuk);

if (businessLayerObject.ValidateMeuk()) {
   businessLayerObject.Update();
}
else {
   throw new Exception("ValidatieFout");
}

Edit: Om mijzelf nog maar wat in de discussie te mengen. Ik stel het ongeveer zo: Kan (of ga) ik deze code hergebruiken of is wat hier gebeurd teveel details en is een beetje abstractie beter, dan verdwijnt de code in een aparte functie. Hierin moet je natuurlijk overwegen wat redelijk is, sommige mensen willen wel weer eens doorslaan .

[ Voor 8% gewijzigd door Aloys op 06-02-2012 19:36 ]

[Verwijderd]

Aloys schreef op maandag 06 februari 2012 @ 19:33:
[...]


Ik geeft de voorkeur aan iets als dit:

C#:

BusinessLayerObject businessLayerObject = new BusinessLayerObject(object meuk);

if (businessLayerObject.ValidateMeuk()) {
   businessLayerObject.Update();
}
else {
   throw new Exception("ValidatieFout");
}

Kan nog korter

C#:

var businessLayerObject = new BusinessLayerObject(object meuk);

if (businessLayerObject.ValidateMeuk()) 
   businessLayerObject.Update();
else 
   throw new Exception("ValidatieFout");

[Aloys]

Het kan nog wel korter hoor, maar dat is niet het punt. Het grootste verschil was de boolean variabele die weg kan en de comments die weg kunnen, dit is gewoon een spelletje om het korter te maken.

C#:

var businessLayerObject = new BusinessLayerObject(object meuk);
if (businessLayerObject.ValidateMeuk())  businessLayerObject.Update();
else throw new Exception("ValidatieFout");

[RTG]

Verwijderd schreef op maandag 06 februari 2012 @ 19:16:
[...]
Echt slecht is de code niet. Het commentaar is wat overbodig, maar zal de werking van het programma niet beïnvloeden.

En zo kun je dus beter niet denken.
Commentaar kun je imo het beste gewoon beschouwen als (onderdeel van je) code. Met slecht commentaar gaat men deze juist meer negeren en over zaken heen lezen die misschien net wel nuttig waren. Commentaar hoort te zeggen wat de code niet kan zeggen, al het andere is ruis.

[Remus]

Gaius schreef op maandag 06 februari 2012 @ 18:23:
Het project waar ik nu aan werk bevat in ieder geval veel te veel comments die niets toevoegen:

C#:

// instantieer businesslayer object
BusinessLayerObject businessLayerObject = new BusinessLayerObject(object meuk);

// voer validatie uit en stop resultaat in boolean
bool validationResult = businessLayerObject.ValidateMeuk();

// check of validatie goed gegaan is, zo ja -> update
if(validationResult == true)
{
   // voer update actie uit
   businessLayerObject.Update();
}
else
{
   // gooi exception
   throw new Exception("ValidatieFout");
}

Jeuk....
Dat soort comments voegt niets toe, behalve beheerwerk en potentiële fouten/verwarring omdat iemand vergeet de comments bij te werken na het fixen van een bug. Weg ermee.

Misschien iemand die Code Complete (2), hoofdstuk 9 'The Pseudocode Programming Process' heeft gelezen? Volgens dat 'proces' beschrijf je eerst in redelijk high-level pseudocode wat er moet gebeuren (intent), dat zet je om in comments en daarna ga je pas de werkelijke code invoeren. Die comments laat je daarna - voor zover nuttig - staan. Het echte probleem dat ik zie is dat de comments op een te laag niveau zijn en daarom dus niet echt nuttig zijn naast de code.

Verwijderd schreef op maandag 06 februari 2012 @ 19:33:
Ik vind dat je altijd bij code moet afwegen of het de juiste is. Maar ik vind ook dat je niet zomaar moet gaan zeggen van "je hebt meer dan 100 regels code in je method, dat kan beter!" Dan zeg ik weer van "ik heb meer dan 100 regels code nodig in die method om de gewenste situatie te bereiken." En daar draait het om, dat je een werkend product oplevert. Een opdrachtgever kijkt echt niet naar of je 50 methods van 10 regels of 5 methods van 100 regels hebt.

Persoonlijk vind ik het altijd wel makkelijker om korte methodes te hebben, dan is het veel makkelijker om te redeneren waar je mee bezig bent en wat er gebeurt. Ook vind ik dat je bij het (re)factoren naar korte methodes vaak ook beter nadenkt over verantwoordelijkheid en scope. Aan de andere kant vind ik dogmatisch korte methodes maken omdat Robert C. Martin zegt dat het moet ook weer onzin .

[ Voor 26% gewijzigd door Remus op 06-02-2012 19:54 ]

[kenneth]

En nog niemand is gevallen over de belabberde naam ValidateMeuk

[ZpAz]

Weet niet of het in C# gebruikelijk is, maar methode namen beginnen met een hoofdletter... brr.

[CoolGamer]

ZpAz schreef op maandag 06 februari 2012 @ 20:29:
Weet niet of het in C# gebruikelijk is, maar methode namen beginnen met een hoofdletter... brr.

Ja, dat is de standaard conventie in C#. Went vanzelf.

[kenneth]

ZpAz schreef op maandag 06 februari 2012 @ 20:29:
Weet niet of het in C# gebruikelijk is, maar methode namen beginnen met een hoofdletter... brr.

Dat maakt dan weer helemaal niets uit. When in Rome ...

[ZpAz]

Mja, ik ben niet in Rome Maar het zal natuurlijk gewenning zijn.

[kenneth]

Je bent wel in Nederland en schrijft geen methodenamen maar methode namen, ieder z'n gebrek

[PhoenixT]

Ik kom uit een C# achtergrond en heb het beginnen van methodenamen met een hoofdletter altijd heel natuurlijk gevonden; het maakt het verschil tussen variabelen en methoden duidelijker. Ben dan ook benieuwd wat precies de argumentatie is van zowel variabelen als methoden met een kleine letter beginnen, afgezien van "gewenning".

[ZpAz]

De () er achter lijkt me wel aangeven dat het een methode is.

[ Voor 7% gewijzigd door ZpAz op 06-02-2012 20:51 ]

[PhoenixT]

Die staat er enkel achter als je direct naar de code kijkt, he

[EddoH]

.oisyn schreef op maandag 06 februari 2012 @ 15:47:
Oh, zo'n stack. Ik dacht al, waarom zou je stackspace unmodifiable moeten zijn? Als container is een unmodifiable stack niet heel erg zinnig. Eigenlijk is dat gewoon alleen maar het bovenste element.

Remus schreef op maandag 06 februari 2012 @ 15:41:
[...]

Why the hell zou je een unmodifiable Stack willen hebben? Gebruik dan gewoon een (unmodifiable) list...

Ja die had ik aan kunnen zien komen.

Ik probeer wat legacy code hier een beetje te fatsoeneren, en geen zin om compleet te refactoren. Een unmodifiable Stack heb je an sich niet veel aan nee, en dat was juist m'n bedoeling

[Verwijderd]

ZpAz schreef op maandag 06 februari 2012 @ 20:29:
Weet niet of het in C# gebruikelijk is, maar methode namen beginnen met een hoofdletter... brr.

Grappig, ik zeg precies hetzelfde over methode namen beginnend met een kleine letter. En de rest van de JAVA-rarigheden.

[ZpAz]

PhoenixT schreef op maandag 06 februari 2012 @ 20:54:
Die staat er enkel achter als je direct naar de code kijkt, he

Hoe bedoel je?

Verwijderd schreef op maandag 06 februari 2012 @ 21:18:
[...]

Grappig, ik zeg precies hetzelfde over methode namen beginnend met een kleine letter. En de rest van de JAVA-rarigheden.

En praktisch elke andere taal op aarde Volgens mij is toch echt C# het buitenbeentje hier.

[Verwijderd]

VB gebruikt ook hoofdletters

Maar werkelijk:

Java:

public class Persoon {

private String naam;
private String adres;
private String postcode;
private Date geboorteDatum;

public String getNaam() {
return this.naam;
}

public void setNaam(String value){
this.naam = value;
}

public String getAdres(){
return this.adres;
}

public void setAdres(String value){
this.adres = value;
}


public String getPostcode(){
return this.postcode;
}

public void setPostcode(String value) {
this.postcode = value;
}

public Date getGeboorteDatum(){
return this.geboorteDatum;
}

public void setGeboorteDatum(Date value){
this.geboorteDatum = value;
}

}

/me heeft moeie handen..

C#:

public class Persoon
{
public string Naam { get; set; }
public string Adres { get; set; }
public string Postcode { get; set; }
public DateTime GeboorteDatum { get; set; }
}

Nou, ik weet wel wat ik liever heb...

[ZpAz]

Dat is een ander verschil, ik zou ook voor het laatste gaan inderdaad, ik ben namelijk ook niet echt een Java fan

Maar dat doet niets af aan het feit dat ik een hoofdletter aan het begin van een methode nog steeds vreemd vind staan. En VB en C# komen uit "hetzelfde huis" dus daar zouden inderdaad vergelijkbare dingen in kunnen zitten.

VB6 en QBasic, those good ol' days.

[ Voor 54% gewijzigd door ZpAz op 06-02-2012 21:33 ]

[PhoenixT]

ZpAz schreef op maandag 06 februari 2012 @ 21:20:
[...]


Hoe bedoel je?

Bij code completion, gegenereerde diagrammen etc wordt vrijwel altijd de methodenaam zonder () getoond.

[Verwijderd]

Zo heeft elke taal wel wat, In C# is het enige echt vreemde - mocht je van Java afkomen - het hoofdletter gebruik.

Wat op .NET (C#, VB) aankomt ben ik zo pro-MS als ik maar wezen kan

[ Voor 24% gewijzigd door Verwijderd op 06-02-2012 21:40 ]

[ZpAz]

PhoenixT schreef op maandag 06 februari 2012 @ 21:32:
[...]

Bij code completion, gegenereerde diagrammen etc wordt vrijwel altijd de methodenaam zonder () getoond.

Bij code completion kan je in een beetje IDE lijkt mij toch wel zien wat het verschil is tussen een methode en een variabele. En bij UML diagrammen zit er een scheidingslijn tussen variabelen en methoden.

Verwijderd schreef op maandag 06 februari 2012 @ 21:33:
Zo heeft elke taal wel wat, In C# is het enige echt vreemde - mocht je van Java afkomen - het hoofdletter gebruik.

Geen enkele taal is inderdaad perfect.

[ Voor 21% gewijzigd door ZpAz op 06-02-2012 21:35 ]

[Brainscrewer]

Ik ben sowieso een dikke Java noob, maar dit is wel heel erg.

final JTextField this.aantalStappen = new JTextField();



(en idd de compiler geeft wel een fout, maar ik vroeg me af waarom het niet werkte )

[Gaius]

Remus schreef op maandag 06 februari 2012 @ 19:51:
[...]
Persoonlijk vind ik het altijd wel makkelijker om korte methodes te hebben, dan is het veel makkelijker om te redeneren waar je mee bezig bent en wat er gebeurt. Ook vind ik dat je bij het (re)factoren naar korte methodes vaak ook beter nadenkt over verantwoordelijkheid en scope. Aan de andere kant vind ik dogmatisch korte methodes maken omdat Robert C. Martin zegt dat het moet ook weer onzin .

Eens. De code van Robert C. Martin is een uiterste. Wel heel makkelijk leesbare en eenvoudig ogende code. Maar de korte methods schrijf je niet omdat het moet, het is wat je overhoudt als je methods schrijft die maar één taak uitvoeren.

De code die ik hier heb is weer een andere uiterste. Een switch-case waarbij de code die uitgevoerd moet worden in de cases staat, voorafgegaan door meerdere if-else-constructies en gevolgd door een if-else-constructies die 4 niveaus diep gaat. In een for-each-loop. En dat in één method van 600 regels.

Maar hey, beter die method dan code uit het andere project. Geschreven door goedkope programmeurs uit het oosten, die weten in 50 regels een constructie neer te zetten waar je uren voor nodig hebt om uit te vogelen wat het doet. Waarna je alsnog de klant moet bellen om te vragen of wat er gebeurt wel klopt. Korte tijd geleden nog een change compleet opnieuw geïmplementeerd omdat het zo gebouwd was dat je in de GUI precies moest weten hoe de Stored Procedure uiteindelijk de data ging opvragen in de database.

[RayNbow]

Verwijderd schreef op maandag 06 februari 2012 @ 21:29:

C#:

public class Persoon
{
public string Naam { get; set; }
public string Adres { get; set; }
public string Postcode { get; set; }
public DateTime GeboorteDatum { get; set; }
}

Nou, ik weet wel wat ik liever heb...

Haskell:

data Person = Person { name :: String
                     , address :: String
                     , zipcode :: String
                     , birthday :: DateTime
                     }