[alg] Slechtste programmeervoorbeelden deel 4

[Verwijderd]

.Gertjan. schreef op donderdag 21 april 2011 @ 17:09:
[...]

Als het eendje was dan is het wel weer leuk

[afbeelding]

Maar dan doen ze het ook als je op de WC zit. Dat is een geheel andere situatie!

[brambo123]

Kwam laatst ook wat leuks tegen, op een site van java.
t/m regel 1232 zijn lege regels met sommige regels wat tabs erin.
Daarna pas inhoud van de website waar ook veel lege regels tussen staat.
Totaal van de 1936 regels 370 gevuld
Vraag ik me af hoe ze bij java programmeren

[Gomez12]

brambo123 schreef op donderdag 21 april 2011 @ 23:09:
Kwam laatst ook wat leuks tegen, op een site van java.
t/m regel 1232 zijn lege regels met sommige regels wat tabs erin.
Daarna pas inhoud van de website waar ook veel lege regels tussen staat.
Totaal van de 1936 regels 370 gevuld
Vraag ik me af hoe ze bij java programmeren

Ach, dat is imho (zolang het met mate gebeurd) enkel een persoonlijke voorkeur.
Als ik in een html-template bijv een loopje zet vernaggel ik ook altijd standaard de layout van mijn broncode, ik heb dan altijd minimaal 1 indenting te veel staan.

Zet op je server gzip-compressie aan en die overbodige 1600 regels tellen ook niet echt meer mee voor je dataverkeer..

Ik vind het veelal gruwelijker om te zien in welke indenting bochten (in server-side talen) sommige mensen zich wringen om maar nette html te produceren (maarja ik gooi er dan ook altijd een postprocessor overheen die gewoon alle newlines en dubbele spaties en tabs eruithaalt)

[Dragor]

Gomez12 schreef op donderdag 21 april 2011 @ 23:19:
Ik vind het veelal gruwelijker om te zien in welke indenting bochten (in server-side talen) sommige mensen zich wringen om maar nette html te produceren (maarja ik gooi er dan ook altijd een postprocessor overheen die gewoon alle newlines en dubbele spaties en tabs eruithaalt)

Ah jij bent zo iemand die alle html op 1 regel zet. Altijd handig als je iets in de broncode wil zoeken. Maar gelukkig hebben we daar BeautifulSoup voor

[Caelorum]

Dragor schreef op vrijdag 22 april 2011 @ 08:34:
[...]


Ah jij bent zo iemand die alle html op 1 regel zet. Altijd handig als je iets in de broncode wil zoeken. Maar gelukkig hebben we daar BeautifulSoup voor

^^ kopieer-plak in visual studio. Staat ook alles weer netjes

[Grijze Vos]

brambo123 schreef op donderdag 21 april 2011 @ 23:09:
Kwam laatst ook wat leuks tegen, op een site van java.
t/m regel 1232 zijn lege regels met sommige regels wat tabs erin.
Daarna pas inhoud van de website waar ook veel lege regels tussen staat.
Totaal van de 1936 regels 370 gevuld
Vraag ik me af hoe ze bij java programmeren

Misschien is het stiekem een stuk Whitespace?

[TweakBoy]

Dragor schreef op vrijdag 22 april 2011 @ 08:34:
[...]


Ah jij bent zo iemand die alle html op 1 regel zet. Altijd handig als je iets in de broncode wil zoeken. Maar gelukkig hebben we daar BeautifulSoup voor

Of gewoon debug mode aanhouden wat de postprocessor deactiveert....
Zelf heb ik geen css en js minify aanstaan in development/debug...

[Rutix]

Patriot schreef op donderdag 21 april 2011 @ 12:59:
[...]


Maak die zin eens af, ik viel bijna van m'n stoel zo abrupt als die eindigde.

Hahaha sorry xD Ik was een reply aan het typen maar werd gestoort en heb blijkbaar op de reply button geklikt
Dit wilde ik ongeveer zeggen :
"Ja idd. Want dan moet je de hele tijd kijken hoe een functie nou precies heet omdat je.dan niet intuïtief kan schatten wat een functie naam is omdat het de ene keer Nederlands is en andere keer mix en weer andere keer engels."

[.Gertjan.]

Rutix schreef op zaterdag 23 april 2011 @ 01:42:
[...]


Hahaha sorry xD Ik was een reply aan het typen maar werd gestoort en heb blijkbaar op de reply button geklikt
Dit wilde ik ongeveer zeggen :
"Ja idd. Want dan moet je de hele tijd kijken hoe een functie nou precies heet omdat je.dan niet intuïtief kan schatten wat een functie naam is omdat het de ene keer Nederlands is en andere keer mix en weer andere keer engels."

Is nog mooier als je gebrekkige code-completion hebt (ik kijk naar jou Axapta ). Ben aan het werk in een stukje maatwerk van een andere partner (gelukkig geen collega's), maar die hebben er echt een zooi van gemaakt. In Axapta is het normaal om als partner je werk te prefixen om het te onderscheiden van standaard werk met een 2 of 3 letterige partner code. Nu kom ik geregeld in stukken waar de volgende situaties gemixed zijn (om maar een voorbeeldje te noemen):

• P1_FileId
• P1FileId
• P1File_Id
• FileId
• P2_FileId
• File_Id
• Gebruik van Nederlandse en Engelse termen, soms zelfs in dezelfde variabele-naam Iets als bijvoorbeeld KlantName

P1 is de partnercode van de partner, P2 de code die bij de klant gebruikt wordt voor eigen ontwikkeling. Al deze namen duiden op dezelfde soort informatie en worden in code/tabellen dus wisselend door elkaar gebruikt. Leuk als je dus tegen een tabel aan het werken bent: P1_FileId P1FileId P1File_Id FileId P2_FileId ah hier is het File_Id. Vaak begint Axapta ook pas te klagen nadat je compilet of opslaat en toont vaak per functie alleen de eerste fout, als je die oplost checkt hij pas de rest...

Normaal zou je met code completion een heel eind komen (zeker in VS2010 die ook matcht op delen van de naam), maar de IDE van Axapta stamt nog uit het stenen tijdperk en is behoorlijk beperkt op dat vlak. Moet eerlijk zeggen, iedere keer als ik in dat tegenkom schieten tranen me in de ogen

Ik vraag me dan altijd af hoe de kwaliteit van de code moet zijn. Als je niet eens consistent kunt programmeren zal er in de code vast ook wel een en ander mis zijn. Wil niet zeggen dat ik perfect ontwikkel, maar het maatwerk waar ik nu in werk is echt behoorlijk inconsistent.

Nu is het verband consistentie en kwaliteit dit geval overigens ruim bewezen Kom behoorlijk wat WTF's tegen


[/rage]

[Salandur]

afgelopen maandag en dinsdag bij de clean code training van Robert 'Bob' Martin gezeten, kwam het bovenstaande plaatje natuurlijk ook voorbij. Echt een aanrader die training. Veel nuttige dingetjes geleerd. Nu nog even er voor zorgen dat ik het boek te pakken krijg (want die zat er niet bij) en dat ik alles ook goed toe ga passen!

[Gomez12]

Dragor schreef op vrijdag 22 april 2011 @ 08:34:
[...]
Ah jij bent zo iemand die alle html op 1 regel zet. Altijd handig als je iets in de broncode wil zoeken. Maar gelukkig hebben we daar BeautifulSoup voor

Je begrijp het idee van een postprocessor?
Die kan je uit en aan zetten en staat dus in develop uit en in 1 test omgeving aan en in 1 testomgeving uit ( zodat mensen testen met postprocessor aan, wij hun test-resultaten met en zonder post-processor kunnen bekijken (voor het geval dat er toch iets fout gaat door postprocessor) )

In ons huidige framework kunnen we hem in een live-omgeving voor bepaalde ip-blocken weer uitzetten (of compleet uitzetten)

En tja, wij maken niet iets wat leesbaar moet zijn voor externe developers (alhoewel op aanvraag gaat de postprocessor uit), wij maken iets wat moet functioneren voor de klant.

Maar ik wens jou veel plezier met je debugstatements etc in je productiecode...

[ Voor 4% gewijzigd door Gomez12 op 23-04-2011 13:02 ]

[.Gertjan.]

Salandur schreef op zaterdag 23 april 2011 @ 12:30:
afgelopen maandag en dinsdag bij de clean code training van Robert 'Bob' Martin gezeten, kwam het bovenstaande plaatje natuurlijk ook voorbij. Echt een aanrader die training. Veel nuttige dingetjes geleerd. Nu nog even er voor zorgen dat ik het boek te pakken krijg (want die zat er niet bij) en dat ik alles ook goed toe ga passen!

Vond het boek eigenlijk niet zo heel veel toevoegen. Heb deze pas gelezen (ja, netjes na een paar jaar ontwikkelen pas een dergelijk boek lezen) en voor mij waren het heel veel open deuren die werden ingetrapt

Maar goed, ik had al diverse andere boeken gelezen waaronder code-complete en ben in het verleden behoorlijk wat bezig geweest met uitzoeken en opstellen van code-standards binnen ontwikkel teams. Dus de meeste dingen had ik al eens lang zien komen.

Als je hem wilt bestellen kun je dat heb beste doen bij Play.com of bij Amazon.co.uk die hebben dit soort boeken meestal wel op voorraad en daar zijn ze over het algemeen goedkoper dan in Nederland. Daarnaast betaal je als je via play bestelt geen belasting Beide verzenden overigens gratis (waarbij je voor Amazon.co.uk wel een minimum bedrag moet bestenden, maar dat is vaak niet zo'n punt).

Over open deuren gesproken, ben nu bezig in Head First Design Patterns, best leuk geschreven, maar ook daar kom ik dingen tegen die al vrij bekend zijn. Enige echt vernieuwende is dat ik nu namen bij patterns heb, lees ik zo'n stukje en denk ik aan het einde, ow het heet een decorator pattern

[Gomez12]

.Gertjan. schreef op zondag 24 april 2011 @ 15:49:
[...]
Vond het boek eigenlijk niet zo heel veel toevoegen. Heb deze pas gelezen (ja, netjes na een paar jaar ontwikkelen pas een dergelijk boek lezen) en voor mij waren het heel veel open deuren die werden ingetrapt

Ik moet zeggen, ik moet je complimenteren.

Meeste mensen die zeggen een paar jaar te ontwikkelen alvorens een goed boek te lezen zijn imho nooit boven het zolderkamernivo uitgestegen.

Maar die goede boeken zijn ook geen magie, het zijn hooguit verzamelde best practices. Een best-practice is niet iets wat random verzonnen wordt, het is gewoon iets wat het beste werkt in de praktijk.

Als die boeken dus veelal open deuren zijn dan is het gewoon een teken dat je goed bezig bent. Je hebt de pitfalls waar de meeste programmeurs in vervallen omzeild.
proficiat...

[.Gertjan.]

Gomez12 schreef op zondag 24 april 2011 @ 15:58:
[...]

Ik moet zeggen, ik moet je complimenteren.

Meeste mensen die zeggen een paar jaar te ontwikkelen alvorens een goed boek te lezen zijn imho nooit boven het zolderkamernivo uitgestegen.

Maar die goede boeken zijn ook geen magie, het zijn hooguit verzamelde best practices. Een best-practice is niet iets wat random verzonnen wordt, het is gewoon iets wat het beste werkt in de praktijk.

Als die boeken dus veelal open deuren zijn dan is het gewoon een teken dat je goed bezig bent. Je hebt de pitfalls waar de meeste programmeurs in vervallen omzeild.
proficiat...

Hehe, hoewel je opmerking ook behoorlijk sarcastisch kan zijn bedankt ik je toch voor je compliment. Zo ontzettend perfect voel ik me nou ook niet, maar doe in ieder geval mijn best

Helemaal niets geleerd is natuurlijk een beetje erg hoog gegrepen, en het boek is natuurlijk wel erg nuttig om alles eens op een rijtje te hebben en het ook eens achter elkaar te kunnen lezen, maar veel dingen zijn toch wel behoorlijk vanzelfsprekend en die kom je over het algemeen vrij snel tegen als je ontwikkelt (zeker als je met bovengenoemde zolderkamer figuren zou werken). Als je daarnaast zelf ook streeft naar perfectie kom je vaak al op de best practices uit, want dat is een manier om perfectie na te streven. Vaak liggen die dingen toch wel op 1 lijn met je eigen best practices.

Een aantal voorbeeldjes:

• Geen lange functions: werk altijd heel gestructureerd, als een functie van de hak op de tak springt en 200 regels lang sterf ik meestal een klein beetje van binnen
• Logische benamingen: is wel fijn als je weet wat een var doet
• Single responsibility: ook vrij logisch, vaak begin je wel met een functie die tig dingen tegelijk doet, maar uiteindelijk heb je bepaalde delen ook elders nodig en breek je de functie vanzelf op in meerdere delen die uiteindelijk slechts 1 doel vervullen

Code Complete vond ik, persoonlijk, veel nuttiger omdat daar ook het proces eromheen werd uitgelicht en daar behoorlijk nuttige catch-phrases in stonden. Ik vind ontwikkelen leuk, maar ben nu erg geïnteresseerd in het hele verhaal eromheen. En juist dat verhaal werd in code compleet beschreven.

Wil niet zeggen dat ik perfect begonnen ben, maar was binnen no-time toch wel met de seniors aan het "worstelen", komt gedeeltelijk door het niveau van de seniors en het feit dat ik altijd gelijk wil hebben (men vind dat een irritant trekje, maar daar ben ik het totaal niet mee eens ). Ik vind het leuk om mezelf te ontwikkelen en tot een bepaald niveau te stijgen en ga discussies met seniors niet uit de weg. Daarnaast ben ik behoorlijk nieuwsgierig en lukt het me om "abstract" te denken en afstand te nemen van het probleem en er eens op een andere manier naar te kijken.
Ik denk dat een ontwikkelaar een bepaalde abstracte mindset moet hebben om succesvol te worden, tijdens mijn opleiding heb ik een hoop jongens gezien die dat misten en die gingen vaak hard op hun gezicht. Als je ze exact vertelde wat ze moesten doen kwam er redelijke code uit, maar als ze aan de hand van een, wat vager, Functional Design iets moesten doen klapten ze dicht en kwam er niet altijd meer iets uit. Dat is wel jammer... Maar ik vrees dat die denkwijze niet echt aan te leren valt.

Uiteraard is de kennis ook niet zomaar in mijn schoot geland en heb ik de meeste dingen ook geleerd door uit te zoeken, gewoon eens wat te proberen en door diverse keren op je gezicht te vallen waarbij je vanzelf leert je code netjes op te zetten. Ook is het belangrijk dat je niet bang bent om te leren en ook niet bang bent je code eens helemaal radicaal om te gooien

Wil overigens niet zeggen dat ik nooit in een pitfall gevallen ben hoor, maar ik kruip er meestal uit, klop mijn broek af en ga gewoon weer door. Sommige mensen blijven daar in hangen. Veel mensen zijn bang om bijvoorbeeld drastisch te refactoren en blijven dus ook met hun code in de pitfall hangen.

[Verwijderd]

- Oeps, verkeerde topic. -

[ Voor 80% gewijzigd door Verwijderd op 24-04-2011 16:20 ]

[BarôZZa]

.Gertjan. schreef op zondag 24 april 2011 @ 16:17:
Ik denk dat een ontwikkelaar een bepaalde abstracte mindset moet hebben om succesvol te worden, tijdens mijn opleiding heb ik een hoop jongens gezien die dat misten en die gingen vaak hard op hun gezicht. Als je ze exact vertelde wat ze moesten doen kwam er redelijke code uit, maar als ze aan de hand van een, wat vager, Functional Design iets moesten doen klapten ze dicht en kwam er niet altijd meer iets uit. Dat is wel jammer... Maar ik vrees dat die denkwijze niet echt aan te leren valt.

Grappig, ik had een tijdje terug ongeveer precies hetzelfde getypt (niet hier overigens). Dat heb ik ook heel veel gezien. Het toepassen van eerder geleerde zaken lukt ze meestal prima, maar zelf naar een oplossing toewerken of iets vanuit een ander perspectief bekijken (brrr, de gebruiker, altijd eng ) wordt een heel ander verhaal.

Het er volgens mij ook voor een groot gedeelte aan of je het leuk vindt om je erin te verdiepen en autodidactisch ingesteld bent. De één moet gewoon continu boeken blijven lezen, allerlei zaken leren en kan die vervolgens gemakkelijk toepassen. De ander komt een probleem tegen en zoekt vervolgens gericht naar een oplossing. Beide hebben uiteraard voordelen en nadelen. De autodidact zal bij een geheel nieuwe situatie gemakkelijker kunnen schakelen, maar er waarschijnlijk weer wat langer over doen wanneer het om iets gaat dat de ander al van tevoren heeft bestudeerd.

Op m'n opleidingen zag ik overigens vooral veel lui die echt van de leerstof afhankelijk waren om een probleem op te lossen. Bij abstract of creatief denken klapten er echt heel veel dicht.

[Jan_V]

Salandur schreef op zaterdag 23 april 2011 @ 12:30:
afgelopen maandag en dinsdag bij de clean code training van Robert 'Bob' Martin gezeten, kwam het bovenstaande plaatje natuurlijk ook voorbij. Echt een aanrader die training. Veel nuttige dingetjes geleerd. Nu nog even er voor zorgen dat ik het boek te pakken krijg (want die zat er niet bij) en dat ik alles ook goed toe ga passen!

Geeft hij daar ook trainingen over? Gaaf!
Heb het boek ook gelezen en bevat idd enkele open deuren, maar zoals hier al is gezegd, is het wel handig om dit alles zo mooi op een rijtje te hebben.

[Avalaxy]

Ik vond Clean Code ook erg goed. Welliswaar (zoals iedereen zegt): opendeuren. Echter zijn het wel open deuren waar ik me niet altijd aan hield. Door het lezen van dat boek ben ik veel meer gaan letten op wat ik programmeer, en is m'n code veel netter.

Er worden ook nog een aantal design patterns uitgelegd, en ik vind dat de uitleg die zij geven best nog wel wat toevoegt boven de uitleg die GoF Design Patterns geeft. Laatstgenoemde vind ik vaak toch wat te kort en richt zich net iets teveel op de structuur ipv de real-world application ervan.

Kwam ook nog een leuke denkwijze tegen wbt het leren werken met een nieuwe API: waarom niet gewoon unit tests ervoor schrijven? Dan leer je ook wat de API doet, en heb je gelijk unit tests (mits de API hier niet in voorziet)

[alienfruit]

Ja, leuk unit tests schrijven zolang het maar niet voor de Facebook API is. Sjonguh, wat een bagger is dat zeg! En het werkt nog steeds niet in Opera voor mij

[pkuppens]

Verwijderd schreef op woensdag 13 april 2011 @ 19:07:

C#:

private void doeIets(DataTable table)
{
     int  i = 0;
     foreach(DataRow row in table.Rows)
    {
         switch(i)
         {
              case 0:
                  doe iets;
                  i++;
                  break;
              ....
              default:
                  doe het standaard ding;
                  break;
         }
    }
}

Problem "solved".

Je kan in dit geval het beste gewoon een for-lus gebruiken

Beantwoord jij ook retorische vragen?

Maar ik durf er geen gif op in te nemen dat ik zoiets niet zelf ook wel eens geschreven heb. Wel snel fiksen daarna.

[Janoz]

brambo123 schreef op donderdag 21 april 2011 @ 23:09:
Kwam laatst ook wat leuks tegen, op een site van java.
t/m regel 1232 zijn lege regels met sommige regels wat tabs erin.
Daarna pas inhoud van de website waar ook veel lege regels tussen staat.
Totaal van de 1936 regels 370 gevuld
Vraag ik me af hoe ze bij java programmeren

Ik vermoed dat je daar aan het kijken was naar het resultaat van een JSP pagina. Daarbij wordt veel van de logica beschreven middels tags. Die tags worden afgehandeld, maar de whitespace blijft wel staan. Die specifieke pagina zal dan wel beginnen met 1232 regels aan jsp code (of met een stuk minder regels jsp code waarin wel enkele lusjes zitten. Vergelijk het maar met een php script waarbij je elk statement als <?php statement; ?> schrijft.

[PiepPiep]

code:

objectUitObscureClass.Volgnummer = Volgnummer;
objectUitObscureClass.Opslaan();
Volgnummer = objectUitObscureClass.Volgnummer;

1e regel bevat Volgnummer bijvoorbeeld 14, 3e regel is het opeens opgehoogd naar 15
Erg handig als functies ook nog andere dingen doen dan wat de naam zegt.

[Matis]

Janoz schreef op dinsdag 26 april 2011 @ 10:41:
Ik vermoed dat je daar aan het kijken was naar het resultaat van een JSP pagina. Daarbij wordt veel van de logica beschreven middels tags. Die tags worden afgehandeld, maar de whitespace blijft wel staan. Die specifieke pagina zal dan wel beginnen met 1232 regels aan jsp code (of met een stuk minder regels jsp code waarin wel enkele lusjes zitten. Vergelijk het maar met een php script waarbij je elk statement als <?php statement; ?> schrijft.

HTML broncode kan me jeuken. Mensen die er in geïnteresseerd zijn hebben wel een plugin om de broncode netjes weer te geven (Firebug, Chrome etc.). De rest weet niet eens dat er broncode achter een webpagina schuilgaat.

De broncode in PHP etc. probeer ik wel netjes qua indenting te houden.
PHP-only bestanden krijgen van mij niet eens een ?>.

[.Gertjan.]

PiepPiep schreef op dinsdag 26 april 2011 @ 11:39:
Erg handig als functies ook nog andere dingen doen dan wat de naam zegt.

Inderdaad, dat is BLOEDIRRITANT. Zit me net ook te verbazen over een stukje Axapta maatwerk waarin een bepaalde functie allerlei dingen doet die je niet kunt herleiden aan de naam. Een functie met de naam IdentifySomething identificeert het niet alleen, maar pompt meteen wat data in de database. Daarbij worden zelfs nummers en gegevens veranderd van onderliggende waardes.

Moet nu eerst de hele flow uitpluizen en kijken wat er waar gebeurt en dan stukjes code isoleren naar eigen functies. Grrrr, een maatwerk uitbreiding op verrot maatwerk van een ander is niet tof

[Rutix]

.Gertjan. schreef op dinsdag 26 april 2011 @ 12:07:
[...]


Inderdaad, dat is BLOEDIRRITANT. Zit me net ook te verbazen over een stukje Axapta maatwerk waarin een bepaalde functie allerlei dingen doet die je niet kunt herleiden aan de naam. Een functie met de naam IdentifySomething identificeert het niet alleen, maar pompt meteen wat data in de database. Daarbij worden zelfs nummers en gegevens veranderd van onderliggende waardes.

Moet nu eerst de hele flow uitpluizen en kijken wat er waar gebeurt en dan stukjes code isoleren naar eigen functies. Grrrr, een maatwerk uitbreiding op verrot maatwerk van een ander is niet tof

Dat is zeker irritant. En natuurlijk staat daar ook niks over in de documentatie ? Lekker klusje altijd... functies debuggen omdat documentatie niet compleet is of omdat de functie naam nergens op slaat. Dat is echt pure tijd verspilling, als ze het nou het meteen goed hadden gedaan dan was je die tijd ook niet kwijt geweest aan het debuggen.

[.Gertjan.]

Rutix schreef op dinsdag 26 april 2011 @ 14:04:
[...]


Dat is zeker irritant. En natuurlijk staat daar ook niks over in de documentatie ? Lekker klusje altijd... functies debuggen omdat documentatie niet compleet is of omdat de functie naam nergens op slaat. Dat is echt pure tijd verspilling, als ze het nou het meteen goed hadden gedaan dan was je die tijd ook niet kwijt geweest aan het debuggen.

Documentatie? Wasda? Er staat voor dit project zo goed als niets gedocumenteerd. Normaliter kun je als ontwikkelaar dan terugvallen op de code, maar dat is ook een ontiegelijke ellende. Ik mag nu gelukkig iets nieuws ernaast zetten, maar dat moet wel aan het bestaande gekoppeld worden, die koppeling is nu al een hoofdpijnproject geworden, en ben pas een paar dagen bezig

#hadikmaareenvakgeleerd
#waarombeniknaarAXovergestapt

[ Voor 3% gewijzigd door .Gertjan. op 26-04-2011 14:16 ]

[Tsunami]

.Gertjan. schreef op dinsdag 26 april 2011 @ 14:16:
Normaliter kun je als ontwikkelaar dan terugvallen op de code, maar dat is ook een ontiegelijke ellende.

Volgens mij is documentatie juist bedoeld om op terug te vallen als de code een ellende is, niet andersom

[.Gertjan.]

Tsunami schreef op dinsdag 26 april 2011 @ 14:19:
[...]

Volgens mij is documentatie juist bedoeld om op terug te vallen als de code een ellende is, niet andersom

Met een technisch ontwerp heb je over het algemeen een high-level overview over de oplossing die gemaakt is. Maar als dat ontbreekt moet je alles uit de code halen, en geloof me met tig subclasses en tabellen wordt dat vrij lastig. Zeker als de schrijfstijl van de ontwikkelaars om te huilen is.

Zonder algemeen technisch ontwerp weet je vaak niet waar je moet beginnen.
Daarnaast is het veel te mooi weer buiten om je te moeten opwinden over bagger van een andere ontwikkelaar
Gelukkig kan ik over een half uurtje lekker naar huis. Eerst 1,5 uur in de auto bakken, maar daarna lekker in het zonnetje zitten
Ook wel benieuwd of de A50 nu eens op schiet, volgens mij is tussen de A12 en Wageningen de A50 helemaal open en weer 120

[IStealYourGun]

Tsunami schreef op dinsdag 26 april 2011 @ 14:19:
[...]

Volgens mij is documentatie juist bedoeld om op terug te vallen als de code een ellende is, niet andersom

Documentatie is er om om te voorkomen dat je niet moet terugvallen op code.
Als je code een ellende is, dan kan je ook geen degelijke documentatie schrijven.

[MBV]

[Verwijderd]

Ik huiver echt voor het soort programmeurs dat mijn opleiding gaat voortbrengen, de volgende benamingen van variabelen en functies zijn dus echt gebruikt...

C:

void TijdAlarmInstellen (void);

void StandaardWaarde (void);

time_t DeTijd, ALARM; 

LedsAansturen(DeTijd);

Het staat niet zo in de code, maar dit is een voorbeeld van wat er te verwachten is...en verder zijn er gedrochten van functies zoals dit:

C:

void TijdAlarmInstellen (void)  // Functie om de alarm tijd in te stellen
{

    AlarmInstellen = 0;
    PORTC = PORTC & 0xC0;
    PORTA = PORTA & 0xC0;
    while(!(PINB & SCHAKELAAR_ALARMINSTELLEN))
    {
        LedsAansturen(ALARM);
        if (!(PIND & KNOP_HOUR))
        {
            ALARM.hour++;
            if (ALARM.hour > 23)
                ALARM.hour = 0x00;
            do                              
            {
                if (!(PIND & KNOP_MIN))
                {
                    ALARM.min = 0x00;
                    ALARM.hour = 0x00;
                }
                do                              
                {
                } while (!(PIND & KNOP_MIN));
            } while (!(PIND & KNOP_HOUR));
        }

        if (!(PIND & KNOP_MIN))
        {
            ALARM.min++;
            if (ALARM.min > 59)
                ALARM.min = 0x00;
            do                              
            {
                if (!(PIND & KNOP_HOUR))
                {
                    ALARM.min = 0x00;
                    ALARM.hour = 0x00;
                }
                do                              
                {
                } while (!(PIND & KNOP_HOUR));
            } while (!(PIND & KNOP_MIN));
        }       
    }
}

Maar gelukkig wordt ons ook aangeleerd goede variabel namen te kiezen!

Wanneer er bijvoorbeeld een integer wordt gebruikt als variabele, moet de naam er zo uitzien:

iGetal

Met deze benaming is het duidelijk de de variabele in interger is, en bijvoorbeeld geen karakter!

Ik ben zó blij dat ik zelf nog wel een beetje probeer in te lezen op best-practices in C/C++...

[Styxxy]

Hungarian notation, maar een beetje kort de bocht uitgelegd... Op zich nog geen slechte naamgeving (mits consequent en logisch gebruikt wordt).

[PiepPiep]

Hungarian notation is een goede notatie als de compiler geen type checking doet.
Wanneer de compiler dat wel doet geeft die errors of warnings als het casten niet veilig is en is dus die toevoeging van i onnodig.
Wanneer de compiler goede type checking doet en de IDE goede autocompletion heeft vind ik zelf het handiger om niet die dingen als i er voor te zetten zodat je sneller je variabele kan vinden wanneer je niet het precieze type weet. Begon de naam nou met i van integer, l van long of s van short?

[Paul]

Verwijderd schreef op woensdag 27 april 2011 @ 23:18:
Het staat niet zo in de code, maar dit is een voorbeeld van wat er te verwachten is...en verder zijn er gedrochten van functies zoals dit:

Just curious, maar wat is het probleem met die code? Enige wat ik zie is schakelaar <> knop, vrijwel al het andere wordt je opgelegd door de libs van (bijvoorbeeld) Atmel

[Matis]

Tsunami schreef op dinsdag 26 april 2011 @ 14:19:
Volgens mij is documentatie juist bedoeld om op terug te vallen als de code een ellende is, niet andersom

Goed code heeft geen commentaar nodig. Dus in dat opzicht heb je gelijk

[Tsunami]

Mwa, daar kan ik het ook weer niet mee eens zijn, code wordt vaker gelezen dan geschreven, dus als jij met één regel commentaar kan uitleggen wat de komende 50 regels aan code doen, scheelt dat voor andere mensen die code doorspitten.

[Matis]

Tsunami schreef op donderdag 28 april 2011 @ 09:29:
Mwa, daar kan ik het ook weer niet mee eens zijn, code wordt vaker gelezen dan geschreven, dus als jij met één regel commentaar kan uitleggen wat de komende 50 regels aan code doen, scheelt dat voor andere mensen die code doorspitten.

Ja, maar met SLOC per function van 50, is het ook afvragen of een functie wel goed (genoeg) is.
Dat neemt natuurlijk niet weg, dat je met een regel goed commentaar alsnog sneller klaar bent met lezen dan 10,25 of 50 SLOCs

[NC83]

PiepPiep schreef op donderdag 28 april 2011 @ 08:40:
Hungarian notation is een goede notatie als de compiler geen type checking doet.
Wanneer de compiler dat wel doet geeft die errors of warnings als het casten niet veilig is en is dus die toevoeging van i onnodig.
Wanneer de compiler goede type checking doet en de IDE goede autocompletion heeft vind ik zelf het handiger om niet die dingen als i er voor te zetten zodat je sneller je variabele kan vinden wanneer je niet het precieze type weet. Begon de naam nou met i van integer, l van long of s van short?

Je zou nooit Hungarian notation moeten gebruiken, ten eerste is dat veelste intensief om bij te houden waneer een variable van type verandert en leidt tot fouten hierdoor. Ten tweede is het veel beter om je variablen namen zo te kiezen dat een andere developer kan gokken welk type die variable heeft.

Tsunami schreef op donderdag 28 april 2011 @ 09:29:
Mwa, daar kan ik het ook weer niet mee eens zijn, code wordt vaker gelezen dan geschreven, dus als jij met één regel commentaar kan uitleggen wat de komende 50 regels aan code doen, scheelt dat voor andere mensen die code doorspitten.

Misschien zou je die code eens moeten refactoren dan en kijken of je het niet kan uitdrukken op een makkleijker manier die geen commentaar vereist. Geen comments is altijd beter dan ze wel hebben, comments kunnen namelijk rotten.

[Andre-85]

Matis schreef op donderdag 28 april 2011 @ 09:25:
[...]

Goed code heeft geen commentaar nodig. Dus in dat opzicht heb je gelijk

Commentaar dat code uitlegd kan een smell zijn, maar commentaar dat aangeeft waarom een bepaalde keuze is gemaakt voegt weldegelijk wat toe. Waarom een keuze gemaakt is, is vaak lastig of niet terug te lezen uit een stuk code.

[MBV]

C++:

if (something)
{
  //copy/paste from X.Y(), had to add a check to prevent a crash
  //[snip]500 regels code[/snip]
}
else if (somethingElse())
{
  //assert(EFalse); //disabled, occurs too often
  //printf("This shouldn't happen\n");
}
else 
{
  //to make TICS happy
}

Zoiets?

En functies van 50 regels ben ik kort gaan vinden

[ Voor 36% gewijzigd door MBV op 28-04-2011 13:02 ]

[Noxious]

Hoe slecht is mijn helper class? Ik heb vernomen dat 'ie ranzig is

C#:

namespace TSMServiceHelper
{
    static class TsmLogic
    {
        public static double GetUnixTime()
        {
            var ts = DateTime.UtcNow - new DateTime(1970, 1, 1, 0, 0, 0);
            return Math.Round(ts.TotalSeconds);
        }
        public static string StripSlashes(string input)
        {
            return System.Text.RegularExpressions.Regex.Replace(input, @"(\\)([\000\010\011\012\015\032\042\047\134\140])", "$2");
        }
    }
}

[Makkelijk]

PHP:

if( $aLocation['Latitude'] != "0" && $aLocation['Longitude'] != "0" ) {
    
    //Locatie gevonden
    echo json_encode(array(
        'city'=>$aLocation['City'],
        'lat'=>$aLocation['Latitude'],
        'lng'=>$aLocation['Longitude']
    ));
}
else {

    // Als het om wat voor een reden dan ook niet lukt,
    // dan gewoon lekker Amsterdam laten zien
    echo json_encode(array(
        'city'=>'...',
        'lat'=>"52.37",
        'lng'=>"4.89",
    ));
}

// Als het om wat voor een reden dan ook niet lukt, dan gewoon lekker Amsterdam laten zien

En het is niet eens een Nederlandstalige website

[ Voor 9% gewijzigd door Makkelijk op 28-04-2011 14:03 ]

[Patriot]

NC83 schreef op donderdag 28 april 2011 @ 11:33:
[...]

Je zou nooit Hungarian notation moeten gebruiken, ten eerste is dat veelste intensief om bij te houden waneer een variable van type verandert en leidt tot fouten hierdoor. Ten tweede is het veel beter om je variablen namen zo te kiezen dat een andere developer kan gokken welk type die variable heeft.

Mja, het wordt gewoon misbruikt. Wat de hungarian notation nu is, is niet zoals hij bedacht is. Er is iemand die dat veel beter uit kan leggen dan ik, dat is Joel Spolsky. Het stuk over hungarian notation begint aan het einde, maar het hele stuk is zeer interessant.

Waar het op neerkomt is dat je hungarian notation wilt gebruiken om het soort variabele aan te geven dus bijv. 'xPlayer1' voor een x-coördinaat, niet 'iPlayer1X'. Dat het een x-coördinaat is maakt duidelijk dat er een getal in zit, en wat voor type getal kan een goede IDE je wel vertellen.

[PrisonerOfPain]

Patriot schreef op donderdag 28 april 2011 @ 14:17:
Waar het op neerkomt is dat je hungarian notation wilt gebruiken om het soort variabele aan te geven dus bijv. 'xPlayer1' voor een x-coördinaat, niet 'iPlayer1X'. Dat het een x-coördinaat is maakt duidelijk dat er een getal in zit, en wat voor type getal kan een goede IDE je wel vertellen.

Namen van variabele moeten gewoon omschrijven wat de semantische waarde van de data is, onafhankelijk van het gemiep over notatie en leesbaarheid. Als iemand daar zo nodig een 'i' neer moet zetten, prima. Niet? Ook prima.

[kenneth]

Zo kan je alle guidelines wel in de prullenbak gooien.

[OkkE]

Patriot schreef op donderdag 28 april 2011 @ 14:17:
Er is iemand die dat veel beter uit kan leggen dan ik, dat is Joel Spolsky.

Net even een stukje gelezen, vind het best wel een interessante voorstel / idee.

Simpel PHP voorbeeldje

PHP:

$usName = $_GET['name']; // UnSafe string
$sName = htmlentities($_GET['name']); // Safe string
print $usName; // NOT OK
print htmlentities($usName); // OK
print $sName; // OK

[PrisonerOfPain]

kenneth schreef op donderdag 28 april 2011 @ 14:56:
Zo kan je alle guidelines wel in de prullenbak gooien.

Prima. Al dat gehuil over waar de accolades moeten staan, dat er geen underscores in variabele namen zitten en dat er een spatie tussen de functie-naam en de open-bracket staat het zal m'n reet roesten. Wanneer het "onleesbaar" is als het niet aan die regels voldoet ga je maar lekker ergens anders de neuroot uithangen. Er is een regel die je aan moet houden als het op code-guidelines aankomt en dat is "when in rome do as the romans do". Simpel.

[kenneth]

Onze guide bestaat dan ook voor 90% uit opmerkingen als "blijf met je poten van de standaardinstellingen af"

[Avalaxy]

PrisonerOfPain schreef op donderdag 28 april 2011 @ 15:04:
[...]

Prima. Al dat gehuil over waar de accolades moeten staan, dat er geen underscores in variabele namen zitten en dat er een spatie tussen de functie-naam en de open-bracket staat het zal m'n reet roesten. Wanneer het "onleesbaar" is als het niet aan die regels voldoet ga je maar lekker ergens anders de neuroot uithangen. Er is een regel die je aan moet houden als het op code-guidelines aankomt en dat is "when in rome do as the romans do". Simpel.

Dat is waar het verschil tussen een vakman en een doorsnee programmeur zit.

[GateKeaper]

Avalaxy schreef op donderdag 28 april 2011 @ 15:33:
[...]
Dat is waar het verschil tussen een vakman en een doorsnee programmeur zit.

Is het dan de vakman die huilt indien iemand zich niet aan zijn "standaarden" houdt? Of is het de vakman die de code ook kan lezen wanneer de accolades niet op de plaatst staan waar ze "normaal" staan?

[Avalaxy]

GateKeaper schreef op donderdag 28 april 2011 @ 15:51:
[...]

Is het dan de vakman die huilt indien iemand zich niet aan zijn "standaarden" houdt? Of is het de vakman die de code ook kan lezen wanneer de accolades niet op de plaatst staan waar ze "normaal" staan?

Ik neem aan dat het niet de standaarden van 1 persoon zijn maar dat die gewoon binnen het bedrijf zijn vastgelegd. Tuurlijk kan een vakman het ook lezen wanneer de code een rotzooi is, maar dat is geen argument om alle leesbaarheid en consistentie maar gelijk overboord te gooien. Dat is net als dat ik deze post bomvol spelfouten zou zetten "omdat jullie toch wel begrijpen wat ik bedoel".

[PrisonerOfPain]

Avalaxy schreef op donderdag 28 april 2011 @ 15:53:
maar dat is geen argument om alle leesbaarheid en consistentie maar gelijk overboord te gooien.

Dat was niet hoe ik het verwoorde en aanraadde.

[Avalaxy]

PrisonerOfPain schreef op donderdag 28 april 2011 @ 16:00:
[...]

Dat was niet hoe ik het verwoorde en aanraadde.

Dat klopt, maar uit je post kon ik wel opmaken dat je je kennelijk niet altijd aan de code conventies houdt (anders zou er ook geen gehuil zijn), ergo; je vindt ze niet al te belangrijk. Correct? Het hele punt van code conventies is echter juist dat iedereen zich er aan houdt.

[GateKeaper]

Ik ben het er natuurlijk wel mee eens dat je bepaalde richtlijnen hebt, maar laat dit richtlijnen zijn.

Zo is het bijvoorbeeld wel zo handig om locale variabelen met kleine letter te laten beginnen, functies / methodes met een hoofdletter en (private) variabelen in een grotere scope (class) te laten beginnen met een underscore.

Maar je kan er ook over gaan discussiëren om de accolades nu direct na de functie / methode naam te zetten of op een nieuwe regel. Bij dat soort puntjes heb ik zoiets van, tjah... doe wat je leuk vindt.

[PrisonerOfPain]

Avalaxy schreef op donderdag 28 april 2011 @ 16:05:
[...]


Dat klopt, maar uit je post kon ik wel opmaken dat je je kennelijk niet altijd aan de code conventies houdt (anders zou er ook geen gehuil zijn), ergo; je vindt ze niet al te belangrijk. Correct? Het hele punt van code conventies is echter juist dat iedereen zich er aan houdt.

Dan interpreteer jij de uitspraak "when in rome do as the romans do" compleet anders dan wat 'ie betekend . Mijn punt ging over de discussies die altijd oplaaien als het over code-conventies gaat. De "BSD-style vs one-true-brace style" of de "hungarian vs geen hungarian" counter-productieve rotzooi die op het internet rondslingert en waar boeken (Code Complete, geen fan) over volgeschreven zijn.

[FragFrog]

OkkE schreef op donderdag 28 april 2011 @ 14:56:
Simpel PHP voorbeeldje
$sName = htmlentities($_GET['name']); // Safe string

Safe waarvoor? Om weer te geven op een website, prima. Maar ook om zo maar in een DB te stoppen zonder escaping? Dat lijkt me juist weer niet.

Ergo, je geeft in een enkel voorbeeld al aan waarom ook een dergelijke methode niet waterdicht is

PrisonerOfPain schreef op donderdag 28 april 2011 @ 15:04:
Er is een regel die je aan moet houden als het op code-guidelines aankomt en dat is "when in rome do as the romans do". Simpel.

gewoon de guidelines gebruiken die gelden op het project (danwel bedrijf) waar je mee werkt. Die hele discussie over waar je brackets ed moet plaatsen, of over hoeveel whitespace je moet gebruiken (is een tab nu 2, 4, 8 of anders spaties?) etc is vrij zinloos: wat je ook doet, als je het uniform doet is het beter dan de alternatieven.

[ Voor 40% gewijzigd door FragFrog op 28-04-2011 16:17 ]

[Janoz]

Maar de opmerking 'when in rome do as the romans do' past dan ook niet echt bij de rest van je post. Die lijkt namelijk "Ik trek me weinig van codeconventies aan" verkondigen. Terwijl je volgens mij eerder bedoeld "Ik ga mijn tijd niet verspillen aan discussies over codeconventies, ik gebruik gewoon wat er geldt".

[Avalaxy]

PrisonerOfPain schreef op donderdag 28 april 2011 @ 16:13:
[...]

Dan interpreteer jij de uitspraak "when in rome do as the romans do" compleet anders dan wat 'ie betekend . Mijn punt ging over de discussies die altijd oplaaien als het over code-conventies gaat. De "BSD-style vs one-true-brace style" of de "hungarian vs geen hungarian" counter-productieve rotzooi die op het internet rondslingert en waar boeken (Code Complete, geen fan) over volgeschreven zijn.

Ah, alright. Dan heb ik je inderdaad verkeerd begrepen.

Wat betreft de discussies, tja... Ik denk niet dat het verkeerd is om je er een beetje mee bezig te houden, voor een hoop standpunten zijn natuurlijk gewoon rationele argumenten. Of je uiteindelijk rationeel de beste keuze maakt of niet; zolang je in ieder geval maar een standaard hebt. Daar haakte mijn initiële punt op in; een vakman zorgt dat hij consistent is in zijn programmeerstijl.

Edit; eigenlijk dus ook al wat Janoz en FragFrog zeggen.

[PrisonerOfPain]

Janoz schreef op donderdag 28 april 2011 @ 16:16:
Maar de opmerking 'when in rome do as the romans do' past dan ook niet echt bij de rest van je post. Die lijkt namelijk "Ik trek me weinig van codeconventies aan" verkondigen. Terwijl je volgens mij eerder bedoeld "Ik ga mijn tijd niet verspillen aan discussies over codeconventies, ik gebruik gewoon wat er geldt".

Precies.

quote: http://www.phrases.org.uk...-do-as-the-romans-do.html

It is polite, and possibly also advantageous, to abide by the customs of a society when one is a visitor.

Ergo, ik pas me aan aan de code-standaard van het project waar ik aan werk. Simpel.

[Davio]

Mjah, ik heb Hungarian altijd wel dubieus gevonden, zelfs met de oorpsronkelijke bedoeling.

Zo'n korte prefix is leuk als je alles helemaal uit moet typen, maar met een degelijke intellisense heb je zo wat je nodig hebt. Dan moet je nog wel uitkijken dat je geen variabelen krijgt metHeleLangeEnOnleesbareNamenZoalsDit, want dat is ook vervelend.

Daarbij kun je je code zo netjes formatten als maar kan volgens de huidige hypes, maar als het niet werkt (zoals de klant het wil) heb je alsnog een probleem.

[Janoz]

FragFrog schreef op donderdag 28 april 2011 @ 16:15:
[...]

Safe waarvoor? Om weer te geven op een website, prima. Maar ook om zo maar in een DB te stoppen zonder escaping? Dat lijkt me juist weer niet.

Ergo, je geeft in een enkel voorbeeld al aan waarom ook een dergelijke methode niet waterdicht is

Safe is dan ook een onzin prefix aangezien save alleen geldt voor een bepaalde context. Prefixen als unsafe, htmlsave, mysqlsave zouden nuttiger zijn, maar uiteindelijk is het handiger om standaard aan te houden dat je je variabelen pas omzet op de plek waar je ze daadwerkelijk nodig hebt. Dat is immers pas de plek waar je zeker weet op welke manier ze gebruikt gaan worden.

[OkkE]

FragFrog schreef op donderdag 28 april 2011 @ 16:15:
Safe waarvoor? Om weer te geven op een website, prima. Maar ook om zo maar in een DB te stoppen zonder escaping? Dat lijkt me juist weer niet.

Ergo, je geeft in een enkel voorbeeld al aan waarom ook een dergelijke methode niet waterdicht is

Safe voor het printen in een HTML website in dit geval inderdaad. Ik zal het ook zelf niet gaan gebruiken, en waterdicht is mijn voorbeeld niet, maar het is een interessant voorstel. Zoals ook het wat abstractere voorbeeld uit het artikel.

[Patriot]

FragFrog schreef op donderdag 28 april 2011 @ 16:15:
[...]

Safe waarvoor? Om weer te geven op een website, prima. Maar ook om zo maar in een DB te stoppen zonder escaping? Dat lijkt me juist weer niet.

Ergo, je geeft in een enkel voorbeeld al aan waarom ook een dergelijke methode niet waterdicht is

Om een verhitte discussie voor te gaan: Je hebt gelijk. Maar.. er wordt in het artikel waar Joel het voorstelt eigenlijk van uit gegaan dat je dingen in de database stopt op een manier waar het geen probleem is dat het voor HTML 'unsafe' is. Dus eigenlijk veranderde je de situatie waarin je zo'n conventie moet gebruiken en dat is voor veel conventies problematisch.

EDIT: Met andere woorden: Het is waterdicht (mits volledig correct toegepast) voor HTML veiligheid maar überhaupt niet bedoeld voor databases.

[ Voor 11% gewijzigd door Patriot op 28-04-2011 18:18 ]

[CodeCaster]

Waarom moesten we identifiers ook alweer hashen?

Ik kwam net via een of andere affiliate link (je moet blogs die je veel bezoekt toch sponsoren door te klikken hè) op een profielensite. Prima, maar niet wat ik zocht, dus ik klikte 'm bijna alweer weg tot een toch wel erg bijzondere random foto (don't ask) m'n aandacht trok. Ik klikte erop en kwam op een profiel-preview-pagina met daarop de foto in het klein. Erop klikken leidde me naar het inlogscherm, evenals de knoppen "Vorige" en "Volgende" onder de foto.

Dat vraagt om kijken waar de grenzen liggen, dus ik bekeek de URL van de foto. Ja hoor. http://www.foo.bar/{profielnaam}/{foto-ID}/{X-resolutie}. Eerst maar eens terug naar de vorige pagina. Ja, de "Volgende"-knop linkte naar een foto-pagina met een ID van één hoger, en "Vorige" naar één lager.

Als ik die ID's in de directe URL naar de foto zette, werkte het en kreeg ik de andere foto's te zien zonder in te loggen. En dan nog van die rottige resolutie af... Ja hoor, zonder de resolutie-switch achteraan de URL kreeg ik de full-size foto's ook nog eens te zien.

Zo jammer hè.

Hoe ik het op zou lossen: de random op de frontpage getoonde profielnamen in een sessievariabele zetten, en zo de overige profielen ontoegankelijk maken voor niet-ingelogde gebruikers. Dus iets als:

PHP:

if (!$loggedID && !in_array($_SESSION['ViewableProfiles'], $currentProfile)) 
  header("Location: /loginplx");.

Vervolgens de combinatie foto-ID + resolutie hashen voor de bestandsnaam van de foto, en deze hash opslaan in de foto-tabel:

code:

userID | fotonummer (1, 2, 3...) | resolutie | hash

Safer, want een stuk minder makkelijk te gokken wat de URL's naar de foto's zijn.

[ Voor 22% gewijzigd door CodeCaster op 28-04-2011 18:48 ]

[Alex)]

Of zorgen dat de requests door een filter/HttpModule worden gehaald die een 403 teruggeeft wanneer de user geen rechten heeft. Dat is netter imo.

[CodeCaster]

Natuurlijk, maar met veel, datavretende, statische content is een lichte http-daemon natuurlijk fijner, omdat dat resources scheelt en sneller geserveerd wordt. Dus kun je niet controleren of iemand rechten heeft wanneer hij de bestandsnaam weet, dus kun je die beter obfuscaten. Wel een vorm van security through obscurity, maar als iemand requests wil bruteforcen met random hashes kun je daar weer andere maatregelen tegen treffen zoals een netwerkapparaat of stuk software die dat soort aanvallen tegenhoudet.

[ Voor 52% gewijzigd door CodeCaster op 28-04-2011 21:25 ]

[YopY]

OkkE schreef op donderdag 28 april 2011 @ 14:56:
[...]

Net even een stukje gelezen, vind het best wel een interessante voorstel / idee.

Simpel PHP voorbeeldje

PHP:

$usName = $_GET['name']; // UnSafe string
$sName = htmlentities($_GET['name']); // Safe string
print $usName; // NOT OK
print htmlentities($usName); // OK
print $sName; // OK

Alleen heeft het totaal geen waarde als je dit niet op een of andere manier kunt controleren. Ik bedoel, niemand die me tegenhoudt om $usName = $_GET['name'] te doen.

Het lijkt me eerder symptoombestrijding dan een oplossing. Sowieso, als je je zaakjes een beetje op orde hebt (lees: je gebruikt een professionele library / framework / zeg het maar), maakt het hele 'safe' / 'unsafe' verhaal geen zak meer uit - door prepared statements worden je queries automagisch 'veilig', en door een beetje een nozele templating engine wordt je output automagisch 'veilig'. En in je code zelf maakt het al helemaal geen fluit uit (tenzij je eval gebruikt, maar eval = evil), het zal PHP worst zijn als er quotes of SQL in de $_GET staan.

GateKeaper schreef op donderdag 28 april 2011 @ 15:51:
Is het dan de vakman die huilt indien iemand zich niet aan zijn "standaarden" houdt? Of is het de vakman die de code ook kan lezen wanneer de accolades niet op de plaatst staan waar ze "normaal" staan?

Het is de vakman die huilt als hij, doordat iemand een afwijkende codestandaard erop nahoudt, hij meer zijn best moet doen om de code te begrijpen. 4l5 1k 1n33n5 in h5xx0r b3g1n t3 7yp3n m0e7 j3 00k 2 k33r l3z3n.

Het is geen gebrek aan skillz, maar pure luiheid. En een luie programmeur is een goeie programmeur, .

Safer, want een stuk minder makkelijk te gokken wat de URL's naar de foto's zijn.

Nog safer, als safeheid je doel is: gewoon geen URLs naar foto's gebruiken, maar alle foto's via een php script (of wat dan ook) serveren die je login controleert als je iets probeert te bekijken.

Nog saferder: foto's helemaal niet uploaden, .

En het moet (denk ik) ook mogelijk zijn om een lightweight sessiecontrole te doen bij requests naar statische content. Sessies zijn onderdeel van Apache, dus logischerwijs moet het mogelijk zijn om een check te doen (al dan niet via een Apache module / plugin of zelfs via .htaccess) op een sessiekey.

[RobIII]

Sowieso: Alle input hou je gewoon "raw" in een variabele (dus zoals je 'm ontvangen hebt*) IMHO. Pas op 't moment dat je er iets mee gaat doen gebruik je de juiste functies waar van toepassing:

PHP:

$name = $_GET['name'];

$name = $name . 'III';

db.insert('insert into `users` values (`username`) value (%name)', array('name'=>$name));
db.execute("insert into `users` values (`username`) value ('" . realescapeding($name) . "')");
echo 'Hello ' . htmlentities($name) . '!';

Doe je dit:

PHP:

$name = htmlentities($_GET['name']);
//of:
$name = realescapeding($_GET['name']);

Dan moet je op alle andere plekken waar je $name gebruikt (als het de DB in gaat, als het ge-output wordt in HTML, als er een PDF gebakken wordt, you_name_it) weer gaan zitten verzinnen of je nou moet unescapen, escapen of niet_aan_komen en welke variant (slashes, html, quotes, ansi color codes, RTF, ...).

PHP:

$name = $name . 'III'; //Moest ik hier nou eerst nog un-escapen ofzo????
db.insert('insert into `users` values (`username`) value (%name)', array('name'=>$name)); //Moest ik $name eerst nog ontdoen van HTML entities?
db.execute("insert into `users` values (`username`) value ('" . realescapeding($name) . "')");  //Was $name nou al voorzien van SQL escape sequences?
echo 'Hello ' . htmlentities($name) . '!'; //Was $name nou al voorzien van entities?

* edit: Of uit de DB gehaald hebt of van schijf gelezen hebt of...

[ Voor 21% gewijzigd door RobIII op 28-04-2011 22:48 ]

[Patriot]

YopY schreef op donderdag 28 april 2011 @ 22:05:
[...]


Alleen heeft het totaal geen waarde als je dit niet op een of andere manier kunt controleren. Ik bedoel, niemand die me tegenhoudt om $usName = $_GET['name'] te doen.

Het lijkt me eerder symptoombestrijding dan een oplossing. Sowieso, als je je zaakjes een beetje op orde hebt (lees: je gebruikt een professionele library / framework / zeg het maar), maakt het hele 'safe' / 'unsafe' verhaal geen zak meer uit - door prepared statements worden je queries automagisch 'veilig', en door een beetje een nozele templating engine wordt je output automagisch 'veilig'. En in je code zelf maakt het al helemaal geen fluit uit (tenzij je eval gebruikt, maar eval = evil), het zal PHP worst zijn als er quotes of SQL in de $_GET staan.

Heb je het artikel naar aanleiding waarvan dat stukje code is geschreven überhaupt gelezen? Daarin wordt piekfijn uitgelegd dat het gaat om A) het snel en automatisch kunnen spotten van 'foute' code, en over HTML output van user input veilig maken.

Ik ben verder ook benieuwd welke template engine jij gebruikt die kan zien welke variabelen wel veilig zijn en welke niet.

EDIT:

RobIII schreef op donderdag 28 april 2011 @ 22:45:
Sowieso: Alle input hou je gewoon "raw" in een variabele (dus zoals je 'm ontvangen hebt*) IMHO. Pas op 't moment dat je er iets mee gaat doen gebruik je de juiste functies waar van toepassing [...knip...]

Ook dat staat gewoon in het artikel waar het vandaan komt. Ironisch genoeg lijkt dit ook nog enorm op de manier waarop Systems Hungarian is ontstaan, dat staat ook in dat artikel. Misschien moeten jullie dat toch eens lezen

EDIT2:
Het is alweer een aantal posts geleden dus even wat linkjes naar het artikel.

[ Voor 24% gewijzigd door Patriot op 28-04-2011 22:49 ]

[RobIII]

Patriot schreef op donderdag 28 april 2011 @ 22:45:
Ook dat staat gewoon in het artikel waar het vandaan komt. Ironisch genoeg lijkt dit ook nog enorm op de manier waarop Systems Hungarian is ontstaan, dat staat ook in dat artikel. Misschien moeten jullie dat toch eens lezen

RobIII in "\[C#] Treeviewitem doubleclickevent" Check die datum eens._{En ik vreet 't beer als ik er niet <2009 al niet een paar keer naar verwezen heb; kan 't alleen nu zo snel niet vinden...} Ik ken 't dus wel hoor

Wat ik zeg: Als je 't op de manier doet zoals ik 't omschrijf heb je zelden tot nooit überhaupt een "safe" of "unsafe" variabele nodig. Een variabele is dan per-definitie unsafe. Zaken als een "xl" prefix hebben dan wél nog nut, maar dat vind ik niet meer onderdeel uit maken van wel/geen Hungarian maar gewoon onderdeel van de variabelenaam zélf.

[ Voor 35% gewijzigd door RobIII op 28-04-2011 23:09 ]

[Patriot]

Ik was er ook niet bepaald bang voor dat jij hem überhaupt nog nooit had gelezen, maar dat wil niet zeggen dat jou opmerking (in mijn ogen) niets te maken heeft met dat wat Joel zegt. In de eerste plaats is het al niet zo dat Joel zegt dat je gegevens vroegtijdig om moet zetten:

One solution is to encode all strings right away, the minute they come in from the user [...] That works, in the sense that if you follow this convention you’ll never have a XSS bug, but that’s not necessarily the best architecture. For example maybe you want to store these user strings in a database somewhere, and it doesn’t make sense to have them stored HTML-encoded in the database, because they might have to go somewhere that is not an HTML page, like to a credit card processing application that will get confused if they are HTML-encoded. [...] We really need to be able to keep things around in unsafe format for a while.

Waar het op neerkomt is dat je een safe string alleen gebruikt als je het ook daadwerkelijk in een HTML-context verstuurd. Anders blijft het gewoon unsafe.

Ik zeg overigens niet dat het een code conventie is waarvan ik vind dat die algemeen aangehouden moet worden. Integendeel, ik ben van mening dat hij te beperkt is voor real life gebruik. Het is echter wel een goede manier om het voor jezelf makkelijk te maken om foute code te spotten. En het nadeel dat jij aanhaalt (dat je te vroeg de HTML encode) is helemaal niet iets wat door de conventie bepaald wordt.

Daarnaast is het in mijn ogen overigens zo dat deze conventie nooit bedoeld was als serieuze conventie. Het is gewoon een voorbeeld om aan te tonen dat het mogelijk is om coding conventies te hanteren die je in staat stellen foute code zo snel mogelijk op te sporen.

[Alex)]

CodeCaster schreef op donderdag 28 april 2011 @ 21:21:
Natuurlijk, maar met veel, datavretende, statische content is een lichte http-daemon natuurlijk fijner, omdat dat resources scheelt en sneller geserveerd wordt. Dus kun je niet controleren of iemand rechten heeft wanneer hij de bestandsnaam weet, dus kun je die beter obfuscaten. Wel een vorm van security through obscurity, maar als iemand requests wil bruteforcen met random hashes kun je daar weer andere maatregelen tegen treffen zoals een netwerkapparaat of stuk software die dat soort aanvallen tegenhoudet.

Psst: Lighttpd + ModSecDownload

[Janoz]

Patriot schreef op donderdag 28 april 2011 @ 22:45:

Ik ben verder ook benieuwd welke template engine jij gebruikt die kan zien welke variabelen wel veilig zijn en welke niet.

Een fatsoenlijke view oplossing escaped automatisch voor de juiste context en zou een explicite actie van de programmeur nodig moeten hebben om niet te escapen. Zelfs binnen html zelf zijn er verschillende escape methoden. Gewone tekst moet immers anders escaped worden dan de value die je ergens in een input veld dumpt.

[YopY]

Patriot schreef op donderdag 28 april 2011 @ 22:45:
Ik ben verder ook benieuwd welke template engine jij gebruikt die kan zien welke variabelen wel veilig zijn en welke niet.

Op zich maakt het niet uit - bij uitvoer moet je ervanuitgaan dat alle variabelen onveilig zijn. Tenminste, als het door de gebruiker ingevulde gegevens zijn.

Qua template engines heb ik in het verleden veel met JSP / JSTL gedaan, danwel gewoon EL expressies (${object.property}), danwel JSTL / c:out (<c:out value="${object.property}"/>). JSP wordt gecompileerd naar Java dat op zijn beurt gecompileerd wordt naar bytecode, dus alle EL output expressies kunnen automagisch ge-escaped worden.

Op het moment zit ik in een project waar we eigenlijk alles clientside doen - een webservice die JSON uitpoept, en clientside rendering mbv Datatables en Mustache.js. Eerlijk gezegd heb ik geen flauw idee of die aan output escaping doen, maar ik neem gewoon aan van ja. De data die we tonen is verder niet van gebruikers afkomstig, dus het maakt ook niet zoveel uit.

[Verwijderd]

Paul Nieuwkamp schreef op donderdag 28 april 2011 @ 09:22:
[...]
Just curious, maar wat is het probleem met die code? Enige wat ik zie is schakelaar <> knop, vrijwel al het andere wordt je opgelegd door de libs van (bijvoorbeeld) Atmel

Nederlandse functie-/variabele namen, slecht geindenteerd en niet consistent met variabele namen.

[ Voor 3% gewijzigd door Verwijderd op 29-04-2011 13:07 ]

[Paul]

Nederlands: Moet de programmeur zelf weten (of opgelegd krijgen), wil ik niet direct fout noemen
Indentie: Waar dan?
Niet consistent: Point. ALARM, AlarmInstellen en hour / min. Al is ALARM misschien een register, dat kan ik zo niet beoordelen, gezien de all caps verwacht ik van wel. Hour / min zou Uur en Min moeten zijn, of alarmInstellen en uur

@hieronder: Ah, ja, dat verklaart Dan is het alleen de naam ALARM inconsistent

[ Voor 11% gewijzigd door Paul op 29-04-2011 14:22 ]

[PrisonerOfPain]

Paul Nieuwkamp schreef op vrijdag 29 april 2011 @ 13:37:
Al is ALARM misschien een register, dat kan ik zo niet beoordelen, gezien de all caps verwacht ik van wel.

ALARM is een time_t, net als DeTijd. Kortom, de hour/min komen uit de bestaande stdlib implementatie.

[roy-t]

Arggh dit geeft voor mij aan waarom PHP een slecht programmeervoorbeeld blijft:

www.reddit.com/r/programm...ariable_variables/c12np38 (het gaat om de reusachtige comment van masklinn)

Je gelooft toch niet wat daar allemaal staat? Ik hoop echt dat het niet waar is.

Edit: Comments komen uit een discussie over PHP's Variable Variables

[ Voor 17% gewijzigd door roy-t op 29-04-2011 16:22 ]

[Patriot]

YopY schreef op vrijdag 29 april 2011 @ 11:46:
[...]


Op zich maakt het niet uit - bij uitvoer moet je ervanuitgaan dat alle variabelen onveilig zijn. Tenminste, als het door de gebruiker ingevulde gegevens zijn.

Mijn punt was dan ook meer hoe jouw templating engine weet of het wel of niet van de gebruiker komt Uiteindelijk is het gewoon je eigen verantwoordelijkheid, en standaard alles beschouwen als onveilig tenzij je weet dat het dat niet is ligt daar gewoon in het verlengde van, dat moge duidelijk zijn.

[afraca]

Roy, php heeft gewoon ingebouwde support voor code obfuscation

[Patriot]

roy-t schreef op vrijdag 29 april 2011 @ 16:20:
Arggh dit geeft voor mij aan waarom PHP een slecht programmeervoorbeeld blijft:

www.reddit.com/r/programm...ariable_variables/c12np38 (het gaat om de reusachtige comment van masklinn)

Je gelooft toch niet wat daar allemaal staat? Ik hoop echt dat het niet waar is.

Edit: Comments komen uit een discussie over PHP's Variable Variables

Tsja, het is gewoon heel erg overdreven gebruik maken van een mogelijkheid binnen PHP. Onduidelijke of haast onbegrijpelijke code kun je met elke taal schrijven.

[MBV]

Noem 1 taal met variable variables...

En dan heb je van die idioten ertussen die een poor mans array gaan maken met variable variables, omdat ze de array-syntax niet kennen

[Matis]

MBV schreef op vrijdag 29 april 2011 @ 20:12:
Noem 1 taal met variable variables...

En dan heb je van die idioten ertussen die een poor mans array gaan maken met variable variables, omdat ze de array-syntax niet kennen

Javascript, of telt dat niet als taal?
anders krijg je idd deze gedrochten

C#:

Obj1 = new Obj ();
Obj2 = new Obj ();

for (int i = 0; i<2; i++ ) {
  if (Obj{i}.getValue () > 0) {
      // code
  }
}

[Patriot]

MBV schreef op vrijdag 29 april 2011 @ 20:12:
Noem 1 taal met variable variables...

En dan heb je van die idioten ertussen die een poor mans array gaan maken met variable variables, omdat ze de array-syntax niet kennen

Het gaat er niet om hoe je lelijke gedrochten van code tevoorschijn tovert, het gaat erom dat je dat niet moet doen

Als iemand met behulp van variabele variabelen een array probeert na te bootsen dan is dat een slecht voorbeeld, als ze dat op een andere maar ook verkeerde manier doen in &inserttaal; doen dan is dat ook een slecht programmeervoorbeeld. Maar dat maakt die talen niet slecht.

[RayNbow]

MBV schreef op vrijdag 29 april 2011 @ 20:12:
Noem 1 taal met variable variables...

En dan heb je van die idioten ertussen die een poor mans array gaan maken met variable variables, omdat ze de array-syntax niet kennen

Telt dit?

C:\>python
Python 2.5.4 (r254:67916, Dec 23 2008, 15:10:54) [MSC v.1310 32 bit (Intel)] on
win32
Type "help", "copyright", "credits" or "license" for more information.
>>> for i in range(10):
...     locals()['a%02d' % i] = i
...
>>> a00
0
>>> a07
7

[Soultaker]

Waarom kan dat?! Worden zelfs locals in Python via een dictionary lookup gedaan? (Geen wonder dat 't zo traag is dan... )

[ Voor 27% gewijzigd door Soultaker op 29-04-2011 21:24 ]

[RayNbow]

Soultaker schreef op vrijdag 29 april 2011 @ 21:23:
Waarom kan dat?! Worden zelfs locals in Python via een dictionary lookup gedaan? (Geen wonder dat 't zo traag is dan... )

Dat het kan wil niet zeggen dat er geen ruimte is voor optimalisaties:

quote: http://www.python.org/doc/essays/list2str.html

This is because local variable lookups are much faster than global or built-in variable lookups: the Python "compiler" optimizes most function bodies so that for local variables, no dictionary lookup is necessary, but a simple array indexing operation is sufficient.

[FragFrog]

MBV schreef op vrijdag 29 april 2011 @ 20:12:
Noem 1 taal met variable variables...

Mmm, effectief werken ze niet anders dan pointers. En function pointers in C++ zijn afaik ook prima om te gebruiken. Snap het probleem dan ook niet zo: ja, je kunt variabele variabelenamen gebruiken in PHP. Het is een feature die spaarzaam toegepast dient te worden voor leesbaarheid, maar in bepaalde situaties verdomd handig is: het kan een stuk code enorm versimpelen en met wat creatief denken juist nieuwe mogelijkheden bieden. Ik heb het jaren geleden al eens gebruikt voor een hack om 'echte' overloading in PHP te simuleren

[Jaap-Jan]

Nou, ik vind de enige overeenkomst tussen pointers (of references) en 'variable variables' is dat ze ergens naar wijzen: pointers wijzen naar een blok geheugen en een variable variable wijst naar een variabele.

Het grote verschil is dat je een variable variable op kan bouwen aan de hand van een string, terwijl je met een pointer alleen pointer arithmetic tot je beschikking hebt.

[PrisonerOfPain]

Jaap-Jan schreef op zaterdag 30 april 2011 @ 12:49:
Het grote verschil is dat je een variable variable op kan bouwen aan de hand van een string, terwijl je met een pointer alleen pointer arithmetic tot je beschikking hebt.

Je kunt pointers ook naar een random stuk geheugen laten wijzen hoor

code:

char *v = (char*)0xff00;

[Jaap-Jan]

PrisonerOfPain schreef op zaterdag 30 april 2011 @ 13:10:
[...]


Je kunt pointers ook naar een random stuk geheugen laten wijzen hoor

code:

char *v = (char*)0xff00;

Je kunt zelfs met rand() in de weer.

Maar in C(++) is er geen functie die als invoer een char[] heeft en als uitvoer een (void *) naar een geheugenadres. En dan moet je ook nog eens weten wat het type is van het adres waar hij naar wijst en als het een char[] is: de lengte daarvan.

[PrisonerOfPain]

Jaap-Jan schreef op zaterdag 30 april 2011 @ 13:40:
[...]


Je kunt zelfs met rand() in de weer.

Maar in C(++) is er geen functie die als invoer een char[] heeft en als uitvoer een (void *) naar een geheugenadres. En dan moet je ook nog eens weten wat het type is van het adres waar hij naar wijst en als het een char[] is: de lengte daarvan.

Mja, kan d'r een maken voor je.

C++:

void *getSummedAddress(char *s)
{
     uintptr_t p = 0;
     int len = strlen(s);
     for(int i = 0; i < len; i++) p += s[i];
     return (void*)p;
}

// verderop
int *ptr = (int*)getSummedAddress("ikHebZinInKaasEnHam");
ptr[0] = 0xDEADBEEF;

[Verwijderd]

roy-t schreef op vrijdag 29 april 2011 @ 16:20:
Arggh dit geeft voor mij aan waarom PHP een slecht programmeervoorbeeld blijft:

www.reddit.com/r/programm...ariable_variables/c12np38 (het gaat om de reusachtige comment van masklinn)

Je gelooft toch niet wat daar allemaal staat? Ik hoop echt dat het niet waar is.

Edit: Comments komen uit een discussie over PHP's Variable Variables

Niks dat daar staat is onverwacht, alles gedocumenteerd. Beetje raar om door zo'n linkje een hele taal als slecht programmeervoorbeeld af te schrijven. Bagger code kan je in elke taal maken, dus elke taal is een slecht programmeervoorbeeld?

[Verwijderd]

PrisonerOfPain schreef op zaterdag 30 april 2011 @ 13:10:
[...]


Je kunt pointers ook naar een random stuk geheugen laten wijzen hoor

code:

char *v = (char*)0xff00;

En laat de segmentation faults maar beginnen!

[Jaap-Jan]

PrisonerOfPain schreef op zaterdag 30 april 2011 @ 13:59:
[...]


Mja, kan d'r een maken voor je.

C++:

void *getSummedAddress(char *s)
{
     uintptr_t p = 0;
     int len = strlen(s);
     for(int i = 0; i < len; i++) p += s[i];
     return (void*)p;
}

// verderop
int *ptr = (int*)getSummedAddress("ikHebZinInKaasEnHam");
ptr[0] = 0xDEADBEEF;

Doet precies wat ik daar typte, maar toch niet wat ik bedoelde. Die invoer zou dan een naam moeten zijn van een lokale variabele.

C:

int hello = 123;
int *p = (int *)addressOf("hello");
printf("%i", *p); //prints 123

Zoiets. Waarbij de invoer de naam is van een variabele die zichtbaar is in de huidige scope. Dat zou ongeveer hetzelfde kunnen als variable variables in PHP.

[Alex)]

Verwijderd schreef op zaterdag 30 april 2011 @ 14:47:
[...]

Niks dat daar staat is onverwacht, alles gedocumenteerd. Beetje raar om door zo'n linkje een hele taal als slecht programmeervoorbeeld af te schrijven. Bagger code kan je in elke taal maken, dus elke taal is een slecht programmeervoorbeeld?

Je krijgt echter wel onverklaarbaar (en potentieel gevaarlijk) gedrag. Als je user-input niet goed checkt zou je op zo'n manier zelfs aan een variabele als $config of $_REQUEST kunnen komen. En dat het gedocumenteerd is betekent niet dat het goed is. Het is een poor man's-implementatie van een array.

[Patriot]

Alex) schreef op zaterdag 30 april 2011 @ 23:41:
[...]

Je krijgt echter wel onverklaarbaar (en potentieel gevaarlijk) gedrag. Als je user-input niet goed checkt zou je op zo'n manier zelfs aan een variabele als $config of $_REQUEST kunnen komen. En dat het gedocumenteerd is betekent niet dat het goed is. Het is een poor man's-implementatie van een array.

Sorry, maar dit slaat echt helemaal nergens op. Het is niet onverklaarbaar. Het is allemaal heel erg logisch. De persoon in die reddit-reactie maakt het extra ingewikkeld (o.a. puur door het feit dat hij vreemde variabelnamen gebruikt) en doet alsof het heel gek is. Maar dat is het niet.

En zeggen dat het een poor-man's-implementatie van een array is slaat helemaal nergens op. Daar kun je het voor misbruiken, maar dat is het niet per definitie.

[CoolGamer]

PHP:

${$_GET['var']} = true

is net zo gevaarlijk als

PHP:

include $_GET['var'];

Dus als je gebruikersinput direct gebruikt als variabelenaam dan levert dat inderdaad een beveiligingsprobleem op. Maar ja, dat is natuurlijk altijd een risico: gebruikersinput ongecontroleerd overal voor gebruiken.

[Soultaker]

RayNbow schreef op vrijdag 29 april 2011 @ 22:09:
Dat het kan wil niet zeggen dat er geen ruimte is voor optimalisaties:

Ik wilde zeggen dat optimalisaties lastig zijn als je locals indirect (via een dictionary) kan updaten, maar toen las ik de documentatie (had ik natuurlijk meteen moeten doen):

Update and return a dictionary containing the current scope's local variables.

Het is dus een snapshot van de waarden van lokale variabelen. Je kunt ze niet updaten via de dictionary. (Je kunt de dictionary wel editen, maar daarmee verander je de waarden van de variabelen niet.)

[RayNbow]

Soultaker schreef op zondag 01 mei 2011 @ 00:26:
[...]

Het is dus een snapshot van de waarden van lokale variabelen. Je kunt ze niet updaten via de dictionary. (Je kunt de dictionary wel editen, maar daarmee verander je de waarden van de variabelen niet.)

Het klopt dat je in een functie kun je de lokale variabelen niet kunt aanpassen via locals(), maar in module en class scope kan dat wel:

Python:

def printfn(x):
    print x

def test():
    a = 3
    locals()['a'] = 5
    printfn(a)

class Test:
    a = 3
    locals()['a'] = 5
    
    def foo(self):
        printfn('foo')
    
    locals()['foo'] = lambda self: printfn('bar')

test()                     # prints 3
print Test.a               # prints 5
Test().foo()               # prints bar