🚀 go-pugleaf

Philip Paeps wrote:

> In be.comp.programming John Bokma <postmaster@castleamber.com> wrote:
>> Philip Paeps wrote:
>> > In be.comp.programming John Bokma <postmaster@castleamber.com>
>> > wrote: 
>> 
>> [ if ... { ]
>> 
>> > Da's de Correcte[tm] (K&R) manier.  Voor functies moet de
>> > inleidende { wel op een nieuwe lijn.  De reden: functies kan je
>> > niet nesten. 
>> 
>> In Perl geen probleem ;-) Maar ik snap de reden niet.
> 
> Functies zijn fundamenteel verschillend van control structures.  Door
> ze lekker veel plaats te laten innemen valt dat ook goed op.  Zo heeft
> men het mij toch steeds uitgelegd, en ik ben het er redelijk mee eens.

Ik niet, ik spring functies ook 4 spaties in (vind ik duidelijker):

......... {

    body
}

dus.

In Perl spring ik veel dingen in, b.v. hashtable vullen:

my %hash = (

    	key1 => value1,
    	key2 => value2,
    	:
    	keyn => valuen,
);

Of dingen als:

foobar(

    	foo,
    	bar,
    	foobar => {

    	    	key1 => value1,   	
    	}
);

(functie aanroep, met o.a. anonyme hash als parameter)

of dingen als:

    	$a->{name} cmp $b->{name}
                  or
    	$b->{value} <=> $a->{value}


>> Ik ben het met Sjoerd eens, zet ze er liever wel neer (tenzij je 100%
>> zeker weet dat er niks bij moet). Handig als je er iets bij wilt
>> zetten om te testen.
> 
> Een kwestie van smaak :-)

Nah, ik heb te vaak gemerkt dat als ik if ... ... schreef ik te vaak 
alsnog een {} nodig had, al was het maar even om iets te printen.

> Mee eens dat als je er wat wilt bijzetten de ontbrekende curlies
> misschien wat op de zenuwen kunnen werken.  Maar het ergert me minder
> dan de curlie-soup in lange single-action control structures.
> 
>     if (foo) {
>          bar(foo);
>     } else if (foobar) {
>          bar (foobar);
>     } else if (borkborkbork) {
>          burp();
>     } else {
>          blub();
>     }
> 
> Smaken verschillen :-P

Dat zijn de beperkingen van C ;-) In Perl zou ik bovenstaande gewoon 
nooit zo opschrijven. En in C zou ik wat meer wit gebruiken.

>> > > (Ok, random inspringen is nog erger).
>> > 
>> > Bweek... 
>>
>> Even vluchtig bekeken, en snap nog steeds niet waarom Perl onleesbaar
>> wordt genoemd. Wellicht C gewenning?
> 
> Perl is niet per definitie onleesbaar.  Perl maakt het de programmeur
> wel makkelijker om onleesbaar te zijn dan C 

Dus: het ligt aan de programmeur, niet aan de taal. En iemand die 
onleesbare Perl schrijft zou ik ook geen C willen zien programmeren, 
omdat dat dan ook onleesbaar wordt.

-- 
John Bokma
                 Voorbeeldscripts in Perl: http://johnbokma.com/perl/
Ervaren Perl / Java programmeur beschikbaar:  http://castleamber.com/
Tevreden opdrachtgevers:     http://castleamber.com/testimonials.html