Verschillende programmeerstijlen; voor- en nadelen

[.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;

Verwijderd 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));

Verwijderd 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 ]

[Verwijderd]

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

[Verwijderd]

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]

Verwijderd 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]

Verwijderd 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?

[Verwijderd]

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 Verwijderd op 27-01-2007 23:58 ]

[mithras]

Verwijderd 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

[Verwijderd]

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 Verwijderd 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]

Verwijderd 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

[Verwijderd]

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 Verwijderd 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]

Verwijderd 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;
}

[Verwijderd]

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.

[Verwijderd]

Verwijderd 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

[Verwijderd]

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]

Verwijderd 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.

[Verwijderd]

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]

Verwijderd 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.

[Verwijderd]

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]

Verwijderd 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.

[Verwijderd]

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]

Verwijderd 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.

[Verwijderd]

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]

Verwijderd 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));
    }

---

[Verwijderd]

En dan zeg je dat ik selectief lees???

Verwijderd 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]

Verwijderd 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)

Verwijderd 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 ]

[Verwijderd]

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

[ Voor 87% gewijzigd door Verwijderd 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;

[Verwijderd]

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 ]

[JKVA]

BalusC schreef op maandag 29 januari 2007 @ 09:56:
...

Ik zit nog te twijfelen tussen de eerste en derde. Die tweede vind ik heel lelijk, vooral omdat je een while gebruikt met alle gevolgen van dien. (zoals wanneer ze null zijn, het is niet overzichtelijk, want een while duidt op iteraties vind ik...)

Er is eventueel nog een vierde optie, namelijk de derde, maar dan met else ifs zodat je niet per se direct hoeft te returnen. Of het mooi is, hangt denk ik van de situatie af. In een methode met 2 variabelen vind ik een tmp variabele overkill, maar wanneer het groeit, kan het handig zijn, ook met debuggen.

[Verwijderd]

BalusC schreef op maandag 29 januari 2007 @ 09:56:
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.

...

Een combinatie van 1 + 3. Eigenlijk dus geen van al jouw voorbeelden. Er wordt teveel verschillende logica in 1 methode gebundeld op deze manier. Daarnaast dient een methode eigenlijk maar 1 entry en exit point te hebben.

[BalusC]

Er is eventueel nog een vierde optie, namelijk de derde, maar dan met else ifs zodat je niet per se direct hoeft te returnen.

Maar die moeten dan weer genest worden.

Een combinatie van 1 + 3.

Laat eens zien

[mithras]

BalusC schreef op maandag 29 januari 2007 @ 10:47:
[...]
Maar die moeten dan weer genest worden.
[...]
Laat eens zien

Bedoelen ze (om zo maar één exit point te hebben) zoiets:

Java:

public Object doSomething() {
    if (!exp1) {
        // code7
        returnValue = value4;
    }

    // code1

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

    // code2

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

    // code 3

    return returnValue;
}

[Verwijderd]

BalusC schreef op maandag 29 januari 2007 @ 09:56:
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.

Ik zoek dan eerder naar een oplossing met een map of list of iets dergelijks. Omdat je dan zeer overzichtelijk uit een lus kan breken, hetgeen wat je doorgaans wilt met een switch-case...

[merauder]

code:

if (vergelijking==VoorbeeldVoorwaarde)

     {
             cout <<  vooruit << endl;
     }   

else 
    {
            cout <<  achteruit << endl;
    }

Rare stijl maar weinig stukken code per regel, verder gebruik ik bij If/Else constructies Tabs om aan te geven op welk niveau de code verweven is. Is handig bij een If/Else constructie BINNEN een If/Else constructie.

[Mastermind]

Ik programmeer op deze manier. Ik mag graag compact programmeren, omdat je dan niet zoveel hoeft te scrollen en een goed overzicht hebt over de code.

Een gedeelte van een programma dat ik heb geschreven, toont bijv. aan hoe handig turnaries zijn:

C#:

string ExternContractnr = factuurEnt.TestCurrentFieldValueForNull(FactuurFieldIndex.ExternContractnr) ? "" : factuurEnt.ExternContractnr.Trim();
while (reportNameExists)
{
      achtervoegselStr = (achtervoegsel++).ToString().PadLeft(2, '0');
      TheNextFileName = ExternContractnr.IndexOfAny(Path.GetInvalidFileNameChars()) > 0 || ExternContractnr == ""
       ? aanMaakNr + "_" + achtervoegselStr + "_LaboratoryAnalyses.pdf"
       : aanMaakNr + "_" + achtervoegselStr + "_LaboratoryAnalyses " + ExternContractnr + ".pdf";
                
       testFilename1 = Path.Combine(finaldir1, TheNextFileName);
       if (alsoTheEditMap)
        {
             testFilename2 = Path.Combine(finaldir2, TheNextFileName);
             testFilename3 = Path.Combine(finaldir3, TheNextFileName);
        }

         reportNameExists = (File.Exists(testFilename1) ||  ((alsoTheEditMap && File.Exists(testFilename2)) || (alsoTheEditMap && File.Exists(testFilename3))));
}

[.oisyn]

Je moet wel scrollen, alleen links/rechts ipv onder/boven. En je identing is nou ook niet echt bepaald consistent. Je naamgeving ook niet trouwens.

[Creepy]

Handig? Ik weet hoe het werkt maar moet je regel code toch een paar keer nakijken om nu precies te zien wat het doet. Omdat je het gebruikt in een toekenning moet je veel specifieker gaan zoeken naar waar de conditie zit, terwijl je dat met een if directer / sneller zou zien.

[Verwijderd]

Mastermind schreef op dinsdag 30 januari 2007 @ 12:46:
Ik programmeer op deze manier. Ik mag graag compact programmeren, omdat je dan niet zoveel hoeft te scrollen en een goed overzicht hebt over de code.

Een gedeelte van een programma dat ik heb geschreven, toont bijv. aan hoe handig turnaries zijn:

C#:

string ExternContractnr = factuurEnt.TestCurrentFieldValueForNull(FactuurFieldIndex.ExternContractnr) ? "" : factuurEnt.ExternContractnr.Trim();
while (reportNameExists)
{
      achtervoegselStr = (achtervoegsel++).ToString().PadLeft(2, '0');
      TheNextFileName = ExternContractnr.IndexOfAny(Path.GetInvalidFileNameChars()) > 0 || ExternContractnr == ""
       ? aanMaakNr + "_" + achtervoegselStr + "_LaboratoryAnalyses.pdf"
       : aanMaakNr + "_" + achtervoegselStr + "_LaboratoryAnalyses " + ExternContractnr + ".pdf";
                
       testFilename1 = Path.Combine(finaldir1, TheNextFileName);
       if (alsoTheEditMap)
        {
             testFilename2 = Path.Combine(finaldir2, TheNextFileName);
             testFilename3 = Path.Combine(finaldir3, TheNextFileName);
        }

         reportNameExists = (File.Exists(testFilename1) ||  ((alsoTheEditMap && File.Exists(testFilename2)) || (alsoTheEditMap && File.Exists(testFilename3))));
}

Volledig onleesbaar is deze code wat mij betreft.

[BalusC]

Hmja, ik scroll liever verticaal dan horizontaal De conditional statement (exp ? stmt1 : stmt2) vermijd ik ook liever in deze context. Dan gebruik ik liever een overzichtelijke if else statement. De conditional statementen gebruik ik eerder bij de zgn. boolean toggles die in 1 regel passen.

Java:

String string = booleanValue ? "stringValue1" : "stringValue2";

[merauder]

Verticaal scrollen ben ik ook niet zo weg van, een simpele druk op 'page-up/page-down' + het scrollwielletje van mijn muis werken toch beter.

[Mastermind]

Ja je moet nu verticaal scrollen omdat het zo'n klein venstertje is. Er zit overigens een pijltje linksboven om het breed te maken.

Op een groot scherm is het zeer overzichtelijk en kan ik in 1 oogopslag zien wat er gebeurt. Superhandig! Ik gebruik zelf camelcasing.

De ident staat hier niet goed omdat dat codeschermpje geen tabs goed weergeeft.

[ Voor 13% gewijzigd door Mastermind op 30-01-2007 13:17 ]

[.oisyn]

merauder schreef op dinsdag 30 januari 2007 @ 13:09:
Verticaal horizontaal scrollen ben ik ook niet zo weg van, een simpele druk op 'page-up/page-down' + het scrollwielletje van mijn muis werken toch beter.

Idd.

Mastermind schreef op dinsdag 30 januari 2007 @ 13:11:
Ja je moet nu verticaal horizontaal scrollen omdat het zo'n klein venstertje is. Er zit overigens een pijltje linksboven om het breed te maken.

Nee, mijn punt is dat je met dergelijke code al snel horizontaal moet scrollen. Ik heb hier een 1920x1440 scherm, en zelfs dan breek ik al eerder af dan jij doet. Da's ook handig als je twee schermen naast elkaar hebt (bijvoorbeeld header/source in c++, of in de gebruikelijke merge tool van je source control systeem).

Op een groot scherm is het zeer overzichtelijk en kan ik in 1 oogopslag zien wat er gebeurt. Superhandig! Ik gebruik zelf camelcasing.

waarom dan af en toe namen beginnen met een hoofdletter?

En je indenting heb je ook nog steeds niet beargumenteerd

[Verwijderd]

merauder schreef op dinsdag 30 januari 2007 @ 12:08:

C++:

 
if (vergelijking==VoorbeeldVoorwaarde)

     {
             cout <<  vooruit << endl;
     }   

else 
    {
            cout <<  achteruit << endl;
    }

Nadeel vind ik hiervan dat je 1) horizontaal een extra indentatie level toevoegt met geen toegevoegde waarde en 2) dat je accolades extra verticale ruimte innemen. Zelf doe ik altijd dit:

C++:

if (vergelijking==VoorbeeldVoorwaarde) {
    cout <<  vooruit << endl;
} else {
    cout <<  achteruit << endl;
}

Vind ik overzichtelijker en compacter. Maar ik weet dat lang niet iedereen het daarmee eens is...

Ik heb trouwens ook wel een het volgende gezien (voor mensen die klagen over het niet kunnen vinden van begin en eind van een blok): puntkomma's vooraan de regel in plaats van achteraan.

Delphi:

while test1 do begin
    while test2 do begin
    ;    func1
    ;    func2
    ;    if blaat then begin
         ;    doIets
         ;    doNogIets
    ;    end
;   break
;   end
end
}

Voorwaarde om dit te kunnen doen is dat de taal het weglaten van de puntkomma voor het eind van een blok toestaat. Ik weet niet of dit in alle talen het geval is...

[BalusC]

Trouwens, hoe denken jullie over het toepassen van de moedertaal in de code? Ik zie best wel veel lappen code met Nederlands/Engels gemixt, wat ik persoonlijk best wel ranzig vind Op buitenlandse forums zie ik ook lappen code met termen in het Spaans, Duits en zelfs Chinees

Voor mijn werk moet ik het Nederlandse taal helaas wel toepassen in de namen van de klassen, methoden en variabelen. Maar voor eigen projectjes zou ik het 100% in het Engels houden. Niet alleen voor de uniformiteit (de sleutelwoorden en operatoren van de codetaal zijn immers ook in het Engels), maar ook voor een betere (internationale) uitwisselbaarheid

[ Voor 6% gewijzigd door BalusC op 30-01-2007 13:43 ]

[Grijze Vos]

Dat is een betrekkelijk normale stijl voor TU/e'ers wat je daar post.

[.oisyn]

BalusC schreef op dinsdag 30 januari 2007 @ 13:42:
Voor mijn werk moet ik het Nederlandse taal helaas wel toepassen in de namen van de klassen, methoden en variabelen.

OMG . Ik vind dat er zo onprofessioneel uitzien altijd. Wij werken met amerikanen en australiers, dus een andere taal dan Engels is sowieso al geen optie, maar zelfs zonder die situatie zouden we hier in het Engels programmeren

[Grijze Vos]

BalusC schreef op dinsdag 30 januari 2007 @ 13:42:
Trouwens, hoe denken jullie over het toepassen van de moedertaal in de code? Ik zie best wel veel lappen code met Nederlands/Engels gemixt, wat ik persoonlijk best wel ranzig vind Op buitenlandse forums zie ik ook lappen code met termen in het Spaans, Duits en zelfs Chinees

Ik doe het eigenlijk altijd in het engels. Soms dan weet ik even geen zinnige naam aan een variabele te geven en dan heet die tijdelijk 'blaat' oid, maar dat verander ik meestal wel als me een zinnige naam te binnen schiet.

Ik heb een keer gepraat met iemand die bij TI aan het werken was aan assembly-code voor de TI-83+, en die moest een stuk code van een spaans-amerikaans vrouwtje debuggen.

Dat was dus iets als

code:

bla1:
  LD A, B
bla2:
  DJNZ bla1
...
...
...
bla273:
...
...

En vul dan voor bla een of ander vaag non-descriptive spaans woord in.

[Mafkees]

Mastermind schreef op dinsdag 30 januari 2007 @ 12:46:
Ik programmeer op deze manier. Ik mag graag compact programmeren, omdat je dan niet zoveel hoeft te scrollen en een goed overzicht hebt over de code.

Een gedeelte van een programma dat ik heb geschreven, toont bijv. aan hoe handig turnaries zijn:

C#:

string ExternContractnr = factuurEnt.TestCurrentFieldValueForNull(FactuurFieldIndex.ExternContractnr) ? "" : factuurEnt.ExternContractnr.Trim();
while (reportNameExists)
{
      achtervoegselStr = (achtervoegsel++).ToString().PadLeft(2, '0');
      TheNextFileName = ExternContractnr.IndexOfAny(Path.GetInvalidFileNameChars()) > 0 || ExternContractnr == ""
       ? aanMaakNr + "_" + achtervoegselStr + "_LaboratoryAnalyses.pdf"
       : aanMaakNr + "_" + achtervoegselStr + "_LaboratoryAnalyses " + ExternContractnr + ".pdf";
                
       testFilename1 = Path.Combine(finaldir1, TheNextFileName);
       if (alsoTheEditMap)
        {
             testFilename2 = Path.Combine(finaldir2, TheNextFileName);
             testFilename3 = Path.Combine(finaldir3, TheNextFileName);
        }

         reportNameExists = (File.Exists(testFilename1) ||  ((alsoTheEditMap && File.Exists(testFilename2)) || (alsoTheEditMap && File.Exists(testFilename3))));
}

Deze code vind ik voornamelijk onduidelijk omdat er 0,0 commentaar bij staat. Verder ga ik grotendeels mee met het commentaar dat al eerder geleverd is maar commentaar in code vind ik een vereiste.

Als ik samenwerk aan een project met iemand en de ander schrijft er geen commentaar bij spreek ik iemand er direct op aan. Vaak krijg je dan te horen van dat doe ik later wel... Hoeveel moeite is het om direct commentaar erbij te schrijven, daar heb je zelf alleen maar baat bij. Tenzij je van plan bent om de hele code te herschrijven omdat het een prototype is maar da's vaak niet zo. Mijn mening over commentaar is dan ook: doe het direct, dan staat het er. Het scheelt je een hoop werk achteraf en je kunt het ook niet meer vergeten.

BalusC schreef op dinsdag 30 januari 2007 @ 13:42:
Trouwens, hoe denken jullie over het toepassen van de moedertaal in de code? Ik zie best wel veel lappen code met Nederlands/Engels gemixt, wat ik persoonlijk best wel ranzig vind Op buitenlandse forums zie ik ook lappen code met termen in het Spaans, Duits en zelfs Chinees

Voor mijn werk moet ik het Nederlandse taal helaas wel toepassen in de namen van de klassen, methoden en variabelen. Maar voor eigen projectjes zou ik het 100% in het Engels houden. Niet alleen voor de uniformiteit (de sleutelwoorden en operatoren van de codetaal zijn immers ook in het Engels), maar ook voor een betere (internationale) uitwisselbaarheid

Ik schrijf mijn code altijd in het Engels, het commentaar erbij gaat in het Nederlands. Misschien beetje krom en zou het commentaar ook in het Engels moeten maar goed, projecten zijn tot dusver enkel voor Nederlandse bedrijven gemaakt.

[BalusC]

.oisyn schreef op dinsdag 30 januari 2007 @ 13:44:
[...]

OMG . Ik vind dat er zo onprofessioneel uitzien altijd. Wij werken met amerikanen en australiers, dus een andere taal dan Engels is sowieso al geen optie, maar zelfs zonder die situatie zouden we hier in het Engels programmeren

Dat was de eis van de klant van de huidige projecten (klant is koning enzo ). Maar voor de rest zijn collega's het wel mee eens dat alles in het Engels zou moeten

Mafkees schreef op dinsdag 30 januari 2007 @ 13:53:
Ik schrijf mijn code altijd in het Engels, het commentaar erbij gaat in het Nederlands. Misschien beetje krom en zou het commentaar ook in het Engels moeten maar goed, projecten zijn tot dusver enkel voor Nederlandse bedrijven gemaakt.

Javadoc's zou ik ook gewoon in het Engels doen. De papieren documentatie van de werking van het geheel kan natuurlijk in alle willekeurige talen geschreven worden.

[ Voor 32% gewijzigd door BalusC op 30-01-2007 13:57 ]

[Mafkees]

BalusC schreef op dinsdag 30 januari 2007 @ 13:54:
Javadoc's zou ik ook gewoon in het Engels doen. De papieren documentatie van de werking van het geheel kan natuurlijk in alle willekeurige talen geschreven worden.

Heb je idd wel een punt.. Ik ga binnenkort (as in vanavond/morgen) beginnen met een nieuw project in PHP en gebruik altijd Java-style documentatie. Ook voor PHP zijn er paketten die dan een mooie website met documentatie kunnen genereren, da's in het Engels vaak dus ook beter als dat in het Engels is idd.

Overtuigd

[JKVA]

BalusC schreef op dinsdag 30 januari 2007 @ 13:54:
[...]

Dat was de eis van de klant van de huidige projecten (klant is koning enzo ). Maar voor de rest zijn collega's het wel mee eens dat alles in het Engels zou moeten

[...]
Javadoc's zou ik ook gewoon in het Engels doen. De papieren documentatie van de werking van het geheel kan natuurlijk in alle willekeurige talen geschreven worden.

Het verschil is vooral dat .oisyn games maakt en zelf zijn domein bepaalt. Ik (en ik denk ook jij) werken aan (waarschijnlijk maatwerk) opdrachten voor klanten. En als dat klanten zijn met een Nederlands domein, welke veel Nederlandse termen bevat, die ook als wens/eis opgeven dat het Nederlands moet zijn, is de keuze voor Nederlands snel gemaakt.

JavaDoc zou ik in dezelfde taal doen als de code.

[.oisyn]

JKVA schreef op dinsdag 30 januari 2007 @ 14:12:

Het verschil is vooral dat .oisyn games maakt en zelf zijn domein bepaalt.

Technisch gezien is Crystal Dynamics onze klant en leveren wij net zoveel maatwerk

Ik (en ik denk ook jij) werken aan (waarschijnlijk maatwerk) opdrachten voor klanten. En als dat klanten zijn met een Nederlands domein, welke veel Nederlandse termen bevat, die ook als wens/eis opgeven dat het Nederlands moet zijn, is de keuze voor Nederlands snel gemaakt.

Leveren jullie de code ook aan de klant? Of blijven jullie ter ondersteuning. Want indien dat laatste maakt het natuurlijk ook niet uit - het gaat erom dat het product werkt en in het Nederlands is, ongeacht hoe dat is gemaakt. En wat als jullie bedrijf nou besluit een deel te outsourcen? Ook daar heeft de klant niets mee te maken, edoch zullen die Indiërs weinig van je Nederlands snappen (niet dat het in het Engels zoveel beter gaat, maar dat terzijde )

JavaDoc zou ik in dezelfde taal doen als de code.

Als het uitmaakt dat de code in het Nederlands is, dan lijkt het me helemaal gewenst dat de documentatie dat natuurlijk ook is.

[ Voor 11% gewijzigd door .oisyn op 30-01-2007 14:28 ]

[JKVA]

.oisyn schreef op dinsdag 30 januari 2007 @ 14:26:
Technisch gezien is Crystal Dynamics onze klant en leveren wij net zoveel maatwerk

Maar die bepalen ook wat voor spel het wordt? Of hebben jullie zelf een concept en ontwerp?

Bij een Engelstalige klant is het natuurlijk sowieso geen probleem. Volgens mij is iedereen het hier er wel mee eens dat Engels mooier is.

Leveren jullie de code ook aan de klant? Of blijven jullie ter ondersteuning. Want indien dat laatste maakt het natuurlijk ook niet uit - het gaat erom dat het product werkt en in het Nederlands is, ongeacht hoe dat is gemaakt. En wat als jullie bedrijf nou besluit een deel te outsourcen? Ook daar heeft de klant niets mee te maken, edoch zullen die Indiërs weinig van je Nederlands snappen (niet dat het in het Engels zoveel beter gaat, maar dat terzijde )

Bij mijn huidige project krijgt de klant de source code. Maar het onderhoud wordt wel bij ons gedaan. Bij een speciale app management afdeling.

Outsourcing speelt nog niet, maar komt gegarandeerd nog. We werken nu al samen met Tsjechen en het is een groot Europees bedrijf, dus ik verwacht dat het nog weleens internationaal gaat.

Als het uitmaakt dat de code in het Nederlands is, dan lijkt het me helemaal gewenst dat de documentatie dat natuurlijk ook is.

Eens

[.oisyn]

JKVA schreef op dinsdag 30 januari 2007 @ 14:53:
[...]


Maar die bepalen ook wat voor spel het wordt? Of hebben jullie zelf een concept en ontwerp?

Wij maken de engine en de tools. Dus wij bedenken helemaal niets aan het spel. Vergelijkbaar met wat jij doet dus neem ik aan.

[ Voor 7% gewijzigd door .oisyn op 30-01-2007 15:31 ]

[JKVA]

.oisyn schreef op dinsdag 30 januari 2007 @ 15:31:
[...]

Wij maken de engine en de tools. Dus wij bedenken helemaal niets aan het spel. Vergelijkbaar met wat jij doet dus neem ik aan.

Aha, dan heb je idd wel iets meer restricties. Ik luister gewoon naar wat de grote baas (klant/architect) wil. Als die vinden dat Nederlands slim is, stel ik wel wat kritische vragen, maar als ze overtuigd zijn van hun gelijk vind ik het best. (beetje politiek )

[BalusC]

De klant is hier een grote speler (RDC/RDW), dan moeten wij wel wat flexibeler zijn