Verschillende programmeerstijlen; voor- en nadelen

[Mafkees]

Er zijn een heleboel verschillende programmeerstijlen die gehanteerd worden. Het is een stijl en dus eigenlijk iets persoonlijks maar hoe kom jij aan je programmeerstijl?

Het bekendste verschil in stijl is misschien wel dit:

Java:

public static void main(String args[]) {
  // code goes here
}

Java:

public static void main(String args[])
{
  // code goes here
}

het verschil in accolades. De een doet 'm op een volgende regel de ander op dezelfde. Een subtieler verschil is het spatiegebruik bij (onder andere) if statements. Bijvoorbeeld:

PHP:

if ( $foo == "bar" )
{
  // code goes here
}

PHP:

if($foo == "bar") // of mss zelfs if($foo=="bar")
{
  // code goes here
}

Een lijstje van voorbeelden, kan natuurlijk veel groter.

• accolades; op de volgende regel of dezelfde
• spatie
• het initialiseren van variabelen binnen een class (doe je dat in de constructor of direct achter de instance variabelen)
• spaties tussen argumenten naar functies/methoden
• plaatsen van commentaar; zet je dat voor de functie, voor een groot stuk code, voor van alles
• etc..

Maar hoe kom jij aan je programmeerstijl? Heb je 'm aangenomen op school omdat ze 't daar ook op een bepaalde manier doen. Heb je 't aangenomen na het programmeren van je eerste stuk code dat aan de hand van een voorbeeld ging. Misschien heb je wel een verschillende stijl per taal.

Ik wil hier een discussie opstarten over verschillende programmeerstijlen. Waarom schrijf je iets op een bepaalde manier op, wat is daar het voordeel van en wat vinden anderen daar het nadeel van. Door dit topic leer je misschien ook nieuwe dingen als je een voorbeeld ziet wat toch eigenlijk best wel erg handig is.

Brand u maar los.. je mag op mijn voorbeelden reageren

[whoami]

Dit heeft niets met software engineering & architecture te maken
-> PRG

Ik kan me trouwens herinneren dat er reeds vroeger een dergelijk topic geopend werd @Got.

[whoami]

Even in het kort: iedereen heeft z'n eigen stijl , en die stijl zal voor die persoon het beste werken. Ik zie er dus niet veel discussie-materiaal in ? Maar goed, het voordeel van de twijfel dan maar....

In ieder geval ben je niet altijd toegestaan om met je eigen stijl te werken: denk maar aan coding guidelines / standards binnen een bedrijf.

Voor C# volg ik trouwens min of meer de MS guideline.

[Mafkees]

Deze post even ter verduidelijking...

whoami schreef op donderdag 25 januari 2007 @ 16:03:
Even in het kort: iedereen heeft z'n eigen stijl , en die stijl zal voor die persoon het beste werken. Ik zie er dus niet veel discussie-materiaal in ? Maar goed, het voordeel van de twijfel dan maar....

In ieder geval ben je niet altijd toegestaan om met je eigen stijl te werken: denk maar aan coding guidelines / standards binnen een bedrijf.

Voor C# volg ik trouwens min of meer de MS guideline.

Heb je gelijk in, het is iets persoonlijks. Ik zou alleen graag willen weten waarom men op een bepaalde manier iets opschrijft. Wat vinden zij daar het voordeel van en daarom misschien iets om over te nemen

[ Voor 11% gewijzigd door Mafkees op 25-01-2007 16:06 ]

[Rowdy.nl]

Het is persoonlijk denk ik, ik vind het prettig om op deze manier te programmeren, dus zonder spaties eromheen, maar wel tussen de variabelen, en met accolades eronder. Collega's doen het weer helemaal anders, dus soms kom ik in code nog wel wat verschillen tegen...

PHP:

if($foo == "bar")
{
  // code goes here
}

Echter Visual Studio 2005 doet standaard spaties eromheen zetten in een if statement (zal vast wel te configgen zijn, stoort me niet zo)

C#:

if( foo == "bar" )
{
  // code goes here
}

Edit, waarom?
Waar het mij om gaat is dat ik in elk geval de accolades onder elkaar heb staan, en dan de code met tabs ingesprongen. Vind ik persoonlijk duidelijker, ander zie ik niet zo snel waar het if statement begint...

[ Voor 17% gewijzigd door Rowdy.nl op 25-01-2007 16:21 ]

[NMe]

Rowdy.nl schreef op donderdag 25 januari 2007 @ 16:19:
Het is persoonlijk denk ik, ik vind het prettig om op deze manier te programmeren, dus zonder spaties eromheen, maar wel tussen de variabelen, en met accolades eronder. Collega's doen het weer helemaal anders, dus soms kom ik in code nog wel wat verschillen tegen...

Dat vind ik best kwalijk, als jullie tenminste aan dezelfde projecten werken.

[Megamind]

Het is ook persoonlijk, ik gebruikte altijd de 1e notatie, maar nu ben ik ook overstag gegaan en programmeer alleen nog maar in de 2e stijl, haken onder statements en spaties, als je een lap code wordt zit je zo te priegelen anders.

[Janoz]

[Alg] Programmeerstijl*


Belangrijkste is niet welke keuze je maakt, maar dat iedereen op je werk/project dezelfde keuze maakt, afgedwongen en vastgelegd in een codestyle (dit kan eventueel door een config bestandje van je IDE, zolang iedereen maar dezelfde heeft).

@.oisyn: Spaties is nog wel te overzsien, maar als je binnen hetzelfde project de ene keer de accolades op dezelfde regel zet en de volgende keer de volgende regel kiest. Daarnaast wil automatische layout van code het versiebeheer systeem ook wel eens compleet onoverzichtelijk maken.

[ Voor 33% gewijzigd door Janoz op 25-01-2007 16:26 ]

[.oisyn]

-NMe- schreef op donderdag 25 januari 2007 @ 16:21:
[...]

Dat vind ik best kwalijk, als jullie tenminste aan dezelfde projecten werken.

Onzin. Het wordt pas kwalijk als iedereen andere naming conventions aanhoudt. Maar of de ene nou een spatie voor of achter de ( tikt maakt natuurlijk geen drol uit.

[Dido]

Veel keus heb ik over het algemeen niet...

code:

IF         COND('#FOO *EQ ''BAR''')
********** CODE GOES HERE
ENDIF

Nu vind ik dit soort uiterlijke dingetjes trowuens minder interessant dan echte programmeerstijlverschillen. Die liggen echter vaak vast in standaards, dus heb je alleen wat aan een persoonlijke stijl als je wat voor jezelf doet.

[Zyppora]

Ik ben zelf vrij consistent:

Java:

public static void main (String args[]) {
  String x = "";
  if (x == "bla") { doY(); }
  else { doZ(); }

  if (x == "bla2") {
    doOneThing("first", "second");
    doAnotherThing();
  } else {
    doSomethingElse();
  }
}

Of ik mijn variabelen binnen de class of method zet, heeft vooral te maken met waar ik ze nodig ga hebben. Commentaar do ik op aparte regels tussen /* en */, behalve als het kort genoeg is om achter // op dezelfde regel te zetten.

[Anoniem: 129028]

.oisyn schreef op donderdag 25 januari 2007 @ 16:24:
[...]

Onzin. Het wordt pas kwalijk als iedereen andere naming conventions aanhoudt. Maar of de ene nou een spatie voor of achter de ( tikt maakt natuurlijk geen drol uit.

Daar ben ik het toch niet mee eens. Ik vind bijvoorbeeld

x = func( a, b, func2( c, d / 5 ) * func3( e, f ));

veel leesbaarder dan

x=func(a,b,func2(c,d/5)*func3(e,f));

Verder kun je door plaatsing van spaties/tabs/haakjes duidelijk aangeven wat je aan het doen bent. Denk aan: casts in Java/C/C++, declaraties van pointers en arrays of functie pointers. In dat soort gevallen maakt het echt wel uit waar je je spaties zet, naar mijn mening. Of neem hele lange statements: breek je die op in meerdere regels? Zet je dan komma's onder elkaar, of operators? Etc. etc.

Als je allemaal dezelfde conventie gebruikt, wordt je code niet alleen netter en mooier, maar ook leesbaarder. Dat geldt ook voor een buitenstaander die je code voor het eerst ziet, zelfs als die eerst moet wennen aan de gebruikte conventie.

[NMe]

.oisyn schreef op donderdag 25 januari 2007 @ 16:24:
[...]

Onzin. Het wordt pas kwalijk als iedereen andere naming conventions aanhoudt. Maar of de ene nou een spatie voor of achter de ( tikt maakt natuurlijk geen drol uit.

C++:

/* dit is een functie */
void doeIets(int var){
  if(blaat==12){
    doeWatAnders();
  }
}

// dit is nog een functie
void doeWatAnders ( void )
{
  if ( global . x == 12 )
  {
    doeNogWat ( );
  }
}

Als ik in één project (of erger nog: file) zo'n verschillend uitziende code zie gaat het bij mij anders aardig kriebelen. Ik vind het onprofessioneel en knullig overkomen.

[Anoniem: 147846]

Ik wil het beide overzichtelijk en compact hebben. Dus ik programmeer liever zonder de extra spaties, en de acolade na een if statement komt op dezelfde regel.

White spaces ben ik echter niet zuinig mee. Een if statement ziet er bij mij zo uit:

C++:

if (check1 == check2) {

   cout << "blaat!" << endl;

} else {

   cout << "blaat2!" << endl;

}

De white spaces maken het wel minder compact, maar ik vind het wel een stuk overzichtelijker. En de extra spaties helpen daar bij mij niet echt bij.

Iedereen zijn eigen stijl.

[_Thanatos_]

Een intelligente syntaxhighlighter en intellisense/code-insight helpt ook voor de leesbaarheid. VS2005 gaat nog wat verder: je definieert hoe je code eruit moet zien en je kan letterlijk binnen 2 seconden een hele file reformatten zoals jij het gedefinieerd hebt. Dus of andermans stijl leesbaar is of niet, is dan opeens veel minder boeiend.

[Janoz]

_Thanatos_ schreef op donderdag 25 januari 2007 @ 17:09:
Een intelligente syntaxhighlighter en intellisense/code-insight helpt ook voor de leesbaarheid. VS2005 gaat nog wat verder: je definieert hoe je code eruit moet zien en je kan letterlijk binnen 2 seconden een hele file reformatten zoals jij het gedefinieerd hebt. Dus of andermans stijl leesbaar is of niet, is dan opeens veel minder boeiend.

Zit dat pas in vs2005? Dergelijke technieken gebruik ik zelf al 5 jaar in IntelliJ en Eclipse.

[Creepy]

_Thanatos_ schreef op donderdag 25 januari 2007 @ 17:09:
Een intelligente syntaxhighlighter en intellisense/code-insight helpt ook voor de leesbaarheid. VS2005 gaat nog wat verder: je definieert hoe je code eruit moet zien en je kan letterlijk binnen 2 seconden een hele file reformatten zoals jij het gedefinieerd hebt. Dus of andermans stijl leesbaar is of niet, is dan opeens veel minder boeiend.

Ben ik niet met je eens omdat een gemiddeld versiebeheer systeem dan niet meer kan zien welke regels er nu wel en niet gewijzigd zijn en het gehele bestand als gewijzigd zal zien. Je history in combinatie met diff functionaliteiten zijn dan ineens redelijk waardeloos zijn geworden.

Een redelijk consistente stijl tussen collega's is wel hierdoor wel degelijk van belang.

[ Voor 3% gewijzigd door Creepy op 25-01-2007 17:17 ]

[_Thanatos_]

Nou Janoz, dan weet jij wat ik bedoel

Ben ik niet met je eens omdat een gemiddeld versiebeheer systeem dan niet meer kan zien welke regels er nu wel en niet gewijzigd zijn en je history in combinatie met diff functionaliteiten redelijk waardeloos zijn geworden.

Dan zou je je kunnen voorstellen dat het versiebeheersysteem zelf de code formatteert met een algemene stijl. Alleen met webforms heb je dan een probleem, omdat je bij reformatting onbedoelde whitespace kan krijgen.

[ Voor 85% gewijzigd door _Thanatos_ op 25-01-2007 17:19 ]

[Black Hawk]

Zoals al eerder gezegd, het is net wat je fijner vindt om te lezen/schrijven.

Hier een voorbeeldfunctie van PHP van mijn stijl

PHP:

    /**
     * Controleert of de gebruiker en het bestand al gekoppeld zijn
     *
     * @param Integer $gebruikersID
     * @param Integer $bestandsID
     * @return Boolean
     */
    function isGekoppeld( $gebruikersID, $bestandsID )
    {
        if ( ! ( $gebruikersID || $bestandsID ) )
        {
            echo "Onjuiste parameters !! (function isGekoppeld -- bestanden.php)";
            return -1;
        }
        else
        {
            $result = mysql_fetch_assoc( query( maakSelect( GEBRUIKER_BESTAND, "COUNT(*) as aantal", 
                                                            "WHERE gebruikersID = " . $gebruikersID . 
                                                            " AND bestandsID = " . $bestandsID ) ) );
            return ( $result['aantal'] > 0 );
        }   
    }

Ik gebruik deze stijl de (volgens sommige) extra spaties en de accolades op een nieuwe regel. Dit vindt ik veel leesbaarder. Een voordeel van de accolades: bij alle accolades die je opent, kun je (visueel) makkelijk zien of deze ook allemaal gesloten zijn, dit wordt vooral zichtbaar gemaakt door het inspringen met tabs.

[Mafkees]

Black Hawk schreef op donderdag 25 januari 2007 @ 17:17:
Zoals al eerder gezegd, het is net wat je fijner vindt om te lezen/schrijven.

Hier een voorbeeldfunctie van PHP van mijn stijl

PHP:

...

Ik gebruik deze stijl de (volgens sommige) extra spaties en de accolades op een nieuwe regel. Dit vindt ik veel leesbaarder. Een voordeel van de accolades: bij alle accolades die je opent, kun je (visueel) makkelijk zien of deze ook allemaal gesloten zijn, dit wordt vooral zichtbaar gemaakt door het inspringen met tabs.

Klopt idd.. Dat is ook de voornaamste reden dat ik op een nieuwe regel begin met een accolade. Doe je dat niet dan kun je het ook wel zien aan het inspringen misschien maar accolade bij accolade zoeken vind ik toch wat makkelijker

[whoami]

Creepy schreef op donderdag 25 januari 2007 @ 17:16:
[...]

Ben ik niet met je eens omdat een gemiddeld versiebeheer systeem dan niet meer kan zien welke regels er nu wel en niet gewijzigd zijn en het gehele bestand als gewijzigd zal zien. Je history in combinatie met diff functionaliteiten zijn dan ineens redelijk waardeloos zijn geworden.

Ik zou dit eens moeten checken, maar ik denk niet dat VS.NET 2005 die 'reformatting' als een wijziging aanschouwt. Het zou kunnen zijn dat het gewoon een andere manier van presenteren is, zonder dat de code als dusdanig als gewijzigd wordt beschouwd. In dat geval ga je dus ook die wijzingen niet in je VCS hebben.

edit
hmm, het wordt idd toch als een wijziging beschouwd.

[ Voor 3% gewijzigd door whoami op 25-01-2007 17:56 ]

[Anoniem: 140111]

Java:

public class FooBar {

    private int fooBar;

    public setFooBar(int newFooBar) {
        this.fooBar = newFooBar;
    }

    public void getFooBar() {
        return this.fooBar;
    }

    public void loopBar() {
        for(int i = 0; i < 10; i++) {
            System.out.println("Teller: "+ i);
        }
    }
    
    public void bullBar(int bull, int cow) {
        if(bull == cow) {
            System.out.println("WTF?");
        }
    }
}

Tot nu toe altijd, min of meer, deze stijl aangehouden, vind het persoonlijk fijner lezen dan:

Java:

public void bullBar(int bull, int cow) 
{
     //bla
}

Maar zoals al eerder aangekaart is; het draait voornamelijk om persoonlijke voorkeur. Aangezien ik nog geen grootschalige projecten heb gedaan heb ik me ook nog niet echt hoeven storen aan andermans voorkeur

[.oisyn]

Anoniem: 129028 schreef op donderdag 25 januari 2007 @ 16:36:
[...]


Daar ben ik het toch niet mee eens. Ik vind bijvoorbeeld

x = func( a, b, func2( c, d / 5 ) * func3( e, f ));

veel leesbaarder dan

x=func(a,b,func2(c,d/5)*func3(e,f));

Dat was het hele punt niet.

Ik zal er echt niet wakker van liggen as iemand func(aap) of func (aap) of func( aap ) schrijft. Of int* i of int * i. Lekker boeiend, het is vrij duidelijk wat er staat .

[ Voor 21% gewijzigd door .oisyn op 25-01-2007 18:32 ]

[.oisyn]

whoami schreef op donderdag 25 januari 2007 @ 17:45:
[...]

Ik zou dit eens moeten checken, maar ik denk niet dat VS.NET 2005 die 'reformatting' als een wijziging aanschouwt.

Er zijn wel meerdere sourcecontrol paketten dan die van vs.net . Over het algemeen doen ze line-diffs, dus dat soort wijzigingen zijn fataal.

[CubicQ]

Een nadeel van automatisch je code aan laten passen door een beautifier is dat het soms wel handig is om bewust van een regel af te wijken, en dat kan zo'n ding niet.

Zelf pas ik me gewoon aan aan het project waar ik op werk. Op het werk hebben we een standaard, en daar gebruik ik die standaard dus ook gewoon.

Wanneer je over dit onderwerp trouwens meer wilt lezen: lees Code Complete! Over dit onderwerp weet de auteur gewoon een compleet hoofdstuk over vol te pennen, incl. redenaties wat de voor en nadelen zijn van de verschillende stijlen.

[Recursio]

Wat ik graag doe, en wat ik een paar dagen geleden nog iemand zag beschrijven als 'ranzig', is de (Hongaarse?) notatie in variabelen waarbij (in mijn stijl) 3 karakters vooraan mijn variabele-naam aangeven welk datatype erin *hoort* te zitten. Dit scheelt me soms tijd bij het debuggen, en het leest sneller in de zin dat ik niet uit de context hoef af te leiden wat het datatype is / moet zijn.

In PHP bijvoorbeeld:

$strUserFirstName = "John";
$intUserID = 1;
$blnUpdated = 0;

[Anoniem: 125106]

Het enige wat belangrijk is, is dat je consistent bent in je stijlgebruik.
Ik persoonlijk volg de "goeie oude" K&R stijl (met dan ook de curly bracket vlak na de functienaam ipv op een nieuwe regel).
Tip: gebruik astyle.
Met astyle kan je makkelijk wisselen van één bepaalde stijl naar een andere.
Er zitten een paar klassiekers ingebouwd, of je kan ook helemaal je eigen stijl aanmaken, precies zoals jij het wil.

[Ives]

Ik gebruik voor mijn projecten een simpele notatie. voor alle variabelen, klassen, functies, enums, etc typ ik de variabelnaam in kleine letters, en capitaliseer (is dat een woord?) ik de eerste letter van elk nieuw woord binnen de naam (bv. inGameLoop, xCounter,...). Voor haakjes gebruik ik

C++:

class someClass
{
   public:
      someClass();
      ~someClass();
   private:
      int xCounter;
};

Omdat je zo (als je verschillende nested loops hebt) goed kan zien wat waarbij hoort. (Wat niet wil zeggen dat ik niet af en toe commentaar na elk haakje toevoeg. Bv

C++:

for(int i = 0; i < 100; i++)
{
   for(int y = 0; y < 100; y++)
   {
      for(int x = 0; x < 100; x++)
      {
         buffer[x][y] = array[i]; // geen idee wat dit doet, ik moest gewoon een voorbeeld 
                                  // hebben met veel loops
      } // end for x
   } // end for y
} // end for i

[.oisyn]

Ives schreef op donderdag 25 januari 2007 @ 20:56:
typ ik de variabelnaam in kleine letters, en capitaliseer (is dat een woord?) ik de eerste letter van elk nieuw woord binnen de naam (bv. inGameLoop, xCounter,...)

camelCasing

[XWB]

Veel spaties enzo, vind ik veel vlotter lezen.

PHP:

$aData = array ( 5, 6, 8 );

foreach ( $aData as $iNumber )
{
    var_dump ( $iNumber );
}

[ Voor 69% gewijzigd door XWB op 25-01-2007 21:30 ]

[BalusC]

whoami schreef op donderdag 25 januari 2007 @ 16:03:
In ieder geval ben je niet altijd toegestaan om met je eigen stijl te werken: denk maar aan coding guidelines / standards binnen een bedrijf.

Dat is bij mijn werk dus het geval Helaas doen niet alle collega's daar netjes aan mee. Maar met Jalopy kunnen we veel bereiken Ik probeer in ieder geval zoveel mogelijk te coden naar de richtlijnen van het bedrijf of zelfs die van de klant, voorzover aanwezig, wat ook het geval is in de huidige projecten.

Mijn eigen codestijl wijkt in principe weinig af van die van het bedrijf, maar voor hobbyprojectjes neem ik bijna automatisch de huidige codeguidelines van het bedrijf over. Ik zal niet opkijken als mijn stijl in de toekomst weer mee-verandert wanneer de codeguidelines van het bedrijf of de klant veranderen.


Overigens is het volgens Sun's eigen richtlijnen netter om de array operator bij de type te declareren ipv bij de variabele Zo dus:

Java:

public static void main(String[] args) {
    // Blaat.
}

[Mafkees]

Recursio schreef op donderdag 25 januari 2007 @ 19:16:
Wat ik graag doe, en wat ik een paar dagen geleden nog iemand zag beschrijven als 'ranzig', is de (Hongaarse?) notatie in variabelen waarbij (in mijn stijl) 3 karakters vooraan mijn variabele-naam aangeven welk datatype erin *hoort* te zitten. Dit scheelt me soms tijd bij het debuggen, en het leest sneller in de zin dat ik niet uit de context hoef af te leiden wat het datatype is / moet zijn.

In PHP bijvoorbeeld:

$strUserFirstName = "John";
$intUserID = 1;
$blnUpdated = 0;

Naar mijn mening ook handig, ik gebruik het echter alleen in C++, en misschien in Java als ik dat weer ga programmeren.. Ik gebruik 't op deze manier:

C++:

int m_iCounter = 0; // member, int, beschrijving
int i_counter = 0; // int, beschrijving (dus geen member)
string m_sText = "baa"; // member, string, beschrijving
SomeObject * m_pObject; // member, pointer, beschrijving

[Gomez12]

Recursio schreef op donderdag 25 januari 2007 @ 19:16:
Wat ik graag doe, en wat ik een paar dagen geleden nog iemand zag beschrijven als 'ranzig', is de (Hongaarse?) notatie in variabelen waarbij (in mijn stijl) 3 karakters vooraan mijn variabele-naam aangeven welk datatype erin *hoort* te zitten. Dit scheelt me soms tijd bij het debuggen, en het leest sneller in de zin dat ik niet uit de context hoef af te leiden wat het datatype is / moet zijn.

In PHP bijvoorbeeld:

$strUserFirstName = "John";
$intUserID = 1;
$blnUpdated = 0;

IMHO is dit heel handig in strong-typed programmeertalen. Maar in bijv. php vind ik dit alleen maar nadelig omdat ik van een variabele $intUserID verwacht dat het een integer is ( en er dus met debuggen ook vanuit ga dat het een integer is ) terwijl het dat helemaal niet hoeft te zijn. Praktijkvoorbeeldje wat ik laatst zag en waar ik ongeveer een half uur heb lopen debuggen : in een boolean variabele de string-waarde "False" gooien, ik zag maar niet waarom dat altijd true was totdat ik uiteindelijk eens de letterlijke waarde van de boolean variabele ging echoen, toen bleek dat in de laatste check er een string waarde werd ingevuld ipv boolean waarde. Altijd leuk om 99x een boolean waarde ingevoerd te zien worden en 2x een string waarde waardoor het helemaal geen boolean meer was.

[PrisonerOfPain]

Mafkees schreef op donderdag 25 januari 2007 @ 22:28:
Naar mijn mening ook handig, ik gebruik het echter alleen in C++, en misschien in Java als ik dat weer ga programmeren.. Ik gebruik 't op deze manier:

In C++ gebruik ik het enkel om de "scope" van de variabelen aan te geven g_ voor global scope, m_ voor member variables, l_ voor locale variabelen en a_ voor functie argumenten. Het type komt er niet bij omdat dat al aangegeven staat bij de type declaratie [en duidelijk zichtbaar is in de debugger].

Lees voer: http://www.joelonsoftware.com/articles/Wrong.html

[JeromeB]

Ik vind die Hongarian Notation (ik doel dus op dat type-prefixen) gewoon irritant. Als ik bijvoorbeeld later het type van een variabele of functie wil wijzigen dan ziet het er suf uit als de naam een verkeerde prefix heeft. Natuurlijk is het mogelijk om de naam van de variabele of functie te wijzigen (met een handige IDE gaat dat ineenkeer), maar dat is extra werk.

[ Voor 5% gewijzigd door JeromeB op 26-01-2007 00:27 ]

[.oisyn]

Gomez12 schreef op donderdag 25 januari 2007 @ 23:32:
[...]


IMHO is dit heel handig in strong-typed programmeertalen. Maar in bijv. php vind ik dit alleen maar nadelig omdat ik van een variabele $intUserID verwacht dat het een integer is ( en er dus met debuggen ook vanuit ga dat het een integer is ) terwijl het dat helemaal niet hoeft te zijn.

Juist andersom. In strong typed talen boeit het niet, omdat je het type al af kunt lezen van, jawel, het type. Het is dus nutteloze informatie.

In een scripttaal is het wel nuttig, aangezien er dan geen declaratie is met een bepaald type. Het kan dus alles zijn, en daarom zou het evt handig kunnen zijn om aan te geven hoe je een variabele gebruikt. Ja, het kan wat anders zijn, maar dat is dan een bug - of je hebt er iets verkeerds ingestopt, of je hebt de variabele een verkeerde naam gegeven. Dus zoals in het zojuist aangehaalde artikel ook al wordt gezegd: je kan beter semantische informatie aan de variabele koppelen, niet iets dat je al ergens anders van af kunt leiden.

Zelf geloof ik simpelweg meer in gewoon duidelijke variabelenamen

[JKVA]

CubicQ schreef op donderdag 25 januari 2007 @ 19:02:
Een nadeel van automatisch je code aan laten passen door een beautifier is dat het soms wel handig is om bewust van een regel af te wijken, en dat kan zo'n ding niet.

Zelf pas ik me gewoon aan aan het project waar ik op werk. Op het werk hebben we een standaard, en daar gebruik ik die standaard dus ook gewoon.

Wanneer je over dit onderwerp trouwens meer wilt lezen: lees Code Complete! Over dit onderwerp weet de auteur gewoon een compleet hoofdstuk over vol te pennen, incl. redenaties wat de voor en nadelen zijn van de verschillende stijlen.

Ik denk dat er niet echt voor en nadelen zijn van een bepaalde stijl. Ik heb bijna alle stijlen ondertussen volgens mij wel gehad en elke keer was het weer ff wennen, maar na een dag weet je niet beter en is die huidige stijl de fijnste.
Het is maar net wat je gewend bent.

Ps. Juist om die eerste dagen door te komen en voor mensen die zich niet gemakkelijk aan kunnen passen, heeft Sun voor Java bijvoorbeeld al conventies opgesteld. De laatste tijd werk ik eigenlijk altijd volgens die conventies en dat bevalt prima, zeker als je andermans code leest die dankzij die conventies er ongeveer hetzelfde uitziet.

offtopic:
Wil niet zeggen dat ik vind dat formatting thuishoort in een codebestand, maar dat het een presentatieding van je IDE zou moeten zijn dat bijvoorbeeld niet in versiebeheer komt te staan. Dat is nog beter, want dan gebruikt iedereen zijn eigen voorkeuren en wordt andermans code ook volgens die instellingen getoond. Jammergenoeg nog nooit zoiets gezien...

[Ives]

.oisyn schreef op donderdag 25 januari 2007 @ 21:17:
[...]
camelCasing

Ik wist dat het iets met een kameel te maken had, camelHump of bump of whatever....

[JKVA]

Ives schreef op vrijdag 26 januari 2007 @ 07:32:
[...]

Ik wist dat het iets met een kameel te maken had, camelHump of bump of whatever....

Jup, camelCase. En .NETters gebruiken PascalCase. Komt ongeveer op hetzelfde neer, behalve dat de eerste letter ook een hoofdletter is.

[Rowdy.nl]

-NMe- schreef op donderdag 25 januari 2007 @ 16:52:
[...]

C++:

/* dit is een functie */
void doeIets(int var){
  if(blaat==12){
    doeWatAnders();
  }
}

// dit is nog een functie
void doeWatAnders ( void )
{
  if ( global . x == 12 )
  {
    doeNogWat ( );
  }
}

Als ik in één project (of erger nog: file) zo'n verschillend uitziende code zie gaat het bij mij anders aardig kriebelen. Ik vind het onprofessioneel en knullig overkomen.

Sja, dat kwam wel eens voor, werk nu niet meer met die collega samen. Maar het was altijd heel makkelijk, de formattering van VS vond mij lief... En de collega waar ik nu mee werk doet het gelukkig op dezelfde manier.

Ansich kun je dus makkelijk een document laten formatteren, zodat je in een document dezelfde stijl hebt. Blijft alleen het irritante feit van commentaar. Onduidelijk, geen of nog erger:

C#:

// Create variable
int iCounter;

Anoniem: 129028 schreef op donderdag 25 januari 2007 @ 16:36:
[...]


Daar ben ik het toch niet mee eens. Ik vind bijvoorbeeld

x = func( a, b, func2( c, d / 5 ) * func3( e, f ));

veel leesbaarder dan

x=func(a,b,func2(c,d/5)*func3(e,f));

Teveel spaties maakt het naar mijn mening niet leesbaarder... En je bent ook niet consistent, als je overal spaties gebruikt, waarom dan tussen de functie en het haakje niet, en ook niet tussen de twee haakjes achteraan? (typo?)

En in een goede editor maakt het al minder uit; je hebt dan code highlighting, dus zie je zowieso al meer verschil:

C++:

x=func(a,b,func2(c,d/5)*func3(e,f));

Anoniem: 129028 schreef op donderdag 25 januari 2007 @ 16:36:
[...]
Als je allemaal dezelfde conventie gebruikt, wordt je code niet alleen netter en mooier, maar ook leesbaarder. Dat geldt ook voor een buitenstaander die je code voor het eerst ziet, zelfs als die eerst moet wennen aan de gebruikte conventie.

Klopt, maar als jij constant na moet denken en je code moet aanpassen omdat je er rekening mee moet houden voor een buitenstaander ben je ook niet productief bezig..

In een bedrijfsomgeving moet je wel afspraken hebben zoals de benoeming van variabelen, (camelCasing, Hongaars ed) omdat je collega's er mee moeten werken, maar verder; als het erg duidelijk is voor jou, is op dat moment het belangrijkste; immers, als je er niet over hoeft na te denken ben je sneller en dus productiever. Spaties, accolades, willen ze het op een andere manier? Gebruik maar een beautifier. Er is namelijk een verschil tussen rekening houden met en je compleet aanpassen ten koste van...

CubicQ schreef op donderdag 25 januari 2007 @ 19:02:
[...]
Wanneer je over dit onderwerp trouwens meer wilt lezen: lees Code Complete! Over dit onderwerp weet de auteur gewoon een compleet hoofdstuk over vol te pennen, incl. redenaties wat de voor en nadelen zijn van de verschillende stijlen.

Linkje...?

JKVA schreef op vrijdag 26 januari 2007 @ 08:22:
[...]

Jup, camelCase. En .NETters gebruiken PascalCase. Komt ongeveer op hetzelfde neer, behalve dat de eerste letter ook een hoofdletter is.

Hmm... Ik gebruik nu al een aantal jaar .NET, maar iig geen PascalCase... Lekker camelCase... Vind de eerste niet uitzien...

[ Voor 6% gewijzigd door Rowdy.nl op 26-01-2007 09:15 ]

[JeroenTheStig]

Een stijl die ik zelf gebruik binnen Java is bij membervariables een underscore te gebruiken als prefix. Dus:

Java:

class Foo {
  private int _bar;

  public Foo(int bar) {
    _bar = bar;
  }
}

Voordelen hiervan vind ik dat je direct ziet of je met een local of een member te maken hebt. Ook bij codecompletion is het een voordeel wanneer je op zoek bent naar een membervariable.

[farlane]

.oisyn schreef op vrijdag 26 januari 2007 @ 00:38:
Juist andersom. In strong typed talen boeit het niet, omdat je het type al af kunt lezen van, jawel, het type. Het is dus nutteloze informatie.
Zelf geloof ik simpelweg meer in gewoon duidelijke variabelenamen

Daar ben ik het roerend mee eens ! Die prefix is echt compleet overbodig omdat je en ieder IDE simpelweg een RMB->Goto Definition of zoiets kan doen als je het type wilt weten.

bijv:

C++:

int AnalyzeThis( LPCWSTR p_lpwcwstrI )
{
    ....
}

Dan denk ik tja, dat het over een parameter met type LPCWSTR ging had ik al gezien maar vertel me liever wat de functie doet en wat ik voor die parameter moet gebruiken.

[JKVA]

Los van camelcase, pascalcase of hungarian vind ik de taalkeuze en variabele/methode/klassenamen nog veel belangrijker. De IDE komt toch case insensitive met code completion.

Constant verschillen tussen Engels en Nederlands vind ik veel ernstiger, of de ene die een methode altijd met find prefixed, een andere met search en weer een ander met get. Dan ben je echt de kluts snel kwijt.

En ja, zulke verschillende programmeerstijlen zie ik regelmatig.

[rrrandy]

Bij mij op het werk gebruiken we Eclipse icm de checkstyle-plugin. Daarvoor hebben we onze eigen checkstyle samengesteld. Daarnaast gebruiken we een eigen codeformatter. Wel zo handig, dwingt iedereen om netjes te programmeren en de code blijft wat dat betreft consistent. Netjes en het oogt wat professioneler.

Naast de hier beschreven stijlen gebruiken we de checkstyle ook voor het aangeven van ongebruikte variabelen, duplicate code checks, cyclomatic complexity, n-point of return checks en ga zo maar door.

Erg handig.

[JKVA]

rrrandy schreef op vrijdag 26 januari 2007 @ 15:09:
Bij mij op het werk gebruiken we Eclipse icm de checkstyle-plugin. Daarvoor hebben we onze eigen checkstyle samengesteld. Daarnaast gebruiken we een eigen codeformatter. Wel zo handig, dwingt iedereen om netjes te programmeren en de code blijft wat dat betreft consistent. Netjes en het oogt wat professioneler.

Naast de hier beschreven stijlen gebruiken we de checkstyle ook voor het aangeven van ongebruikte variabelen, duplicate code checks, cyclomatic complexity, n-point of return checks en ga zo maar door.

Erg handig.

Dat is waar, tot mensen zelf gaan beslissen die checkstyle bestanden lokaal aan te passen. Die eigenwijze figuren heb ik ook genoeg gezien. (ben er zelf ook eentje geweest )

Dan wordt op de centrale server wel de goede configuratie aangehouden, maar is er één projectlid waarvan alle code afwijkt. Heel vervelend...

Technisch gezien werkt het prima, maar IT-ers zitten vreemd in elkaar.

[momania]

rrrandy schreef op vrijdag 26 januari 2007 @ 15:09:
Daarnaast gebruiken we een eigen codeformatter.

Hier ook idd, even crtl+shift+F en voila, code is formatted volgens gezamelijke regels.

[Mafkees]

Boktor schreef op vrijdag 26 januari 2007 @ 09:16:
Een stijl die ik zelf gebruik binnen Java is bij membervariables een underscore te gebruiken als prefix. Dus:

Java:

class Foo {
  private int _bar;

  public Foo(int bar) {
    _bar = bar;
  }
}

Voordelen hiervan vind ik dat je direct ziet of je met een local of een member te maken hebt. Ook bij codecompletion is het een voordeel wanneer je op zoek bent naar een membervariable.

Daarvoor gebruik ik in m'n methodes altijd 'this'. In java bijvoorbeeld this.username, in php wordt het $this->username. Is misschien iets meer werk voor de compiler maar goed ... stelt ook weinig voor

[mithras]

Ik probeer met mn code de php.net manual voorbeeld stijl aan te houden:

PHP:

class foo {
   function foo() {
      $this->do_something("bar");
   }

   function do_something($variable) {
      echo $variable;
   }
}

Dus mét een spatie tussen () en {} en de accolades wel op dezelfde regel houden. Ook geen camelCase maar lekker under_score gebruiken. Qua leesbaarheid verschilt het niet zo, het is gewoon wennen, maar dan maakt het niet veel uit.

Verder houd ik me ook niet aan specifieke voorvoegsels voor variabelen als ze van een bepaalde type zijn. Als je (ik werk eigenlijk alleen OOP) binnen je classe een duidelijke beschrijving houd van je variabelen en functies, ben je ook klaar.
Een goede IDE die een automatische bookmark maakt bij het begin van een functie of declaratie van een variabele doet dan de rest

PHP:

/**
 * The default folder to extract the archive to
 * @var string
 */
var $default_folder

/**
 * Decompresses a given archive to a given location. If path of
 * archive and location to extract don't exist: return false
 * @param string $archive_path
 * @param string $return_folder
 * @return bool
 */
function decompress($archive_path, $return_folder=$this->default_folder){
  do_something();
}

Wat ik dan snel erg vervelend vinden is wanneer je een klasse adept van iemand die dus een hele andere conventie erop na houd. De spaties boeien niet zo, de accolades kijk ik wel omheen, maar vooral variabelen volgens camelCase brrrrr

[ Voor 8% gewijzigd door mithras op 26-01-2007 16:28 ]

[Anoniem: 147846]

Overgens hou ik er van om mijn variablen zo aan te maken:

PHP:

$exampleVarZeroOne = 1;
$secondVar         = 1;
$anotherVariable   = 1;

Dit is ook flink bevorderend voor het overzichtelijkheid

[Anoniem: 140111]

Een stijl die ik zelf gebruik binnen Java is bij membervariables een underscore te gebruiken als prefix. Dus:

Java:

class Foo {
  private int _bar;

  public Foo(int bar) {
    _bar = bar;
  }
}

Voordelen hiervan vind ik dat je direct ziet of je met een local of een member te maken hebt. Ook bij codecompletion is het een voordeel wanneer je op zoek bent naar een membervariable.

Dat is wel een goede eigenlijk

[CubicQ]

Rowdy.nl schreef op vrijdag 26 januari 2007 @ 09:13:

[...]
Linkje...?

http://www.cc2e.com/Default.aspx

[LauPro]

Voor PHP gebruik ik in principde PEAR guidelines. Op uitzondering van tabs ipv spaces (de tijd van ANSI-terminals is imo voorbij).

[JKVA]

Anoniem: 140111 schreef op vrijdag 26 januari 2007 @ 17:43:
[...]


Dat is wel een goede eigenlijk

Dat zie je bij verschillende open source projecten idd ook. Zwaar netjes wat mij betreft.

Maar toen ik het een keertje bij mijn project probeerde, begon checkstyle meteen te zeiken. (net als de projectleider, die graag met je mee in de code zit te neuzen)

[BalusC]

Zoiets zie je in Java eigenlijk alleen maar bij constructeurs of setters. In zo'n geval gebruik ik gewoon de this verwijzing.

Java:

public void setSomething(Object something) {
    this.something = something;
}

[JeroenTheStig]

Anoniem: 140111 schreef op vrijdag 26 januari 2007 @ 17:43:
[...]


Dat is wel een goede eigenlijk

Vind ik zelf ook, maar helaas wilde de projectleider van het huidige project waar ik op zit er niet aan, hij wilde zich keurig netjes aan de Java-standaarden houden. Dan vraag ik mij af, wie heeft bepaald dat er 1 Java-standaard is... volgens mij niemand. Het zijn alleen richtlijnen die je op de java.sun.com-site kunt vinden.

Bovendien werd hierboven ook al opgemerkt dat je ook this kunt gebruiken en dat dit ook werkt met codecompletion. Dat laatste is natuurlijk ook waar, maar als je class al flink aan het groeien is, dan vind ik de underscore toch een stuk handiger, omdat je met de underscore alleen nog maar de member variables overhoudt. Met this krijg je _alle_ members te zien, inclusief members van je superclass.

[LauPro]

Het lijkt me vrij duidelijk *wie* Java heeft opgericht. En daar is dan ook nagedacht over standaarden. Dat er misschien bepaalde zaken beter kunnen dat zal ik niet ontkennen maar in het algemeen belang van de consistentie van Java-projecten kan je beter aan die initiële standaard voldoen. Eventuele aanpassingen aan die standaarden zouden bijvoorbeeld kunnen worden opgenomen in een gehele nieuwe versie van het platform.

Dus het is mijns inziens niet aan jou om te bepalen wat de maatstaf moet zijn. Al helemaal omdat codecompletion niet iets is dat in de 'Java-standaard' is opgenomen maar te maken heeft met de implementatie van de gebruikte editor. Je oplossing zou dus kunnen liggen in het zoeken/maken van een pref waarbij de codecompletion niet de members van de superclass laat zien of pas laat zien na een bepaalde toetsaanslag.

Het is dus in mijn ogen symptoonbestrijding om je codestyle aan te passen op je editor in plaats van andersom.

[FTPlus]

De verschillende programeer stijlen (met name de accolades) zijn zelf opgenomen in ansi of iso standaarden. Het zou vast waar zijn dat de ene stijl minder plek in beslag neemt dan de ander, of dat de ene overzichterlijker is dan de ander, uiteindelijk maakt dat allemaal niet zoveel uit. Het belangrijkste van stijl in een code is dat het uniform is. Als men stijlen inconsequent of domweg doorelkaar gaat gebruiken, is een code minder leesbaar.

Verder is er maar één goede stijl, en dat is je eigen. Als je niet vanuit groepsverband werkt, en een bepaalde stijl moet hooghouden, dan is het geen schande om het in je eigen stijl te doen. Als je geen eigen stijl hebt, kan je altijd een iso stijl kiezen, maar als je gaande weg het prettig vind om dingen op een andere manier te schrijven, waarom ook niet.

Totslot: onafhankelijk van welke stijl je ook programeert, het gebruik van comments is absoluut geen overbodige luxe. Ik zie code meestal als een verhaaltje: met hoofdstukken (modules), alinea's (functie blokken), zinnen.
Aan het begin van het verhaal hoord een lijstje met hoofdstukken en een voorwoord. Boven een hoofdstuk hoort een titel. Hoofdstukken en alinea's duidelijk van enkaar gescheiden met witregels of -ruimtes. Af en toe een voetnoot bij onduidelijke zinnen.

[JKVA]

BalusC schreef op vrijdag 26 januari 2007 @ 21:11:
Zoiets zie je in Java eigenlijk alleen maar bij constructeurs of setters. In zo'n geval gebruik ik gewoon de this verwijzing.

Java:

public void setSomething(Object something) {
    this.something = something;
}

Dat wordt Shadowing genoemd en is zwaar evil. Het klopt dat je met this refereert naar je instantievariabelen, maar check deze code eens.

Java:

public class Iets {

    private Document document;

    public void setDocument(Document docment) {
        this.document = document;
    }
}

Iets dergelijks heb ik ooit een dag aan verspild, simpelweg omdat ik over te typefout in de parameter heen keek. Tegenwoordig behoedt Eclipse me voor dergelijke fouten door warnings te geven, maar ik hou liever het heft in eigen hand.

Bovendien gebruiken we een continuus integration systeem met tig code kwaliteit metingen die gepresenteerd worden op een website. En als je dan ziet dat je per x regels code er x regels fout zijn, komt je project over als een ontzettende klerebende, tenminste voor de klant...

[RayNbow]

JKVA schreef op zaterdag 27 januari 2007 @ 11:24:
[...]
Iets dergelijks heb ik ooit een dag aan verspild, simpelweg omdat ik over te typefout in de parameter heen keek. Tegenwoordig behoedt Eclipse me voor dergelijke fouten door warnings te geven, maar ik hou liever het heft in eigen hand.

Waarom Eclipse warnings laten geven? In Eclipse kun je vrij simpel een getter/setter laten genereren.

[BalusC]

JKVA schreef op zaterdag 27 januari 2007 @ 11:24:
Dat wordt Shadowing genoemd en is zwaar evil.

Hier heb je me al eerder op gewezen En ik kan me met jouw voorbeeld enigszins voorstellen dat het zwaar evil is. Maar als je goed code't dan is er niks aan het handje. In ieder geval, ik heb er nooit problemen mee gehad

[Wizz15]

Black Hawk schreef op donderdag 25 januari 2007 @ 17:17:

PHP:

/**
 * Hier een beschrijving van de class
 *
 */
class iets {
    /**
     * Controleert of de gebruiker en het bestand al gekoppeld zijn
     *
     * @param Integer $gebruikersID
     * @param Integer $bestandsID
     * @return Boolean
     *
     */
    public function isGekoppeld( $gebruikersID = false, $bestandsID = false )
    {
        $return = false;

        if ( ! ( $gebruikersID || $bestandsID ) ):
            echo "Onjuiste parameters !! (function isGekoppeld -- bestanden.php)";
        else:
            $arrResult = mysql_fetch_assoc( query( maakSelect( GEBRUIKER_BESTAND, "COUNT(*) as aantal", 
                                                             "WHERE gebruikersID = " . $gebruikersID . 
                                                             " AND bestandsID = " . $bestandsID ) ) );
  
            $return = ( $result['aantal'] > 0 );
        endif;

        return (bool) $return;
    }
}

ik heb in het verleden wel met accolades gewerkt, maar ik vind het handiger als ik bij lange stukken code nog kan zien waar ik zit in mijn code in plaats van omhoog te moeten scrollen bijvoorbeeld om te kijken of het een if-else constructie is, of bijvoorbeeld een while-loop. Op deze manier zie je het gelijk

en als ik toch accolades zie weet ik dat het een method/functie of class is, afhankelijk van de indentatie

[ Voor 27% gewijzigd door Wizz15 op 27-01-2007 14:32 ]

[JKVA]

RayNbow schreef op zaterdag 27 januari 2007 @ 11:35:
[...]

Waarom Eclipse warnings laten geven? In Eclipse kun je vrij simpel een getter/setter laten genereren.

Er is meer dan getters en setters, maar je hebt gelijk. Eclipse genereert ze alleen standaard wel fout, tenminste als je shadowing als een fout ziet. En dat doet die CheckStyle meuk...

BalusC schreef op zaterdag 27 januari 2007 @ 12:46:
[...]
Hier heb je me al eerder op gewezen
[...]

Lol, kan me er niks meer van herinneren. Anders had ik het niet gezegd.

edit:

Aha, gevonden:
[Eclipse] getters & setters generatie template aanpassen

[ Voor 7% gewijzigd door JKVA op 27-01-2007 15:31 . Reden: ff iets nazoeken ]

[Petok]

Wat ik soms zie in code is dat ze proberen de else in een if statement te ontwijken:

code:

int maximum;
max = a;
if ( b > a ) {
    max = b;
}

[Pete]

JKVA schreef op zaterdag 27 januari 2007 @ 11:24:
[...]

Dat wordt Shadowing genoemd en is zwaar evil.

Maar hoe maak jij dan setter methods? Zoals eclipse (String string)? Of ben jij iemand die de code conventie onderaan deze pagina gebruikt? (dus instance vars met m_ of my beginnen en class vars met c_)

Zijn er zoiezo mensen die die conventie aanhouden?

[Anoniem: 201130]

JKVA schreef op zaterdag 27 januari 2007 @ 11:24:
[...]

Dat wordt Shadowing genoemd en is zwaar evil. Het klopt dat je met this refereert naar je instantievariabelen, maar check deze code eens.

Java:

public class Iets {

    private Document document;

    public void setDocument(Document docment) {
        this.document = document;
    }
}

Iets dergelijks heb ik ooit een dag aan verspild, simpelweg omdat ik over te typefout in de parameter heen keek. Tegenwoordig behoedt Eclipse me voor dergelijke fouten door warnings te geven, maar ik hou liever het heft in eigen hand.

Bovendien gebruiken we een continuus integration systeem met tig code kwaliteit metingen die gepresenteerd worden op een website. En als je dan ziet dat je per x regels code er x regels fout zijn, komt je project over als een ontzettende klerebende, tenminste voor de klant...

JKVA schreef op zaterdag 27 januari 2007 @ 11:24:
[...]

Dat wordt Shadowing genoemd en is zwaar evil. Het klopt dat je met this refereert naar je instantievariabelen, maar check deze code eens.

Er is niets evil aan shadowing. Nutteloze F's, M'tjes en underscores bij je variabelen zetten, dat is pas evil. Want deze zijn totaal nietszeggend en zijn wat mij betreft bad practises. Het net zoiets als een tabel noemen: "tblBlaat". Ja, dat het een tabel is dat weten we echt wel hoor .

Bij java kan ik het me trouwens nog wel voorstellen dat je iets voor de variabele wil zetten vanwege de notatiewijzes van methoden en properties. Echter in C# wordt dit ook veel gedaan door mensen en daar is het totaal nutteloos want de code convention is:

C#:

public void DoSomething();
public string Something { get; set; }
private string something;

Dit is duidelijk te onderscheiden en al helemaal met de aanwezige intellisense.

Petok schreef op zaterdag 27 januari 2007 @ 15:50:
Wat ik soms zie in code is dat ze proberen de else in een if statement te ontwijken:

code:

int maximum;
max = a;
if ( b > a ) {
    max = b;
}

Daar is overigens ook niet veel mis mee. Dit is zelfs performance optimalisatie. Immers hoeft alleen de if gecontroleerd te worden en niet meer de else daarna.

[ Voor 10% gewijzigd door Anoniem: 201130 op 27-01-2007 23:58 ]

[mithras]

Anoniem: 201130 schreef op zaterdag 27 januari 2007 @ 23:56:

[...]


Daar is overigens ook niet veel mis mee. Dit is zelfs performance optimalisatie. Immers hoeft alleen de if gecontroleerd te worden en niet meer de else daarna.

Als de if gecontroleerd is, hoeft de else niet nóg eens gecontroleerd te worden Het wordt een keer gedaan. Is het true, dan if, anders (dan _moet_ het false zijn) else. Dat is dus maar één check

[Anoniem: 201130]

mithras schreef op zondag 28 januari 2007 @ 00:01:
[...]
Als de if gecontroleerd is, hoeft de else niet nóg eens gecontroleerd te worden Het wordt een keer gedaan. Is het true, dan if, anders (dan _moet_ het false zijn) else. Dat is dus maar één check

Klopt, maar er dient dan nog wel een "jump" gemaakt te worden naar de memory locatie waar de statements zich bevinden die in de else staan. In deze situatie hoeft dit niet. Dat is trouwens wel optimalisatie voor de "freaks" moet ik toegeven

[ Voor 6% gewijzigd door Anoniem: 201130 op 28-01-2007 00:04 ]

[Erkens]

Petok schreef op zaterdag 27 januari 2007 @ 15:50:
Wat ik soms zie in code is dat ze proberen de else in een if statement te ontwijken:

code:

int maximum;
max = a;
if ( b > a ) {
    max = b;
}

dat doe ik ook regelmatig, is imo vaak ook duidelijker. Je weet nu namelijk dat max altijd de waarde van a bevat, tenzij b groter is: een uitzondering dus.

[.oisyn]

Anoniem: 201130 schreef op zondag 28 januari 2007 @ 00:03:
[...]


Klopt, maar er dient dan nog wel een "jump" gemaakt te worden naar de memory locatie waar de statements zich bevinden die in de else staan. In deze situatie hoeft dit niet. Dat is trouwens wel optimalisatie voor de "freaks" moet ik toegeven

Het is helemaal geen optimalisatie, punt.

[Erkens]

.oisyn schreef op zondag 28 januari 2007 @ 00:19:
[...]

Het is helemaal geen optimalisatie, punt.

idd, want mocht b groter zijn, dan zijn er plotseling 2 toekenningen ipv 1 met een "normale" if-else structuur

[Anoniem: 201130]

Erkens schreef op zondag 28 januari 2007 @ 00:25:
[...]

idd, want mocht b groter zijn, dan zijn er plotseling 2 toekenningen ipv 1 met een "normale" if-else structuur

Nee hoor, hoeft helemaal niet. Want was is sneller. Een waarde toekennen aan een geheugenlokatie die net benaderd is of een nieuwe subroutine ophalen en uitvoeren en vervolgens weer toekennen?

[ Voor 5% gewijzigd door Anoniem: 201130 op 28-01-2007 00:30 ]

[.oisyn]

Je kunt er helemaal geen uitspraken over doen omdat er nog geen platform gedefineerd is. Wellicht is er helemaal geen compare instructie, maar bestaat er gewoon een min instructie (zoals in x86's MMX en SSE, PowerPC's VMX, etc.) of conditional moves. Daarnaast is er ook niet zoiets als "het ophalen van een subroutine"; er is namelijk geen subroutine, maar wel wat conditional en unconditional branches. En unconditional branches zijn meestal goedkoop.

Vergelijk (x86):

code:

// de "geoptimaliseerde" code
    mov eax, [a]
    mov ebx, [b]
    mov [max], ebx
    cmp eax, ebx
    cmovl [max], eax


// de "ongeoptimaliseerde" code
    mov eax, [a]
    mov ebx, [b]
    cmp eax, ebx
    cmovl [max], eax
    cmovge [max], ebx

En als max in uncached memory staat, kun je er maar beter niet teveel naar schrijven. Maar dat is weer een aanname. Bottom line is dat je er zonder kennis van het specifieke platform geen uitspraken over kunt doen

[ Voor 38% gewijzigd door .oisyn op 28-01-2007 00:59 ]

[Kwistnix]

Boktor schreef op vrijdag 26 januari 2007 @ 09:16:
Een stijl die ik zelf gebruik binnen Java is bij membervariables een underscore te gebruiken als prefix. Dus:

Java:

class Foo {
  private int _bar;

  public Foo(int bar) {
    _bar = bar;
  }
}

Voordelen hiervan vind ik dat je direct ziet of je met een local of een member te maken hebt. Ook bij codecompletion is het een voordeel wanneer je op zoek bent naar een membervariable.

Ik ben zelf van mening dat het gebruik van een underscore prefix overbodig is als je een fatsoenlijke IDE gebruikt. Daarbij is deze vorm van prefixen irritant als je aan de JavaBean spec moet voldoen.
Normaal gesproken gebruik je accessor methoden als "getFoo" and "setFoo", maar op deze manier krijg je dan methoden namen als "get_foo" en "set_foo". Dat vind ik dus ronduit lelijk.
Hibernate, bijvoorbeeld, maakt default gebruik van accessor methoden voor toegang tot member variabelen. In zo'n situatie moet ja dan dus ook in de hibernate mappings de id name's prefixen met een underscore, wat nergens op slaat in die context.

[ Voor 39% gewijzigd door Kwistnix op 28-01-2007 02:58 ]

[H!GHGuY]

Anoniem: 129028 schreef op donderdag 25 januari 2007 @ 16:36:
[...]
Daar ben ik het toch niet mee eens. Ik vind bijvoorbeeld

x = func( a, b, func2( c, d / 5 ) * func3( e, f ));

veel leesbaarder dan

x=func(a,b,func2(c,d/5)*func3(e,f));

en ik vind

C++:

x = func(a, b, func2(c, d/5) * func3(e, f));

nog net iets duidelijker. In beide van jouw voorbeelden had ik plots de moeite om te zien welke parameters nu nog tot func2, func3 hoorden en welke tot func.

qua indentering stijl:

C++:

class CSomeClass
{
public:
  void EenFunctie()
  {
    string x("");
    if (x == "bla")
      doY();
    else
      doZ();

    if (x == "bla2")
    {
      doOneThing("first", "second");
      doAnotherThing();
    }
    else
    {
      doSomethingElse();
    }
  }
}

Ik moet namelijk die brackets onder elkaar hebben om te zien waar m'n functie begint en eindigt.
Een scope duid je aan met { en }, niet met if, while, for en }. Ik vind het allemaal teveel naar python gaan als je dat wel doet. En ga daar maar eens om met 5 niveau's van indentatie met daartussen nogal wat code.

De enige andere stijl die ik nog enigszons ietwat leesbaar vind is deze:

C++:

if (a == 10) {

  doeIets();
  doeNogIets();
  enNogIets();

} else {
  
  doeIetsAnders();
  enNogIetsTotaalAnders(a);
  enSluitdanAfMetDit();

}

Ik vind bovendien luchtige code er gemakkelijker leesbaar uitzien.
Van

C++:

int mijnFunctie(int a, int b, int c)
{
  if (a==b) c*=a;
  eenFunctie(a, b);
  int d = b /a;
  while (d > 0)
     c -= b;
  return a*b/c;
}

krijg ik krullende tenen. Meestal scheidt ik ook functionele blokken

C++:

int mijnFunctie(int a, int b, int c)
{
  if (a==b)
    return c;

  int d = a+b;
  while (d > 0)
     d = eenFunctie(c + d);

  return d + a + b;
}

[Anoniem: 26306]

FallenAngel666 schreef op zondag 28 januari 2007 @ 01:56:

Ik ben zelf van mening dat het gebruik van een underscore prefix overbodig is als je een fatsoenlijke IDE gebruikt. Daarbij is deze vorm van prefixen irritant als je aan de JavaBean spec moet voldoen.
Normaal gesproken gebruik je accessor methoden als "getFoo" and "setFoo", maar op deze manier krijg je dan methoden namen als "get_foo" en "set_foo". Dat vind ik dus ronduit lelijk.

Je zou het ook kunnen zien als een tekortkoming van de JavaBeans specificatie.

Hibernate, bijvoorbeeld, maakt default gebruik van accessor methoden voor toegang tot member variabelen. In zo'n situatie moet ja dan dus ook in de hibernate mappings de id name's prefixen met een underscore, wat nergens op slaat in die context.

Je zou het ook kunnen zien als een tekortkoming van Hibernate.

Dooddoeners natuurlijk, maar je moet ten eerste inzien dat er voor elke stijl wel iets te zeggen is. Anders zouden er namelijk helemaal geen verschillende stijlen bestaan.

Ikzelf gebruik overigens verschillende stijlen voor verschillende talen.

[Anoniem: 201130]

Anoniem: 26306 schreef op zondag 28 januari 2007 @ 11:08:
[...]

Je zou het ook kunnen zien als een tekortkoming van de JavaBeans specificatie.

Je zou het ook kunnen zien als een terkortkoming van mensen die overal pertinent nietszeggende underscores voor willen gooien

[JeroenTheStig]

FallenAngel666 schreef op zondag 28 januari 2007 @ 01:56:
[...]


Ik ben zelf van mening dat het gebruik van een underscore prefix overbodig is als je een fatsoenlijke IDE gebruikt. Daarbij is deze vorm van prefixen irritant als je aan de JavaBean spec moet voldoen.
Normaal gesproken gebruik je accessor methoden als "getFoo" and "setFoo", maar op deze manier krijg je dan methoden namen als "get_foo" en "set_foo". Dat vind ik dus ronduit lelijk.
Hibernate, bijvoorbeeld, maakt default gebruik van accessor methoden voor toegang tot member variabelen. In zo'n situatie moet ja dan dus ook in de hibernate mappings de id name's prefixen met een underscore, wat nergens op slaat in die context.

Hier ben ik het dus niet mee eens. Ten eerste filter je met autocompletion je membervariables er direct uit i.p.v. dat je al je classmembers krijgt. Ten tweede kun je in een beetje fatsoenlijke IDE instellen hoe je membervariables eruit zien. In JDeveloper kan ik bijvoorbeeld instellen dat ik als prefix een underscore gebruik. Bij het genereren van getters en setters wordt hier rekening mee gehouden, waardoor je je underscores niet in je getters en setters krijgt.

[Kwistnix]

Boktor schreef op zondag 28 januari 2007 @ 13:33:
[...]

Hier ben ik het dus niet mee eens. Ten eerste filter je met autocompletion je membervariables er direct uit i.p.v. dat je al je classmembers krijgt.

In het overgrote deel van de gevallen waar je methode parameters hetzelfde noemt als je member variabelen heb je het over getter en setter methoden. Die kun je in iedere IDE automagisch laten genereren dus dat is geen probleem. In andere gevallen is het wellicht de moetie waard om voor parameters een andere naamgeving te hanteren, of je gebruikt simpelweg het keyword "this". Dat scheelt natuurlijk wel 5 hele characters...
Scope herkenning is in de meeste IDE's ook geen probleem. Eclipse highlight bijvoorbeeld member variabelen, waardoor de scope van een variabele direct helder is.

Ten tweede kun je in een beetje fatsoenlijke IDE instellen hoe je membervariables eruit zien. In JDeveloper kan ik bijvoorbeeld instellen dat ik als prefix een underscore gebruik. Bij het genereren van getters en setters wordt hier rekening mee gehouden, waardoor je je underscores niet in je getters en setters krijgt.

En op dat moment wijkt je dus af van de JavaBean spec

[Anoniem: 49627]

RayNbow schreef op zaterdag 27 januari 2007 @ 11:35:
Waarom Eclipse warnings laten geven? In Eclipse kun je vrij simpel een getter/setter laten genereren.

Simpelweg omdat eclipse een derderangs 'platform' is waarvan de setter generatie zwaar zuigt. Het is voor eclipse namelijk geen probleem om setters voor final fields te genereren . En eclipse genereert ook foute getter/setter methode namen. Probeer maar eens een veld als "private String eMail", de setter die daarbij hoort is namelijk "seteMail(..)" *


*afhankelijk van jdk versie (introspection regels en bla bla bla)

[JeroenTheStig]

FallenAngel666 schreef op zondag 28 januari 2007 @ 14:01:
[...]


In het overgrote deel van de gevallen waar je methode parameters hetzelfde noemt als je member variabelen heb je het over getter en setter methoden. Die kun je in iedere IDE automagisch laten genereren dus dat is geen probleem. In andere gevallen is het wellicht de moetie waard om voor parameters een andere naamgeving te hanteren, of je gebruikt simpelweg het keyword "this". Dat scheelt natuurlijk wel 5 hele characters...
Scope herkenning is in de meeste IDE's ook geen probleem. Eclipse highlight bijvoorbeeld member variabelen, waardoor de scope van een variabele direct helder is.

De highlight-functie heb ik volgens mij niet in JDeveloper, maar ik zal eens een keer naar Eclipse kijken hoe dat hier in is geregeld

[...]


En op dat moment wijkt je dus af van de JavaBean spec

Dit is niet waar
Ik citeer uit het SCJP-boek wat ik hier heb liggen over de JavaBean spec:

If the property is not a boolean, the getter method's prefix must be get. For example, getSize() is a valid JavaBeans getter name for a property named "size". Keep in mind that you do not need to have a variable named size (although some IDEs expect it). The name of the property is inferred from the getters and setters, not through any variables in your class. What you return from getSize() is up to you.

[Kwistnix]

De spec legt ook bepaalde design patterns vast:

By default, we use design patterns to locate properties by looking for methods of the form:
public <PropertyType> get<PropertyName>();
public void set<PropertyName>(<PropertyType> a);
If we discover a matching pair of "get<PropertyName>" and "set<PropertyName" methods that take and return the same type, then we regard these methods as defining a read-write property whose name will be "<propertyName>". We will use the "get<PropertyName>" method to get the property value and the "set<PropertyName>" method to set the property value. The pair of methods may be located either in the same class or one may be in a base class and the other may be in a derived class.

[ Voor 6% gewijzigd door Kwistnix op 28-01-2007 18:14 ]

[RayNbow]

Anoniem: 49627 schreef op zondag 28 januari 2007 @ 14:03:
[...]
Simpelweg omdat eclipse een derderangs 'platform' is waarvan de setter generatie zwaar zuigt. Het is voor eclipse namelijk geen probleem om setters voor final fields te genereren .

Als je in de editor set<ctrl+space> typt, dan ja... dan geeft Eclipse inderdaad de mogelijkheid om een setter te genereren.

Ook via het menu geeft Eclipse de mogelijkheid om setters voor final fields te genereren. Echter, in dit geval geeft Eclipse wel een waarschuwing en wordt er gevraagd of je zeker weet dat je een setter wil laten genereren.

Conclusie: als programmeur moet je wel je common sense^TM gebruiken als je code tools gebruikt.

En eclipse genereert ook foute getter/setter methode namen. Probeer maar eens een veld als "private String eMail", de setter die daarbij hoort is namelijk "seteMail(..)"

Eclipse genereert hier voor eMail de setter setEMail. Dit lijkt me gewoon correct:

* eMail is een field. Volgens de naming convention beginnen fields met een kleine letter en elk intern woord met een hoofdletter. eMail bestaat dus dan uit twee woorden, namelijk "e" en "mail".

* setEMail is een method. Volgens de naming convention beginnen methods met een kleine letter en moet de eerste letter van elk intern woord een hoofdletter zijn.

[Anoniem: 49627]

RayNbow schreef op zondag 28 januari 2007 @ 18:26:
Eclipse genereert hier voor eMail de setter setEMail. Dit lijkt me gewoon correct:
* eMail is een field. Volgens de naming convention beginnen fields met een kleine letter en elk intern woord met een hoofdletter. eMail bestaat dus dan uit twee woorden, namelijk "e" en "mail".

* setEMail is een method. Volgens de naming convention beginnen methods met een kleine letter en moet de eerste letter van elk intern woord een hoofdletter zijn.

Ik noem het natuurlijk met een reden heh, dit is namelijk een uitzondering. Voor java1.4 en lager moet het 'seteMail' zijn. Dat is de spec! Voor java5 en hoger is het wel 'setEmail'. Eclipse doet het domweg fout.

[roy-t]

Ik vind dit wel een interessante eigenlijk, zelf programmeer ik bijna altijd in mijn eentje en voor totale nono's, dus niemand die de code doorleest.

Wat ik wel merk is dat als ik aan grote projecten werk (1mans projecten van max 100u) dat ik tijdens het programmeren nog wel eens van stijl wil veranderen. Dit komt misschien ook omdat ik nog niet veel grote (again verwijs ik naar 100u, vind ik groot zat ) projecten heb gemaakt. Zelf zit ik nog te zoeken. Maar een paar dingen zijn voor mij heel duidelijk.

variabelen geef ik het liefst een naam mee die beschrijvend is, met de voor zetsels i (integer) s (string) b (boolean) d (date) c (currency) etc.

Grote objecten geef ik meestal ook een vaste naam met 3 letters (cmd voor commandbutton, lst voor list etc).

Als ik in C# programmeer gebruik ik ook altijd { en } op nieuwe regels.

De overstap van VB6 naar C# was wel heel groot door de { en } dit maakte dat je het totaal anders las, en deze stijl heeft nu zijn weg gevonden naar mijn VB programmeer werk door veel meer te tabben binnen in IF-THEN-ELSE of SELECT CASE statements.

Ik groei!

[RayNbow]

Anoniem: 49627 schreef op zondag 28 januari 2007 @ 19:17:
[...]

Ik noem het natuurlijk met een reden heh, dit is namelijk een uitzondering. Voor java1.4 en lager moet het 'seteMail' zijn. Dat is de spec! Voor java5 en hoger is het wel 'setEmail'. Eclipse doet het domweg fout.

Heb je een bron dan? De Java naming convention pagina is sinds 1998 nauwelijks veranderd.

[Anoniem: 49627]

RayNbow schreef op zondag 28 januari 2007 @ 19:49:
Heb je een bron dan? De Java naming convention pagina is sinds 1998 nauwelijks veranderd.

Nee geen bron, want dan moet ik zoeken en daar heb ik simpelweg geen zin in.
Je kan altijd even spelen met "java.beans.Introspector" om het zelf te ervaren.

[Optix]

Zelf prog ik veel PHP in VI(M). Daarom heb ik het liefst niet al te veel enter's en gebruik het meest spaties om de code duidelijk te maken, code highlighting maakt het dan wel af. Ik heb het liefst zo veel mogelijk code op mijn scherm.

[RayNbow]

Anoniem: 49627 schreef op zondag 28 januari 2007 @ 19:56:
[...]
Nee geen bron, want dan moet ik zoeken en daar heb ik simpelweg geen zin in.
Je kan altijd even spelen met "java.beans.Introspector" om het zelf te ervaren.

quote: http://springide.org/project/ticket/355

But the following code fails on JDK 1.5 with "java.beans.IntrospectionException: Method not found: isEMail"
[...]

Conclusie: gebruik in namen van fields alleen woorden die langer zijn dan 1 letter, anders gaat het capitalizen/decapitalizen fout.

Gevolg voor het "eMail" voorbeeld: gebruik de alternatieve en correcte spelling "email", dan ben je van het gezeur af.

[Anoniem: 49627]

RayNbow schreef op zondag 28 januari 2007 @ 20:29:
Conclusie: gebruik in namen van fields alleen woorden die langer zijn dan 1 letter, anders gaat het capitalizen/decapitalizen fout.

Gevolg voor het "eMail" voorbeeld: gebruik de alternatieve en correcte spelling "email", dan ben je van het gezeur af.

Daar ben ik enigszins wel van op de hoogte aangezien ik die bug zelf heb ingeschoten
Hetzelfde geldt voor de eclipse bug: https://bugs.eclipse.org/bugs/show_bug.cgi?id=154823 Conclusie:

The conclusion is:
For a field called eMail, we should call the getter 'geteMail'. If we would
call it getEMail, Java Beans would conclude that this is a constant name and
assume the property is 'EMail'.

[RayNbow]

Anoniem: 49627 schreef op zondag 28 januari 2007 @ 21:08:
[...]
Daar ben ik enigszins wel van op de hoogte aangezien ik die bug zelf heb ingeschoten
Hetzelfde geldt voor de eclipse bug: https://bugs.eclipse.org/bugs/show_bug.cgi?id=154823 Conclusie:

[...]

Lees je nu selectief?
In de pagina waar ik naar linkte staat een voorbeeldsituatie beschreven, waarin de door jou voorgestelde property eMail en de bijbehorende setters/getters seteMail, geteMail (of: iseMail) niet werkt.

De conclusie die ik hieruit trek is om namen als "eMail" te vermijden. De spelling "email" dient hier dan ook de voorkeur. Wil je per se de letter M met een hoofdletter schrijven, noem de field dan "electronicMailAddress" oid.

[Anoniem: 49627]

RayNbow schreef op zondag 28 januari 2007 @ 21:25:
Lees je nu selectief?
In de pagina waar ik naar linkte staat een voorbeeldsituatie beschreven, waarin de door jou voorgestelde property eMail en de bijbehorende setters/getters seteMail, geteMail (of: iseMail) niet werkt.

De conclusie die ik hieruit trek is om namen als "eMail" te vermijden. De spelling "email" dient hier dan ook de voorkeur. Wil je per se de letter M met een hoofdletter schrijven, noem de field dan "electronicMailAddress" oid.

ik dacht dat ik duidelijk was, klaarblijkelijk niet De reporter van de bug op de pagina, waar jij naar refereert, ben ik Ik ben zodoende behoorlijk op de hoogte van wat wel en niet handig is om te doen. Het voorbeeld wat je daar dus ziet is onder java5, het verschil wat ik al eerder aankaartte.

[hamsteg]

Grappig, iedereen vindt wel iets ... maar eh ... heeft een ieder zich wel eens afgevraagd wat de impact is van een bepaalde stijl als een ander jouw code moet bewerken?

Bij mijn bedrijf is daarom de stelregel 1 opdracht/conditie per regel en veel spaties ... eerst was ik het daar natuurlijk niet mee eens. Na tien jaar ben ik echter wel in staat om snel en gemakkelijk de code van al mijn collega's te lezen en te beoordelen. De laatste jaren ben ik daarom meer en meer voor dit statement ( btw. een block starter/stopper wordt ook gezien als 1 statement). Hoe minder complex op een regel, hoe makkelijker op te dragen en uit te leggen aan iedereen.

Het grappige is dat dit in alle talen goed te handhaven is. Ik heb vele talen gezien maar deze eenvoudige regel help. (en nee ik ben het er niet altijd automatisch mee eens )

[RayNbow]

Anoniem: 49627 schreef op zondag 28 januari 2007 @ 21:32:
[...]
ik dacht dat ik duidelijk was, klaarblijkelijk niet De reporter van de bug op de pagina, waar jij naar refereert, ben ik Ik ben zodoende behoorlijk op de hoogte van wat wel en niet handig is om te doen. Het voorbeeld wat je daar dus ziet is onder java5, het verschil wat ik al eerder aankaartte.

Ik refereerde naar een andere reply op die pagina:
 

---

08/23/06 18:02:59 changed by tjuerge ¶

But the following code fails on JDK 1.5 with "java.beans.IntrospectionException: Method not found: isEMail"

Java:

import java.beans.PropertyDescriptor;

public class RunIntrospection { 
    public static void main(String[] args) throws Exception {       
        PropertyDescriptor prop = new PropertyDescriptor("eMail", Bean.class);
        System.out.println(prop.getWriteMethod());
    }
    
    private class Bean {
        public boolean iseMail() {
            return false;
        }

        public void seteMail(String eMail) {
        }
    }
}

This is because of Sun's implementation of PropertyDescriptor:

Java:

    /**
     * Constructs a PropertyDescriptor for a property that follows
     * the standard Java convention by having getFoo and setFoo
     * accessor methods.  Thus if the argument name is "fred", it will
     * assume that the writer method is "setFred" and the reader method
     * is "getFred" (or "isFred" for a boolean property).  Note that the
     * property name should start with a lower case character, which will
     * be capitalized in the method names.
     *
     * @param propertyName The programmatic name of the property.
     * @param beanClass The Class object for the target bean.  For
     *      example sun.beans.OurButton.class.
     * @exception IntrospectionException if an exception occurs during
     *              introspection.
     */
    public PropertyDescriptor(String propertyName, Class<?> beanClass)
        throws IntrospectionException {
    this(propertyName, beanClass, 
         "is" + capitalize(propertyName), 
         "set" + capitalize(propertyName));
    }

---

[Anoniem: 49627]

En dan zeg je dat ik selectief lees???

Anoniem: 49627 schreef op zondag 28 januari 2007 @ 21:32:
[..] Het voorbeeld wat je daar dus ziet is onder java5, het verschil wat ik al eerder aankaartte.

RayNbow schreef op zondag 28 januari 2007 @ 21:54:
But the following code fails on JDK 1.5 with "java.beans.IntrospectionException: Method not found: isEMail"

[RayNbow]

Anoniem: 49627 schreef op zondag 28 januari 2007 @ 22:06:
En dan zeg je dat ik selectief lees???

[...]


[...]

De code werkt ook niet onder Java 1.4, schat

[1174827@atlas rh9]$ java -version
java version "1.4.2"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2-b28)
Java HotSpot(TM) Client VM (build 1.4.2-b28, mixed mode)
[1174827@atlas jtmp]$ javac RunIntrospection.java
[1174827@atlas jtmp]$ java RunIntrospection
Exception in thread "main" java.beans.IntrospectionException: No method "getEMail" with 0 arg(s) of matching types.
        at java.beans.Introspector.findMethod(Introspector.java:1238)
        at java.beans.Introspector.findMethod(Introspector.java:1212)
        at java.beans.PropertyDescriptor.<init>(PropertyDescriptor.java:58)
        at RunIntrospection.main(RunIntrospection.java:5)

Anoniem: 49627 schreef op zondag 28 januari 2007 @ 22:16:
weet je, laat ook maar. Het is al teveel oftopic en je snapt het toch niet.

Ik snap het probleem wel degelijk. Volgens de huidige implementatie zijn capitalize en decapitalize niet elkaars inversen:

code:

// Dit is hoe het nu is:
a = capitalize("eMail"); // a is nu "EMail"
a = decapitalize(a); // a is nu "EMail"

// Dit zou het vorige stukje moeten zijn:
a = capitalize("eMail"); // a is nu "eMail"
a = decapitalize(a); // a is nu "eMail"

// Het volgende is hoe het nu is en moet zijn:
a = capitalize("EMail"); // a is nu "EMail"
a = decapitalize(a); // a is nu "EMail"
 

Dit betekent dat totdat dit probleem in de JDK wordt opgelost, dat je niet met fieldnamen als "eMail" moet gaan werken. Vermijd dus namen die beginnen met slechts een enkele kleine letter dat meteen gevolgd wordt door een hoofdletter.

[ Voor 34% gewijzigd door RayNbow op 28-01-2007 22:54 ]

[Anoniem: 49627]

weet je, laat ook maar. Het is al teveel oftopic en je snapt het toch niet.

[ Voor 87% gewijzigd door Anoniem: 49627 op 28-01-2007 22:18 ]

[ILUsion]

Mijn stijl in Pascal-dialecten (Object Pascal/ Delphi en Modula 2) houdt vooral in dat ik heel veel met inspringen werk, steeds 2 spaties (reden: spaties zien er overal hetzelfde uit, en Delphi werkt autmatisch met 2 spaties). Voor PHP heb ik momenteel nog niet echt een stijl, of toch geen goede (ik vermoed dat ik een redelijk BASIC-achtige stijl heb in PHP).

Delphi:

if (blaat)
  then
    begin
      dosomethings;
    end
  else
    begin
      dosomeotherthings;
    end;

En voor Modula (wel iets minder ruimte nodig hiervoor, maar ik vind de begin-end-stijl van gewone Pascal veel consistenter, zeker als je dan vergelijkt met PHP, C, ... waar je ook gewoon simpelweg codeblokjes maakt, plus is het in Modula-2 nogal stom om steeds die shift te moeten zoeken bij het ingeven van keywords, jezus, waarom zou je die zo willen laten opvallen terwijl je toch syntax highlighting hebt).

Delphi:

IF (blaat)
  THEN
    DosomeThings;
  ELSE
    DoSomethingElse;
  END;

En voor procedures en dergelijke:

Delphi:

procedure blaat(x, y, z : TType): TType;
  procedure blaatkwadraat(x: TType): TType;
    const blaat = 'foo';
    begin
      result := DoSomeThing(x, blaat);
    end;
  const blaat = 'bar';
  begin
    DoSomething(x);
    DoSomething(y);
    result := BlaatKwadraat(z);
  end;

[Anoniem: 26306]

Ik vind het er niet duidelijker op worden als je if en then en else op verschillende indentation levels hebt. Overigens vind ik "then" en "end" redelijk irritant in programmeertalen. In template-achtige situaties vind ik het wel duidelijk, maar in zuivere programmacode vind ik het onleesbaar worden.

[BalusC]

Hoe gaan jullie om met een combinatie van meerdere selectie statementen en meerdere return plaatsen binnen een methode? De een zegt dat geneste selectie statementen zuigen en dat de ander zegt dat meerdere return plaatsen binnen een methode onoverzichtelijk is.

1) Geneste selectie statementen en 1 return plaats:

Java:

public Object doSomething() {
    Object returnValue = null;

    if (exp1) {
        // code1

        if (exp2) {
            // code2

            if (exp3) {
                // code3
                returnValue = value1;
            } else {
                // code4
                returnValue = value2;
            }
        } else {
            // code5
            returnValue = value3;
        }
    } else {
        // code6
        returnValue = value4;
    }

    return returnValue;
}

2) Platte selectie statementen binnen een while en 1 return plaats:

Java:

public Object doSomething() {
    Object returnValue = null;

    while (returnValue == null) { // En ervan uitgaande dat value1, 2, 3 en 4 niet null kunnen zijn.
        if (!exp1) {
            // code6
            returnValue = value4;
        }

        // code1

        if (!exp2) {
            // code5
            returnValue = value3;
        }

        // code2

        if (!exp3) {
            // code4
            returnValue = value2;
        }

        // code3
        returnValue = value1;
    }

    return returnValue;
}

3) Platte selectie statementen en meerdere return plaatsen:

Java:

public Object doSomething() {
    if (!exp1) {
        // code6
        return value4;
    }

    // code1

    if (!exp2) {
        // code5
        return value3;
    }

    // code2

    if (!exp3) {
        // code4
        return value2;
    }

    // code3

    return value1;
}

[mithras]

Ik zou gaan voor optie drie: meest overzichtelijk. De eerste is met de vele if/else een grote warboel waarbij je goed moet kijken welke else bij welke if hoort, waar je dan ook makkelijk fouten in kan maken.
Die while staat me niet zo aan omdat je een loop gebruikt waarvoor helemaal geen loop nodig is. Daarnaast doe je exact hetzelfde als #3, alleen return je de waarde op een ander moment. Eigenlijk zinloos dus, dan is de #3 het makkelijkst, eenvoudigst en waarschijnlijk ook het snelst

Als het trouwens een kwestie zou zijn van meerdere if/elseif/elseif/else, gebruik ik liever een case (in php dan) statement. Dan behoud je ook ongeveer dezelfde "stijl" als bij jouw #3 voorbeeld.

[ Voor 16% gewijzigd door mithras op 29-01-2007 10:21 ]