[alg] Slechtste programmeervoorbeelden deel 4

[netvor]

.oisyn schreef op vrijdag 19 december 2008 @ 01:16:
7 & 5 is dan ook heel wat anders dan 7 && 5 (respectievelijk 5 en true)

In dit voorbeeld is dat geen wereldschokkend verschil: als je ze in een if( ) gebruikt komen beiden op hetzelfde neer. Maar kijk eens naar deze:

C:

if ( 2 && 4 ) {
  /* wordt uitgevoerd, beide argumenten zijn namelijk "niet nul" dus het resultaat is 1. */
}
if ( 2 & 4 ) {
  /* wordt niet uitgevoerd, resultaat van de bitwise-and is 0. */
}

Trouwens: ANSI C kent niet iets als "true" en "false." Het resultaat van een bitwise AND is een int met waarde 1 of 0. En ja, ik ben bekend met C99. Maar een hoop compilerbouwers helaas nog niet, na slechts een jaar of tien...

[ Voor 7% gewijzigd door netvor op 19-12-2008 10:45 ]

[.oisyn]

netvor schreef op vrijdag 19 december 2008 @ 10:40:
Trouwens: ANSI C kent niet iets als "true" en "false." Het resultaat van een bitwise AND is een int met waarde 1 of 0. En ja, ik ben bekend met C99. Maar een hoop compilerbouwers helaas nog niet, na slechts een jaar of tien...

Beetje rare opmerking. Aan de ene kant zeg je dat ANSI C (ik spreek trouwens liever over ISO C) geen boolean types en constants kent, aan de andere kant zeg je dat dat weer wel het geval is. Ja, ISO C kent true en false. Nee, nog niet iedere compiler ondersteunt die bijna 10 jaar oude specificatie, maar de meesten concentreren zich dan ook op C++.

.Gertjan. schreef op vrijdag 19 december 2008 @ 08:10:
[...]


Rechtstreeks de namespace importeren is niet altijd handig nee (zeker niet als 2 namespaces dezelfde classes bevatten, zoals een aantal database namespaces van Java geloof ik). In .NET hebben ze daar een handigheidje voor (weet niet of het in meerdere talen zo werkt):

C#:

using BLL = very.long.name.space;

Kan in C++ ook

C++:

namespace kort = een::hele::diepe::nested::Namespace;

[ Voor 37% gewijzigd door .oisyn op 19-12-2008 11:59 ]

[netvor]

Zucht. De programmeertaal C heeft meer namen dan Prince: ANSI C, ISO C, C89, C90, C99, K&R en ga zo maar door. Het lijkt haast wel een opensourceproject.

Wat ik probeerde te zeggen was dat het dialect dat omstreeks 1989-1990 door ANSI en ISO gestandaardiseerd is geen booleans kent. Het dialect dat een kleine tien jaar later is gestandaardiseerd (wederom door zowel ANSI als ISO) heeft wel plaats voor booleans. Mij is aangeleerd die eerste "ANSI C" te noemen en die laatste "C99." Dat slaat inderdaad nergens op, want C99 is net zo goed "een ANSI C." Maar helaas, wat je eenmaal aangeleerd hebt, leer je niet zo snel weer af.

Wat ik verder probeerde te zeggen was dat als je het over de taal C hebt, dat je dan voor de zekerheid maar beter uit kan gaan van de 89/90 versie, aangezien moderne compilers niet alle features van de nieuwe versie ondersteunen. Soms kan je die alleen maar benaderen door je programma als C++ te compileren.

[Zoijar]

Bijna niemand schrijft "ANSI C" (C89) voor zover ik weet. Ik heb het wel eens moeten doen, en dat is raar. Compile maar eens met gcc -ansi -pedantic. Volgens mij heb je dan geen single line comments, moet je al je declaraties aan het begin van je scope maken, en nog meer van dat soort hinderlijke restricties.

[.oisyn]

netvor schreef op vrijdag 19 december 2008 @ 13:54:
Wat ik verder probeerde te zeggen was dat als je het over de taal C hebt, dat je dan voor de zekerheid maar beter uit kan gaan van de 89/90 versie, aangezien moderne compilers niet alle features van de nieuwe versie ondersteunen.

Klopt, maar boolean types zijn nou net van die dingen die de meeste moderne compilers wél ondersteunen. Net als variadic macro's en idd C++-style declaraties en comments.

[Robtimus]

Verwijderd schreef op vrijdag 19 december 2008 @ 01:01:
[...]
is dat dan niet in principe hetzelfde? Of geldt niet true==1 en false==0?

In principe niet nee. Het enige dat geldt is dat false == 0 en true != 0. Dat true vaak 1 is, hoeft nog niet te betekenen dat het altijd zo is. Zo kan ook -1 worden gebruikt - de bitwise negatie van false.

[.oisyn]

Overigens geldt wat FD-man zegt wel altijd, alleen is dat niet helemaal hoe hij het bedoelde. Als in, (int)true is altijd 1 en (int)false is altijd 0. Dus true==1 && false==0 geeft altijd true .

[link0007]

.oisyn schreef op donderdag 18 december 2008 @ 00:18:
Persoonlijk ben ik dan weer niet zo'n fan van { of de then-clause van een if op dezelfde regel maar dat is een kwestie van voorkeur

Om niet te ver off-topic te gaan, maar ik irriteer me er echt aan dat het merendeel van de code die ik lees, de { op dezelfde regel heeft staan

Wat is nu makkelijker:

PHP:

function optellen($getal1,$getal2){
    $uitkomst = $getal1;
    while ($getal2>0){
        $uitkomst++;
        $getal2--;
    }
    return $uitkomst;
}

of

PHP:

function optellen($getal1,$getal2)
{
    $uitkomst = $getal1;
    while ($getal2>0)
    {
        $uitkomst++;
        $getal2--;
    }
    return $uitkomst;
}

Vooral zonder indenting is het echt horror als iemand de eerste manier gebruikt Gelukkig dwingt Python indenting af, anders was dat helemaal een rampentaal geweest.

Python:

def optellen(getal1,getal2):
uitkomst = getal1
while (getal2>0):
uitkomst+=1
getal2-=1
return uitkomst

Dan zie je dus echt niet meer wat er gebeurt (kijk, dan zien mensen wel hoe belachelijk het is om niet te indenten.. anders zien ze het probleem nooit )


Hoort toch zeker ook wel in dit topic thuis

[ Voor 0% gewijzigd door link0007 op 20-12-2008 12:24 . Reden: tiepvout ]

[Zoijar]

link0007 schreef op zaterdag 20 december 2008 @ 01:42:

Ik heb een hekel aan die tweede manier, kost zo veel verticale ruimte.

[CrashOverDrive]

Zoijar schreef op zaterdag 20 december 2008 @ 05:05:
[...]

Ik heb een hekel aan die tweede manier, kost zo veel verticale ruimte.

Dat heb ik juist weer andersom, vind ook de platte manier onleesbaar.
Gewoon lekker enteren, daar heb je tenslotte een scrollwiel voor , imho is alles dan een stuk duidelijker.
Maar inprincipe is het geen slecht programmeer voorbeeld (beide), is meer een kwestie van persoonlijke voorkeur.

[Sebazzz]

Zoijar schreef op zaterdag 20 december 2008 @ 05:05:
[...]

Ik heb een hekel aan die tweede manier, kost zo veel verticale ruimte.

Vind ik ook, bovendien gaat niet iedere editor er even goed mee om. (Notepad++ en Zend hadden daar in het verleden in ieder geval problemen mee dus daarom gebruik ik de eerste methode)

[Jaap-Jan]

link0007 schreef op zaterdag 20 december 2008 @ 01:42:
[...]

Om niet te ver off-topic te gaan, maar ik irriteer me er echt aan dat het merendeel van de code die ik lees, de { op dezelfde regel heeft staan

Wat is nu makkelijker:

PHP:

//

of

PHP:

//

Vooral zonder indenting is het echt horror als iemand de eerste manier gebruikt Gelukkig dwingt Python indentating af, anders was dat helemaal een rampentaal geweest.

Python:

def optellen(getal1,getal2):
uitkomst = getal1
while (getal2>0):
uitkomst+=1
getal2-=1
return uitkomst

Dan zie je dus echt niet meer wat er gebeurt (kijk, dan zien mensen wel hoe belachelijk het is om niet te indenten.. anders zien ze het probleem nooit )


Hoort toch zeker ook wel in dit topic thuis

Afdwingen? Ze kunnen niet anders:

Python:

for i in range(0,10):
print i
print 'hallo'

Wat zou er allemaal bij de for-loop horen (als Python een free-form taal zou zijn, want dit kan natuurlijk niet in Python)? Als jij het niet kan zien, kan de compiler dat ook niet zien.

En ik geef persoonlijk de voorkeur aan de eerste vorm, maar dat is echt een kwestie van smaak. Wel apart dat je de eerste code niet leesbaar vind, terwijl de stijl van Python daar dichter tegen aan ligt dan de tweede. Geen extra witruimte tussen de functiedeclaratie (idem voor loops en flow-control statements) en het begin van het code-block bijvoorbeeld.

[.oisyn]

Zoijar schreef op zaterdag 20 december 2008 @ 05:05:
[...]

Ik heb een hekel aan die tweede manier, kost zo veel verticale ruimte.

Who cares , niemand werkt tegenwoordig meer met een 80x25 textscherm of 640x480 grafisch. Comments nemen ook verticale ruimte in. "Alinea's" ook (tenminste, ik hoop dat je wel nog steeds alinea's in je code aanbrengt, anders wordt het helemaal zo'n onleesbare brei)

[link0007]

hehe, kwam net dit tegen in iemand anders z'n code:

Python:

        elif not isinstance(self, PhunHeader):

            if "zDepth" in self.data:

                self.zDepth = strip2float(self.data["zDepth"])

            else:

                try:
                    assert(version == 1)
                except AssertionError:
                    assert(version != 1)

                self.zDepth = 0

Zo kan je die assert toch net zo goed weglaten? Ik snap de logica niet helemaal
Lijkt iig op een vieze quickfix.. Ben ik zelf ook goed in, vieze quickfixes per ongeluk in de uiteindelijke code laten zitten

[kunnen]

C++:

for(int i=0; i<max_keer; i++)
{
  getal.doIets();
  IsPalindroom(getal, i);
}
//doe hier nog iets met het getal

Dan kijk je, en dan denk je natuurlijk dat het moet zijn:

C++:

if(IsPalindroom(getal)) break;

Maar nee, wat bevat de IsPalindroom functie:

C++:

void IsPalindroom(Getal* getal, int* i)
{
  bool werkelijk_palindroom;
  //logica hier
  if(werkelijk_palindroom) i = 9999999;
}

Het werkt toch?

[ Voor 3% gewijzigd door kunnen op 21-12-2008 01:25 ]

[Zoijar]

.oisyn schreef op zaterdag 20 december 2008 @ 13:15:

Who cares , niemand werkt tegenwoordig meer met een 80x25 textscherm of 640x480 grafisch. Comments nemen ook verticale ruimte in. "Alinea's" ook (tenminste, ik hoop dat je wel nog steeds alinea's in je code aanbrengt, anders wordt het helemaal zo'n onleesbare brei)

Ja, dat klopt.Het is een persoonlijke voorkeur; er is niets mis met beide. Ik zou sowieso een wit-regel na de "declaraties" doen, en eentje voor de return. Functie init / body / result in alinea's. Bij meerdere loops ook elke loop met init in zijn eigen alinea etc. Lange functie calls schrijf ik ook meerdere regels. Het gaat mij er eigenlijk meer om dat een closing brace hoort bij de statement die er recht boven staat. Ach, wat maakt het ook uit

[Brian]

ThomasB schreef op zondag 21 december 2008 @ 01:24:

C++:

for(int i=0; i<max_keer; i++)
{
  getal.doIets();
  IsPalindroom(getal, i);
}
//doe hier nog iets met het getal

Dan kijk je, en dan denk je natuurlijk dat het moet zijn:

C++:

if(IsPalindroom(getal)) break;

Maar nee, wat bevat de IsPalindroom functie:

C++:

void IsPalindroom(Getal* getal, int* i)
{
  bool werkelijk_palindroom;
  //logica hier
  if(werkelijk_palindroom) i = 9999999;
}

[...]

Dit is echt de meest vage en onlogische constructie die ik in tijden heb gezien

[PrisonerOfPain]

Zoijar schreef op zondag 21 december 2008 @ 11:11:
[...]
Het gaat mij er eigenlijk meer om dat een closing brace hoort bij de statement die er recht boven staat.

Een beetje IDE heeft natuurlijk zelf aan waar de closing brace bij hoort

[Onbekend]

ThomasB schreef op zondag 21 december 2008 @ 01:24:

C++:

for(int i=0; i<max_keer; i++)
{
  getal.doIets();
  IsPalindroom(getal, i);
}
//doe hier nog iets met het getal

Dan kijk je, en dan denk je natuurlijk dat het moet zijn:

C++:

if(IsPalindroom(getal)) break;

Maar nee, wat bevat de IsPalindroom functie:

C++:

void IsPalindroom(Getal* getal, int* i)
{
  bool werkelijk_palindroom;
  //logica hier
  if(werkelijk_palindroom) i = 9999999;
}

[...]

Dus als je max_keer groter dan 9999999 is, zou je in een oneindige loop terecht kunnen komen.
Zelf vind ik dat een rare constructie en sommige programmeertalen laten dit soort technieken gelukkig niet toe.

[kenneth]

ThomasB schreef op zondag 21 december 2008 @ 01:24:

C++:

for(int i=0; i<max_keer; i++)
{
  getal.doIets();
  IsPalindroom(getal, i);
}
//doe hier nog iets met het getal

Dan kijk je, en dan denk je natuurlijk dat het moet zijn:

C++:

if(IsPalindroom(getal)) break;

Maar nee, wat bevat de IsPalindroom functie:

C++:

void IsPalindroom(Getal* getal, int* i)
{
  bool werkelijk_palindroom;
  //logica hier
  if(werkelijk_palindroom) i = 9999999;
}

[...]

Ik heb code vol dit soort constructies moeten onderhouden

[jos707]

Onbekend schreef op zondag 21 december 2008 @ 15:14:
[...]

Dus als je max_keer groter dan 9999999 is, zou je in een oneindige loop terecht kunnen komen.
Zelf vind ik dat een rare constructie en sommige programmeertalen laten dit soort technieken gelukkig niet toe.

Dat dit niet de meest logische en verfijnde manier van programmeren is kan ik begrijpen maar dat een programmeertaal dit niet zou compilen vind ik vreemd.

[Onbekend]

jos707 schreef op zondag 21 december 2008 @ 16:18:
[...]

Dat dit niet de meest logische en verfijnde manier van programmeren is kan ik begrijpen maar dat een programmeertaal dit niet zou compilen vind ik vreemd.

In de for-constructie staat dat i steeds met 1 opgehoogd moet worden. Dit zou dus moeten betekenen dat de for-loop "max_keer" doorlopen wordt. Doordat je de variable i ook al ergens anders gaat wijzigen, kom je soms voor de meest vreemde problemen te staan.
Zelf zou ik dit gewoon vervangen door een do-while-loop met daarin i++.

Twee programmeertalen die het niet toelaten om een variable van een for-loop nog eens te wijzigen zijn Delphi en Visual Basic.

[roy-t]

Waarom dan ook niet INT_MAX of zoiets gebruiken? dan heb je nooit een inf loop. (geen int kan 1 groter zijn dan int_max dus dan stopt de for loop wel)

* roy-t negeert het echte probleem: lelijke code

[Zoijar]

PrisonerOfPain schreef op zondag 21 december 2008 @ 15:10:
[...]


Een beetje IDE heeft natuurlijk zelf aan waar de closing brace bij hoort

Ja, bij de bijbehorende opening brace.

C++:

while (1) {}
{ // acquire lock
   ScopedLock lock(mutex);
}

ja ik weet het, dat geldt ook bij andere indentation

[ Voor 9% gewijzigd door Zoijar op 21-12-2008 18:16 ]

[PaveloW]

ThomasB schreef op zondag 21 december 2008 @ 01:24:

C++:

for(int i=0; i<max_keer; i++)
{
  getal.doIets();
  IsPalindroom(getal, i);
}
//doe hier nog iets met het getal

Zou volgens mij wel een fout moeten geven met compilen, i wordt als een pointer verwacht in de IsPalindroom() functie, dus zou eigenlijk als &i moeten worden doorgeven, waarschijnlijk wordt i als een reference doorgegeven aan de IsPalindroom() functie, aangezien hij ook zomaar wordt toegewezen....maar toch niet het meest handige stukje om het op die manier te doen....

[Zoijar]

Sowieso is het eigenlijk rare code, want na de loop weet je nog steeds niets; is het nou een palindroom, of niet? De i valt namelijk ook nog uit scope, dus je bent al je informatie kwijt.

[Woy]

Ik denk niet dat hij "i" controleerd of het een Palindroom is maar "getal". "i" geeft hij dan alleen mee om uit de loop te springen. Maar de code is niet helemaal compleet, dus het blijft een gok.

[Zoijar]

Dat snap ik Maar na de loop is het of een ealy exit geweest, of het is een palindroom, en je weet niet welke.

[Verwijderd]

link0007 schreef op zaterdag 20 december 2008 @ 01:42:
[...]

Om niet te ver off-topic te gaan, maar ik irriteer me er echt aan dat het merendeel van de code die ik lees, de { op dezelfde regel heeft staan

Wat is nu makkelijker:

PHP:

function optellen($getal1,$getal2){
    $uitkomst = $getal1;
    while ($getal2>0){
        $uitkomst++;
        $getal2--;
    }
    return $uitkomst;
}

of

PHP:

function optellen($getal1,$getal2)
{
    $uitkomst = $getal1;
    while ($getal2>0)
    {
        $uitkomst++;
        $getal2--;
    }
    return $uitkomst;
}

[....]


Hoort toch zeker ook wel in dit topic thuis

Hoort nou precies niet in dit topic thuis. Dit is immers een kwestie van voorkeur of misschien zelfs gewoon van de conventies binnen het bedrijf waar je werkt en heeft niets met goed of slecht programmeren te maken.

[alienfruit]

Daar hebben ze hele leuke dingen voor bedacht namelijk code formatters. Gewoon lekker code formatter er over heen voordat je aan het werk gaat en daarna weer een erover als je het weer incheckt. Maar goed, ik ben iemand die valt over niet hangende { } of geen spaties tussen operators en haakjes (dus: while ( $getal2 > 0 ) {).

[ Voor 4% gewijzigd door alienfruit op 22-12-2008 14:54 ]

[.oisyn]

alienfruit schreef op maandag 22 december 2008 @ 14:53:
Daar hebben ze hele leuke dingen voor bedacht namelijk code formatters. Gewoon lekker code formatter er over heen voordat je aan het werk gaat en daarna weer een erover als je het weer incheckt.

Ontzettend onhandig, dan laten de diffs onnodige changes zien, en wordt het integreren tussen branches een stuk lastiger.

[Kettrick]

.oisyn schreef op maandag 22 december 2008 @ 15:15:
[...]

Ontzettend onhandig, dan laten de diffs onnodige changes zien, en wordt het integreren tussen branches een stuk lastiger.

Tenzij je binnen een team dezelfde instellingen gebruikt voor de formatting, maar dat is in de praktijk nogal lastig

[alienfruit]

Ja, daarom heb ik ook als BDOH een pre-commit hook in de bare repo die de code formatter draait die voldoet aan de wensen van de klant. Deze lost dan meteen problemen op zoals tab -> spaces e.d.

[ Voor 21% gewijzigd door alienfruit op 22-12-2008 15:40 ]

[kenneth]

Bij ons blijft iedereen gewoon van de default settings van VS.NET af, opgelost Nouja, bijna dan.

[Snake]

kenneth schreef op maandag 22 december 2008 @ 16:03:
Bij ons blijft iedereen gewoon van de default settings van VS.NET af, opgelost Nouja, bijna dan.

Bij JavaScript zet ik 'm toch op

JavaScript:

function blah()
{
}

ipv.

JavaScript:

function blah() {
}

En Line Numbers.

En Tabs als Tabs, en 1 tab = 4 spaties. Imo het beste, dan kan iedereen zelf bepalen hoe breed die z'n tabs wilt weergeven

[netvor]

PaveloW schreef op maandag 22 december 2008 @ 08:09:
Zou volgens mij wel een fout moeten geven met compilen, i wordt als een pointer verwacht in de IsPalindroom() functie, dus zou eigenlijk als &i moeten worden doorgeven, waarschijnlijk wordt i als een reference doorgegeven aan de IsPalindroom() functie, aangezien hij ook zomaar wordt toegewezen....maar toch niet het meest handige stukje om het op die manier te doen....

Als we toch bezig zijn: getal wordt ook als pointer verwacht in de IsPalindroom() functie, maar toch staat er getal.doIets(); in de body van de loop. Even voor de volledigheid.

[PrisonerOfPain]

Zoijar schreef op zondag 21 december 2008 @ 18:14:
[...]
ja ik weet het, dat geldt ook bij andere indentation

Volgende generatie IDEs komt met IQ upgrade voor de gebruiker

[kunnen]

PaveloW schreef op maandag 22 december 2008 @ 08:09:
[...]


Zou volgens mij wel een fout moeten geven met compilen, i wordt als een pointer verwacht in de IsPalindroom() functie, dus zou eigenlijk als &i moeten worden doorgeven, waarschijnlijk wordt i als een reference doorgegeven aan de IsPalindroom() functie, aangezien hij ook zomaar wordt toegewezen....maar toch niet het meest handige stukje om het op die manier te doen....

Ik had de code niet letterlijk uit de source gehaald, heb nu het origineel bij de hand:

C++:

      void ispalindroomgetal (int& i) {
              i = 9999;
      }   

als publieke memberfunctie van een klasse (en werd alleen intern gebruikt ).

[.Gertjan.]

kenneth schreef op maandag 22 december 2008 @ 16:03:
Bij ons blijft iedereen gewoon van de default settings van VS.NET af, opgelost Nouja, bijna dan.

Vervelende is wel dat Visual Studio standaard spaties gebruikt inplaats van Tabs. Dit kan nog wel eens voor problemen zorgen als je de file opent met andere editors.

Het eerste wat ik doe bij een schone VS installatie is in iedergeval de settings zodanig aanpassen dat VS de Tabs ook echt als tabs opslaat.

Als niet iedereen die setting het zelfde heeft staan zal SourceSafe vaak onterecht filewijzigingen zien, omdat de regels die jij bewerkt ineens geen spaties meer bevatten, maar tabs of omgekeerd

[Zoijar]

.Gertjan. schreef op dinsdag 23 december 2008 @ 09:49:
Vervelende is wel dat Visual Studio standaard spaties gebruikt inplaats van Tabs. Dit kan nog wel eens voor problemen zorgen als je de file opent met andere editors.

Het eerste wat ik doe bij een schone VS installatie is in iedergeval de settings zodanig aanpassen dat VS de Tabs ook echt als tabs opslaat.

Als niet iedereen die setting het zelfde heeft staan zal SourceSafe vaak onterecht filewijzigingen zien, omdat de regels die jij bewerkt ineens geen spaties meer bevatten, maar tabs of omgekeerd

Ik ben juist kortgeleden overgestapt van tabs naar spaties. Tabs wordt altijd een zooitje als je eht een paar keer naar een ander systeem heen en weer kopieert. Spaties blijft gewoon prima.

[Janoz]

Met Zoijar. Vooral wanneer je een stukje onconventioneel indenting gebruikt zoals een grote booleaanse expressie waarbij je met inspringen graag de parenthesis wat duidelijker maakt of een lange methode waarbij je de parameters over meerdere regels netjes wilt uitlijnen. Tabs en automatische uitlijntools maken daar een zootje van.


@.oisyn hieronder:
Dat is wel zo, maar je ziet pas wanneer het fout is als de tab lengte aangepast wordt, nog los van het feit of je IDE uberhaupt snapt dat het eerste deel indenting met tab gebeurt en het volgende deel met spaties wanneer je een keer op enter drukt. Je wilt niet zelf voor elke regel weer opnieuw x maal op tab drukken en dan y maal op spatie.

[ Voor 35% gewijzigd door Janoz op 23-12-2008 14:24 ]

[.oisyn]

Niet als je indenting met tabs doet en uitlijning met spaties

[link0007]

scherp, oisyn

Maar tabs zelf maken geen rotzooit, het representeert gewoon x spaties. Wanneer je een uniform geheel behoudt, dus OF alleen tabs, OF alleen spaties, kan je er in principe geen zooitje van maken

Wanneer je voor uitlijning spaties gebruikt (die dus afgesteld zijn op JOUW tab-instellingen), en voor indenting tabs, en iemand anders opent het met andere instellingen, verpest je juist de hele uitlijning (tenzij je IDE het oplost).

Ik blijf erbij dat je nergens spaties hoeft te gebruiken voor je uitlijning of indenting, maar overal tabs.

[Woy]

link0007 schreef op dinsdag 23 december 2008 @ 12:43:
Ik blijf erbij dat je nergens spaties hoeft te gebruiken voor je uitlijning of indenting, maar overal tabs.

Hoe wil je het volgende dan met Tabs goed krijgen? Met een andere instelling voor Tabs gaat dat geheid mis

C#:

public void Method( int param1,
                    int param2 )
{
}

[ Voor 35% gewijzigd door Woy op 23-12-2008 12:49 ]

[SiliconError]

Link0007: als je het allemaal met tabs gaat doen, en je verandert je tab-width en dan valt je uitlijning uit elkaar.
Het kan dus niet alleen met tabs.

Je bent die int param2 aan het uitlijnen, je moet 'm dus tabben tot aan het niveau van 'public void', mocht dat nog geindenteerd zijn, en dan van daaruit gaan uitlijnen met spaties.
Wat het probleem is... automatische tools maken er meestal alleen tabs óf alleen spaties van.

[ Voor 40% gewijzigd door SiliconError op 23-12-2008 13:00 ]

[netvor]

@rwb: Door regel twee te beginnen met evenveel tabs als op regel 1 staan (in dit geval 0, maar zeker in een taal als C# zal zo'n functiedeclaratie binnenin een andere declaratie staan, dus worden er tabs toegevoegd. Na de tabs voeg je vervolgens 20 spaties in, en daarna de parameter.

Tsja, als je dit fijn vindt en je collega's ook, ga dan vooral je gang. Persoonlijk vind ik het mixen van twee verschillende soorten whitespace als het mixen van single malt whisky en coca cola, maar over smaak valt natuurlijk niet te twisten. Verder ben ik bang dat je een uitgebreide codeformatter moet hebben om dit automatisch te implementeren. Mijn laatste ervaring met MSVC was uit de tijd van MSVC2005, en die kon dit volgens mij niet.

* netvor mept SiliconError

[link0007]

Je hebt gelijk, rwb, daar had ik niet aan gedacht. Maar inderdaad, dan moet je wel verder gaan met spaties. Ik denk dat ik daar niet goed over heb nagedacht

[Zoijar]

rwb schreef op dinsdag 23 december 2008 @ 12:49:
[...]

Hoe wil je het volgende dan met Tabs goed krijgen? Met een andere instelling voor Tabs gaat dat geheid mis

C#:

public void Method( int param1,
                    int param2 )
{
}

Ik deed dat altijd zo:

C++:

public void Method(
    int param1,    // comment1
    int param2     // comment2 
) {
    // body
}

Net als lange functie calls:

C++:

void foo() {
    long_function_call(
        param1,    // this is xxx
        param2     // use yyy
    );
}

[ Voor 15% gewijzigd door Zoijar op 23-12-2008 13:30 ]

[Eskimootje]

.oisyn schreef op maandag 22 december 2008 @ 15:15:
[...]

Ontzettend onhandig, dan laten de diffs onnodige changes zien, en wordt het integreren tussen branches een stuk lastiger.

Conclusie: formatting is geen onderdeel van je code maar is een representatie kwestie. Formatting hoort dus niet plaats in de source repository. Nu nog zorgen dat iedereen er zo mee omgaat.

[Woy]

SiliconError schreef op dinsdag 23 december 2008 @ 12:55:
[...]
Je bent die int param2 aan het uitlijnen, je moet 'm dus tabben tot aan het niveau van 'public void', mocht dat nog geindenteerd zijn, en dan van daaruit gaan uitlijnen met spaties.
Wat het probleem is... automatische tools maken er meestal alleen tabs óf alleen spaties van.

Ik reageer op het statement van link007

link0007 schreef op dinsdag 23 december 2008 @ 12:43:
Ik blijf erbij dat je nergens spaties hoeft te gebruiken voor je uitlijning of indenting, maar overal tabs.

Wat ik dus probeerde te ontkrachten. Zoijar geeft voor dit voorbeeld wel een oplossing, maar er zullen mischien ook wel weer andere voorbeelden zijn waar dit niet het geval is.

Zelf gebruik ik gewoon overal spaties.

Eskimootje schreef op dinsdag 23 december 2008 @ 13:33:
[...]

Conclusie: formatting is geen onderdeel van je code maar is een representatie kwestie. Formatting hoort dus niet plaats in de source repository. Nu nog zorgen dat iedereen er zo mee omgaat.

Op zich wel, maar de huidige tools werken gewoon niet op die manier. Ook is het lastig om een goede Code Formatter te maken die alle situaties afhandeld. Soms zal je net even iets anders willen formatten.

[ Voor 12% gewijzigd door Woy op 23-12-2008 13:55 ]

[netvor]

Eskimootje schreef op dinsdag 23 december 2008 @ 13:33:
[...]

Conclusie: formatting is geen onderdeel van je code maar is een representatie kwestie. Formatting hoort dus niet plaats in de source repository. Nu nog zorgen dat iedereen er zo mee omgaat.

Niet mee eens. Als je je code volledig vrij van representatiekwesties op wilt slaan in je repo moet je de code eigenlijk opslaan in een AST of in een soort bytecode ofzo. Dan haal je meteen ook al die nutteloze comments weg...

Waarom doen we dat niet? Omdat formatting, net als comments, ons helpt om een bepaalde intentie aan de code mee te geven. Door bijvoorbeeld in een functie één functieaanroep over meerdere regels te verdelen geven we aan dat dit het belangrijkste deel van de functie is. Door witregels in te voegen verdelen we de "tekst" in "alinea's." En ga zo maar door.

Ik snap ook wel dat er een verschil is tussen het omzetten van tabs naar spaties en het invoegen en verwijderen van witregels, maar toch zijn beiden een voorbeeld van "formatting" en geven ze, hoe impliciet ook, een bepaalde subtext van de auteur mee.

Een ander voorbeeld: veel codeformatters voegen automatisch haakjes toe aan if-statements. Of ze breken single-line if statements automatisch op in twee regels. Dat is IMHO een slechte zaak, want de manier waarop een if statement genoteerd staat zegt impliciet iets over hoe belangrijk de programmeur dit stukje code acht:

C:

if ( iets ) doeIetsSimpels();

if ( iets )
  doeIetsBelangrijkers();

if ( iets )
{
  doeIetsBelangrijks();
}

Tenminste, zo ervaar ik het als ik naar andermans code kijk. En zelf pas ik deze regels ook toe, bewust of onbewust. Ben ik hierin de enige?

[StephanVierkant]

netvor schreef op dinsdag 23 december 2008 @ 14:20:
Een ander voorbeeld: veel codeformatters voegen automatisch haakjes toe aan if-statements. Of ze breken single-line if statements automatisch op in twee regels. Dat is IMHO een slechte zaak, want de manier waarop een if statement genoteerd staat zegt impliciet iets over hoe belangrijk de programmeur dit stukje code acht:

C:

if ( iets ) doeIetsSimpels();

if ( iets )
  doeIetsBelangrijkers();

if ( iets )
{
  doeIetsBelangrijks();
}

Tenminste, zo ervaar ik het als ik naar andermans code kijk. En zelf pas ik deze regels ook toe, bewust of onbewust. Ben ik hierin de enige?

Hoe definieer je het belang van een stukje code? Bedoel je daarmee als het niet werkt, het niet zo erg is? Het criterium voor wel of geen haakjes is voor mij hoeveel code (en daarbinnen ook weer if/else bijvoorbeeld) er nog komt. Verder speelt luiheid wel een beetje mee

[netvor]

Tsja, dat is een beetje een ongrijpbaar concept, en hangt heel erg af van wat de code precies is en doet. Dingen als een flag in een loop aan- of uitzetten zou ik met de kortste notatie noteren, terwijl ik voor iets als het bijwerken van de DB de langste notatie zou gebruiken.

[ThunderNet]

Ik vind if statements zonder brackets een ramp.
Het zijn van die dingen waar je snel overheen leest en je je ineens gaat afvragen waarom de code niet doet wat je wilt als je wat dingen toegevoegd hebt.
Zeker als je met meerdere mensen in dezelfde code werkt vind ik haakjes rond if-statements een must

[Eskimootje]

Stephan4kant schreef op dinsdag 23 december 2008 @ 14:27:
[...]

Hoe definieer je het belang van een stukje code? Bedoel je daarmee als het niet werkt, het niet zo erg is? Het criterium voor wel of geen haakjes is voor mij hoeveel code (en daarbinnen ook weer if/else bijvoorbeeld) er nog komt. Verder speelt luiheid wel een beetje mee

Belangrijkheid laten blijken uit de formatting is natuurlijk weer een houtje touwtje oplossing. Dit hoort gewoon in het commentaar. Daarnaast is het verschillende manier opschrijven van dezelfde functionaliteit ook niet echt nodig, iets wat hetzelfde doet hoort er gewoon hetzelfde uit te zien.

PS. Kortgeschreven if statements zouden door de IDE omgezet moeten worden naar de standaard notatie. Als iemand het andersom prettiger vind prima, maar is een presentatie kwestie.

[ Voor 11% gewijzigd door Eskimootje op 23-12-2008 14:42 ]

[Verwijderd]

Een ander voorbeeld: veel codeformatters voegen automatisch haakjes toe aan if-statements.

Zonder brackets zijn If-statements vervelend. Het enige wat je 'wint' is een een stukje verticale ruimte in je source-file ten koste van leesbaarheid.

[netvor]

Interessant; ik lijk redelijk alleen te staan in mijn mening over korte versus lange statements. Dat terwijl de manier van werken die ik beschreef hier in het bedrijf gangbaar is. Zo zie je maar weer, dit soort kwesties zijn enorm persoonsgebonden, en zo zitten honderden programmeurs simpelweg te werken volgens de persoonlijke stijl van een langvergeten lead developer die er jaren geleden mee op de proppen is gekomen.

[.oisyn]

Verwijderd schreef op dinsdag 23 december 2008 @ 14:53:
[...]

Zonder brackets zijn If-statements vervelend. Het enige wat je 'wint' is een een stukje verticale ruimte in je source-file ten koste van leesbaarheid.

Vind je

C++:

if (bla)
    statement;

werkelijk minder leesbaar dan

C++:

if (bla)
{
    statement;
}

?

Een veel belangrijkere reden dan leesbaarheid om geen

C++:

if (bla) statement;

te gebruiken is trouwens omdat je dan geen breakpoint kunt plaatsen op 'statement'.

[ Voor 18% gewijzigd door .oisyn op 23-12-2008 15:00 ]

[Verwijderd]

netvor schreef op dinsdag 23 december 2008 @ 14:54:
Interessant; ik lijk redelijk alleen te staan in mijn mening over korte versus lange statements. Dat terwijl de manier van werken die ik beschreef hier in het bedrijf gangbaar is. Zo zie je maar weer, dit soort kwesties zijn enorm persoonsgebonden, en zo zitten honderden programmeurs simpelweg te werken volgens de persoonlijke stijl van een langvergeten lead developer die er jaren geleden mee op de proppen is gekomen.

Tuurlijk is het een persoonlijke voorkeur.
IMHO zijn brackets dé manier om stukken code die bij elkaar horen te scheiden van de rest.
Als je later nog eens iets aan je if toe moet/wilt voegen kom je er niet onderuit ze alsnog te voorzien van brackets en het is voor iemand die je code niet kent een stuk duidelijker als ze er staan

.oisyn schreef op dinsdag 23 december 2008 @ 14:56:
[...]


Vind je

C++:

if (bla)
    statement;

werkelijk minder leesbaar dan

C++:

if (bla)
{
    statement;
}

?

Ja, natuurlijk valt het in dit voorbeeld mee, maar in lappen code vind ik het veel prettiger met brackets.

[ Voor 17% gewijzigd door Verwijderd op 23-12-2008 14:58 ]

[StephanVierkant]

.oisyn schreef op dinsdag 23 december 2008 @ 14:56:
[...]


Vind je

C++:

if (bla)
    statement;

werkelijk minder leesbaar dan

C++:

if (bla)
{
    statement;
}

?

In dit geval niet, omdat het statement maar 1 regel (één woord zelfs!) is. Bij wat ingewikkeldere code kan het nogal lastig worden.

[ Voor 49% gewijzigd door StephanVierkant op 23-12-2008 14:58 ]

[.oisyn]

Stephan4kant schreef op dinsdag 23 december 2008 @ 14:58:
[...]

In dit geval niet, omdat het statement maar 1 regel (één woord zelfs!) is. Bij wat ingewikkeldere code kan het nogal lastig worden.

Ja, zodra de expressie in de if meerdere regels beslaat dan gebruik ik ook brackets hoor. Maar zonder meer zeggen dat het niet gebruiken van brackets minder leesbaar is gaat me echt te ver.

[Verwijderd]

.oisyn schreef op dinsdag 23 december 2008 @ 15:03:
[...]
Maar zonder meer zeggen dat het niet gebruiken van brackets minder leesbaar is gaat me echt te ver.

Ik vind prettiger omdat je een duidelijk kader hebt om je statement, zeker als je door code (van een ander) heen bladerd vind ik het prettiger.

[Woy]

Ik gebruik meestal wel brackets, maar bij hele simpele statements zoals hetvolgende laat ik het ook weg

C#:

if( someCheck )
    return;

Maar raken we nu niet erg offtopic , er zijn zat andere topics waar over de coding styles gediscussierd word.

[Zoijar]

Ik gebruik nooit if's zonder brackets, tenzij het even snel een hack is, die dan jaren blijft staan

Als het dan al single line moet, dan maar zo:

C++:

if (somecheck) {doiets();}

Spaties rondom ( en ) vind ik trouwens bijzonder ergerlijk

[kenneth]

Zoijar schreef op dinsdag 23 december 2008 @ 16:23:
Spaties rondom ( en ) vind ik trouwens bijzonder ergerlijk

Hahaha, ik ben gelukkig niet de enige

Nogmaals: VS.NET defaults ftw

[_Erikje_]

Wat ik hier mis is de andere "mooiere" manier

Java:

if (iets){
    doIets();
}

of

Java:

iets ? doIets(); : ietsAnders();

Daarnaast maakt het geen reet uit of je spaties of tabs gebruikt, een knappe IDE of edittor zal een tab overriden naar een x aantal spaties.
Pas als je talen als Python gaat gebruiken is het gebruik van tabs belangrijk, voor de rest is het gewoon het leesbaar maken van de code. Jammergenoeg heeft iedere ontwikkelaar een eigen definitie van 'leesbaarheid'

[Grijze Vos]

Een ternary operator met function calls als operanden vind ik toch wel heel brak hoor.

[Woy]

Grijze Vos schreef op woensdag 24 december 2008 @ 09:52:
Een ternary operator met function calls als operanden vind ik toch wel heel brak hoor.

In C# kan het overigens ook niet eens! De ternary operator is idd heel handig bij conditionele assignments, maar vind het niet zo mooi als veredelde IF inderdaad.

[ Voor 20% gewijzigd door Woy op 24-12-2008 10:25 ]

[_Erikje_]

rwb schreef op woensdag 24 december 2008 @ 10:24:
[...]

In C# kan het overigens ook niet eens! De ternary operator is idd heel handig bij conditionele assignments, maar vind het niet zo mooi als veredelde IF inderdaad.

Ik mis het altijd heel erg als ik C# aan het programmeren ben. Bij het returnen van waardes vind ik het wel handig... Maar ik bedrijp dat mensen het lastig leesbaar vinden.

[link0007]

mwah, ik gebruik het ook spaarzaam. Het is dynamischer om een switch/if statement te gebruiken, afhankelijk van wat je nodig hebt. Stel je wilt later meer doen, dan is het gewoon eenvoudiger om uit te breiden.

[Tanuki]

_Erikje_ schreef op donderdag 25 december 2008 @ 11:55:
[...]

Ik mis het altijd heel erg als ik C# aan het programmeren ben. Bij het returnen van waardes vind ik het wel handig... Maar ik bedrijp dat mensen het lastig leesbaar vinden.

Dat kan toch gewoon in C#?

C#:

public string Iets
{
    get
    {
        return ((x == y) ? "Ja" : "Nee");
    }
}

Of lees ik het nou verkeerd?

[_Erikje_]

l0c4lh0st schreef op donderdag 25 december 2008 @ 22:36:
[...]

Dat kan toch gewoon in C#?

C#:

public string Iets
{
    get
    {
        return ((x == y) ? "Ja" : "Nee");
    }
}

Of lees ik het nou verkeerd?

hmzzz, ik heb et een keer geprobeerd, en de compiler begon te janken. Nu moet ik zeggen dat ik zelden C# programmeer

[Snake]

_Erikje_ schreef op donderdag 25 december 2008 @ 23:27:
[...]


hmzzz, ik heb et een keer geprobeerd, en de compiler begon te janken. Nu moet ik zeggen dat ik zelden C# programmeer

Neen ik snap het hier ook niet, want het compileert dus wel perfect, en ik zie ook geen reden waarom het niet zou compileren.

Er zijn 2 dingen waar ik mij aan stoor bij de C# compiler:

• Geen drop trough case bij een niet lege case
• Geen mogelijkheid om een generic te beperken tot een value type. (where T : System.ValueType gaat niet.)

[Bender]

een marktplaats script van iemand op tbforum.nl bevatte deze query als authenticatie controle voor zowel; frontend als backend

PHP:

mysql_query("SELECT * FROM gebruikers WHERE id = " . $_COOKIE[id])

[MLM]

Ergens vind ik het wel mooi dat de C# IDE zelf de formatting doet, zo blijft de formatting bij iedereen hetzelfde, en geen geneuzel over tab/space zoals net even geleden.

In C++ (waar dat dus niet automatisch gaat) gebruik ik eigenlijk altijd opening en closing braces op een aparte regel, behalve waar dat disproportioneel veel verticale ruimte kost:
- een if statement met een simpele single-line then statement, maar wel de then op een eigen regel met een extra indent
- een inline class get-accessor doe ik helemaal op 1 regel in de header file

[Zoijar]

Smalltalk slaat z'n source op als xml... kan je het zelf formatten

[Verwijderd]

Snap de hele discussie over al dan niet brackets niet zo. Waarom zou je ze niet gebruiken? Het levert niets op om het niet te doen. Tja het levert verticale ruimte op, maar die is praktisch onbeperkt...

[_Erikje_]

Verwijderd schreef op vrijdag 26 december 2008 @ 12:45:
Snap de hele discussie over al dan niet brackets niet zo. Waarom zou je ze niet gebruiken? Het levert niets op om het niet te doen. Tja het levert verticale ruimte op, maar die is praktisch onbeperkt...

Het gaat om leesbaarheid van de code, en nu vindt niet iedereen hetzelfde leesbaar. Ook speelt het 1337-heidsgehalte van compacte code een rol, I think.

[roy-t]

Snake schreef op vrijdag 26 december 2008 @ 01:02:
[...]

Neen ik snap het hier ook niet, want het compileert dus wel perfect, en ik zie ook geen reden waarom het niet zou compileren.

Er zijn 2 dingen waar ik mij aan stoor bij de C# compiler:

• Geen drop trough case bij een niet lege case
• Geen mogelijkheid om een generic te beperken tot een value type. (where T : System.ValueType gaat niet.)

Je kunt zover ik weet juist wel constraints zetten op je generic, maar misschien is dit alleen C#3.0 (dus net nieuw). Je kan immers eisen waar je T van af moet stammen en System.ValueType is toch ook gewoon van een object afstammend, dus dan zou het zover ik weet gewoon moeten werken. (In Pro C# 2008 and the .Net3.5 framework staat volgens mij exact die code die je nu schrijft). Helaas niet op mijn eigen pc nu anders had ik even VS2005 en VS2008 uitgevoerd om het te proberen.

[link0007]

Triloxigen schreef op vrijdag 26 december 2008 @ 09:31:
een marktplaats script van iemand op tbforum.nl bevatte deze query als authenticatie controle voor zowel; frontend als backend

PHP:

mysql_query("SELECT * FROM gebruikers WHERE id = " . $_COOKIE\[id])

Sad but true.. zal niet de enigste zijn die het zo doet er zijn 3 dingen fout aan dat voorbeeld trouwens:
- $_COOKIE['id'] word niet naar int gecast (of opgeschoond als 't geen integer-id is)
- een wildcard om aan te geven welke tabellen je wilt selecteren vind ik een nare gewoonte.. alsof je niet weet wat je tabelnamen zijn?
- het is natuurlijk een enorm beveiligingslek om alleen het id (publieke informatie) te gebruiken als inloggegevens Gebruik dan gewoon meteen de username!

[Voutloos]

en punt 4: id is geen constante, maar je wilt het element welke de string 'id' als key heeft, dus moet je wel gewoon quotes gebruiken... Voor veel automagische conversies in PHP valt wat te zeggen (en aan de nu volgende verplichte discussie doe ik niet mee ), maar de idiote 'onbestaande-constante-naar-string'-cast moet echt eruit gehaald worden.

[link0007]

klopt, had hem nog niet eens gezien En inderdaad, vooral omdat het als notice word gezien (meen ik?) ipv als fatal error... veel mensen denken een perfect script te hebben geschreven, gewoon omdat php ze niet alle foutmeldingen geeft.

[Sebazzz]

Punt 5: Iemand zal voor de grap maar even met een webdeveloper toolbar zijn 'id' cookie aanpassen. (sql injectie)

[Robtimus]

Sebazzz schreef op vrijdag 26 december 2008 @ 19:24:
Punt 5: Iemand zal voor de grap maar even met een webdeveloper toolbar zijn 'id' cookie aanpassen. (sql injectie)

Zie punt 1: niet opschonen / casten.

[Snake]

roy-t schreef op vrijdag 26 december 2008 @ 13:20:
[...]


Je kunt zover ik weet juist wel constraints zetten op je generic, maar misschien is dit alleen C#3.0 (dus net nieuw). Je kan immers eisen waar je T van af moet stammen en System.ValueType is toch ook gewoon van een object afstammend, dus dan zou het zover ik weet gewoon moeten werken. (In Pro C# 2008 and the .Net3.5 framework staat volgens mij exact die code die je nu schrijft). Helaas niet op mijn eigen pc nu anders had ik even VS2005 en VS2008 uitgevoerd om het te proberen.

http://msdn.microsoft.com/en-us/library/56b2hk61.aspx

En

http://msdn.microsoft.com/en-us/library/0dcw7ztt.aspx

[Sebazzz]

Ik weet niet of het een slecht programmeervoorbeeld is maar ik zou dit toch anders aanpakken:
ftp://ftp.knmi.nl/pub_weerberichten/basisverwachting.xml

XML:

<verwachting type="...">....</verwachting>
<dag nummer="x">iso datum hier (dus jjjj-mm-dd)</dag>
<!--etc-->

[Tanuki]

Sebazzz schreef op zondag 28 december 2008 @ 18:52:
Ik weet niet of het een slecht programmeervoorbeeld is maar ik zou dit toch anders aanpakken:
ftp://ftp.knmi.nl/pub_weerberichten/basisverwachting.xml

XML:

<verwachting type="...">....</verwachting>
<dag nummer="x">iso datum hier (dus jjjj-mm-dd)</dag>
<!--etc-->

Ik vind het gewoon 1 grote lap ranzig opgebouwde XML.

Wat mij betreft dus perfect voor dit topic.

[link0007]

ik vind datums sowieso lastige XML zaken.. hoe doen de mensen dat hier? ik bouw het zo op:

XML:

<date type="submitted">
    <day format="d">28</day>
    <month format="m">12</month>
    <year format="Y">2008</year>
</date>

Aan de ene kant vind ik het best logisch gedaan, omdat je per element bepaald wat voor type het is, maar aan de andere kant kan het ook zo:

XML:

<date type="submitted" format="d-m-y">
    <day>28</day>
    <month>12</month>
    <year>2008</year>
</date>

Maar alhoewel dat wat attributes scheelt voor de subelementen van de date, is het wel een beetje tegen mijn principes wat betreft het doel van XML. Bij XML wil ik juist alles zo representeren dat het heel universeel is, en makkelijk om aan toe te voegen. Verder vind ik het datumformaat een onderdeel van de individuele eenheden. Dus ik vind de eerste techniek het beste. Natuurlijk zijn er nog veel meer mogelijkheden om een datum te definieren (het liefst wil je toch wel met timestamps gaan werken ), maar het gaat er hier even over hoe je dit soort datums representeert.

[MBV]

ehm, voor die weervoorspelling zou het heel simpel kunnen zijn toch?

XML:

<voorspellingen generated="2008-12-29etc">
  <voorspelling dag_relatief="-1" iso_datum="2008-12-28">
    <mm>3</mm>
    <max_temp>-2</max_temp>
    ...
  </voorspelling>
</voorspellingen>

Waarom moeilijk doen met tags die een variabele naam hebben? Hoe wil je daar ooit een XQuery o.i.d. op loslaten?
En over datumformaten: daarvoor hebben ze standaarden uitgevonden. De iso-standaard (toch?) voor datumformaat is "YYYY-MM-dd hh:mm:ss", waarbij je de streepjes mag weglaten. Doordat het een iso-standaard is moet iedereen eenvoudig kunnen achterhalen hoe hij daar zijn gegevens uit kan halen, toch?

Soms moet je de oplossing van het probleem niet moeilijker maken dan nodig, en al helemaal niet proberen 85 andere problemen op te lossen die waarschijnlijk geen probleem zijn.

[Woy]

Snake schreef op vrijdag 26 december 2008 @ 01:02:
[...]

Neen ik snap het hier ook niet, want het compileert dus wel perfect, en ik zie ook geen reden waarom het niet zou compileren.

De ternary operator word wel ondersteund natuurlijk, maar niet als statement

C#:

//Mag wel ( Mits Foo en Bar de juiste return types hebben )
int a = true ? Foo() : Bar();
//Mag niet
true ? Foo() : Bar();

Er zijn 2 dingen waar ik mij aan stoor bij de C# compiler:

[list]
• Geen drop trough case bij een niet lege case

Idd erg irritant af en toe. Maar ik snap wel dat het een hoop stomme fouten kan besparen.

• Geen mogelijkheid om een generic te beperken tot een value type. (where T : System.ValueType gaat niet.)
[/list]

Dat kan toch gewoon?

C#:

public class Foo<T> where T : struct
{
}

Dit bepertk je T als ValueType. En dat kan ook gewoon sinds de invoering van generics.

Snake schreef op vrijdag 26 december 2008 @ 23:19:
[...]
http://msdn.microsoft.com/en-us/library/56b2hk61.aspx

En

http://msdn.microsoft.com/en-us/library/0dcw7ztt.aspx

Een constraint op string is ook een beetje vreemd natuurlijk aangezien die toch sealed is, dus waarom zou je dan nog een generic class gebruiken. Even testen of je uberhaupt een sealed class als constraint kunt gebruiken. Voor array kan ik ook niet echt een goede case bedenken, je kan immers het type van de constraint gebruiken om een Array te defineren, maar mischien dat daar nog wel iets bij te bedenken zou zijn.

edit:
idd je kan een Sealed class niet als contraint gebruiken

C#:

public sealed class Foo {}
public class Bar<T> where T : Foo {}

levert de volgende error op

'Foo' is not a valid constraint. A type used as a constraint must be an interface, a non-sealed class or a type parameter

o ik zie dat dat precies de error is die in je link staat

[ Voor 37% gewijzigd door Woy op 29-12-2008 10:34 ]

[Nextron]

Iets met Zune en schrikkeljaren

C:

year = ORIGINYEAR; /* = 1980 */

while (days > 365)
{
    if (IsLeapYear(year))
    {
        if (days > 366)
        {
            days -= 366;
            year += 1;
        }
    }
    else
    {
        days -= 365;
        year += 1;
    }
}

[Grijze Vos]

Thanatoss schreef op zondag 04 januari 2009 @ 23:03:
Iets met Zune en schrikkeljaren

C:

year = ORIGINYEAR; /* = 1980 */

while (days > 365)
{
    if (IsLeapYear(year))
    {
        if (days > 366)
        {
            days -= 366;
            year += 1;
        }
    }
    else
    {
        days -= 365;
        year += 1;
    }
}

Ik herinner me levendig hoe ik zo'n soort implementatie heb gemaakt voor een boekhoud achtig tooltje op de TI-83+ (in Assembly, uiteraard). Gekke fransozen met hun rare applicatie-wensen.

[dcm360]

Eentje die ik van mezelf tegenkwam:

code:

start:=getTickCount;
repeat
  sleep(5);
  application.ProcessMessages;
  nu:=getTickCount;
until nu-start=instellingen.splashTimeOut;

Bij mijzelf en bij de andere ontwikkelaar werkte het altijd, alleen bij de klant niet... Dus we hebben een mooie workarround ontworpen, maar toen ik de code pasgeleden weer tegenkwam zag ik pas wat er mis mee was...

[Raging_Trancer]

link0007 schreef op vrijdag 26 december 2008 @ 13:56:
[...]

PHP:

<?php
mysql_query("SELECT * FROM gebruikers WHERE id = " . $_COOKIE\[id])
?>

- een wildcard om aan te geven welke tabellen je wilt selecteren vind ik een nare gewoonte.. alsof je niet weet wat je tabelnamen zijn?

Volgens mij lees je het verkeerd. Wat de query in dit geval doet is alle waarden ophalen van de user met id = "$_COOKIE[id]" uit de tabel "gebruikers".

[DamadmOO]

Raging_Trancer schreef op maandag 05 januari 2009 @ 12:43:
[...]


Volgens mij lees je het verkeerd. Wat de query in dit geval doet is alle waarden ophalen van de user met id = "$_COOKIE[id]" uit de tabel "gebruikers".

Dan nog is het gewoon slecht om een "SELECT * FROM ..." te gebruiken. Op het moment dat je de query schrijft weet je precies welke waardes je nodig hebt. Heb je een extra waarde nodig dan pas je gewoon de SELECT query aan.

En als je dan komt met als argument dat je niet 100 keer dezelfde select query wilt aanpassen dan mag je als ontwikkelaar wel eens kijken naar refactoring.

[Xiphalon]

roy-t schreef op vrijdag 26 december 2008 @ 13:20:
[...]


Je kunt zover ik weet juist wel constraints zetten op je generic, maar misschien is dit alleen C#3.0 (dus net nieuw). Je kan immers eisen waar je T van af moet stammen en System.ValueType is toch ook gewoon van een object afstammend, dus dan zou het zover ik weet gewoon moeten werken. (In Pro C# 2008 and the .Net3.5 framework staat volgens mij exact die code die je nu schrijft). Helaas niet op mijn eigen pc nu anders had ik even VS2005 en VS2008 uitgevoerd om het te proberen.

System.ValueType en System.Enum zijn gewoon reference types hoor. De classen dan. Enum en int enzo zijn wel value types

Om een value type af te dwingen kan je

code:

void Test<T>() where T: struct

gebruiken. Je kan dan alleen maar value types en structs (die ook value types zijn...) doorgeven.

[ Voor 3% gewijzigd door Xiphalon op 05-01-2009 13:11 ]

[Haan]

Raging_Trancer schreef op maandag 05 januari 2009 @ 12:43:
[...]


Volgens mij lees je het verkeerd. Wat de query in dit geval doet is alle waarden ophalen van de user met id = "$_COOKIE[id]" uit de tabel "gebruikers".

Het woord tabel is zo te zien dan ook gewoon een foutje en zou 'veld' moeten zijn.

[.oisyn]

darkmage schreef op maandag 05 januari 2009 @ 13:11:
Je kan dan alleen maar value types en structs (die ook value types zijn...) doorgeven.

Niet "ook", er bestaan geen andere value-types dan structs. Een 'int' in C# is namelijk gewoon een alias voor de struct System.Int32.

[ Voor 5% gewijzigd door .oisyn op 05-01-2009 16:21 ]

[Xiphalon]

.oisyn schreef op maandag 05 januari 2009 @ 16:19:
[...]

Niet "ook", er bestaan geen andere value-types dan structs. Een 'int' in C# is namelijk gewoon een alias voor de struct System.Int32.

True.

Ik was even confuus met de integral types (sbyte, uint) enz

[daniëlpunt]

IceManX schreef op vrijdag 26 december 2008 @ 20:14:
[...]

Zie punt 1: niet opschonen / casten.

Als ik alleen 1 in vul is het nog steeds een integer.