MS' Coding Guidelines

[whoami]

Mjah, gewoon een wat luchtiger topic en wat leesvoer zo op de vrijdagmiddag:

coding guidelines MS

Wat ik wel vreemd vind, is het feit dat hun guideline is om spaties te gebruiken ipv tabs om te indenteren, en ik vind het ook vreemd dat ze private members niet prefixen met een underscore.

Nuja, het is natuurlijk niet iets waar je zwaar moet aan tillen ofzo. Ieder bedrijf of iedere hobbyist heeft wel z'n eigen guidelines / style, maar ik dacht dat dit wel eens een leuk linkje kon zijn.

[André]

Gebruik jij liever tabs dan spaties?

[drice]

je kan beter spaties gebruiken dan tabs.
Als jij tab op 4 spaties hebt ingesteld en ik op 8 spaties ziet het er niet uit op mijn machine.
Als je echter spaties gebruikt ziet het overal hetzelfde uit

[whoami]

drice schreef op vrijdag 01 april 2005 @ 14:37:
je kan beter spaties gebruiken dan tabs.
Als jij tab op 4 spaties hebt ingesteld en ik op 8 spaties ziet het er niet uit op mijn machine.
Als je echter spaties gebruikt ziet het overal hetzelfde uit

Idd, daar heb je een punt.
Echter, als iedereen binnen jouw dev-team dezelfde settings heeft qua tab-size, dan mag dat geen probleem zijn.

[pjonk]

drice schreef op vrijdag 01 april 2005 @ 14:37:
je kan beter spaties gebruiken dan tabs.
Als jij tab op 4 spaties hebt ingesteld en ik op 8 spaties ziet het er niet uit op mijn machine.
Als je echter spaties gebruikt ziet het overal hetzelfde uit

Yep dat klopt, maar als je besluit dat je toch naar 3 spaties indent wil gaan moet je ineens al je sourcefiles gaan search/replacen anders pas je gewoon ff je tab indent instelling aan. Niet echt flexibel dus mijns inziens.

[Cyphax]

whoami schreef op vrijdag 01 april 2005 @ 14:38:
[...]


Idd, daar heb je een punt.
Echter, als iedereen binnen jouw dev-team dezelfde settings heeft qua tab-size, dan mag dat geen probleem zijn.

Dat klopt, maar je kunt niet echt een verschil zien tussen een tab en een paar spaties, daar heb ik ook nog weleens ruzie mee (je verwacht 4x backspace te doen en ineens mis je op de vorige regel 3 karakters ofzo). Ik heb ook liever spaties.
Sommige editors (notepad++ iig) kunnen ook tabs automatisch converteren naar spaties als je dat wilt. Want tab werkt wel sneller verder.

[whoami]

Cyphax schreef op vrijdag 01 april 2005 @ 14:40:
[...]
Sommige editors (notepad++ iig) kunnen ook tabs automatisch converteren naar spaties als je dat wilt. Want tab werkt wel sneller verder.

Dat kan je in VS.NET ook.

[Verwijderd]

Offtopic: hoe stel je dat in VS.NET in dan?

Ontopic: Voor zover ik weet is het alleen gebruikelijk om te prefixen met een _ als je public en private functie voor de rest dezelfde naam hebben a la:

Visual Basic:

public sub DoQuery(byval strQuery as string)
   _DoQuery(strQuery,connection)
end sub

private sub _DoQuery(byval strQuery as string, byval connection as odbcconnection)
   ' Hier je code
end sub

[pjonk]

Do not use a prefix for member variables (_, m_, s_, etc.). If you want to distinguish between local and member variables you should use “this.” in C# and “Me.” in VB.NET.

Variabelen met dezelfde naam op local en private scope niveau gebruiken vind ik nou niet echt duidelijk, maar goed zoals gezegd het zijn guidelines.

[whoami]

Verwijderd schreef op vrijdag 01 april 2005 @ 14:47:
Offtopic: hoe stel je dat in VS.NET in dan?

Tools / Options / Text Editor / all languages / en dan insert spaces aanduiden.

[MSalters]

JonkieXL schreef op vrijdag 01 april 2005 @ 14:51:
[...]

Variabelen met dezelfde naam op local en private scope niveau gebruiken vind ik nou niet echt duidelijk, maar goed zoals gezegd het zijn guidelines.

Is vrij gangbaar in C++ ctors:

C++:

class X {
  int i;
  X(int i) : i(i) { } 
}

Maar in dat geval is het ook erg duidelijk dat het twee i objecten zijn, die gelijk aan elkaar zijn.

[Verwijderd]

Microsoft meent dat een variable vanuit zijn naamgeving al moet aanduiden dat deze private is. Vandaar.

[whoami]

Verwijderd schreef op vrijdag 01 april 2005 @ 14:54:
Microsoft meent dat een variable vanuit zijn naamgeving al moet aanduiden dat deze private is. Vandaar.

Als ze zeggen dat je een private member niet moet prefixen, dan kan je dat toch niet doen ?

[Verwijderd]

Ik snap alleen niet wat er mis mee is om Hungarian notation te gebruiken?
Ik vind het zelf meestal wel makkelijk om aan de naam van de variabele te zien wat het type is, zonder het op te zoeken (of in vs.net) er met je muis boven te hangen.

[pjonk]

Verwijderd schreef op vrijdag 01 april 2005 @ 14:59:
Ik snap alleen niet wat er mis mee is om Hungarian notation te gebruiken?
Ik vind het zelf meestal wel makkelijk om aan de naam van de variabele te zien wat het type is, zonder het op te zoeken (of in vs.net) er met je muis boven te hangen.

Leesbaarheid van de code is het uitgangspunt en hungarian notation draagt daar niet altijd tot bij. Ik heb vroeger zelf altijd hungarian gebruikt, maar stap daar nu ook vanaf. Ik noem mijn variabelen SQL en niet strSQL lijkt me vrij obvious dat dat een string moet zijn. Verder is het een goede guideline om je procedures niet te lang te maken dan kan je de variabele declaratie nog in je scherm zien (behalve bij privates dan).

[Jaspertje]

Spaties, of tabs maakt volgens mij niet meer of minder uit dan het lettertype wat je gebruikt, want als de ene programmeur op 10px programmeert en de ander op 12px, dan komt er alsnog een verschil bij het uitlijnen

[Daos]

Verwijderd schreef op vrijdag 01 april 2005 @ 14:59:
Ik snap alleen niet wat er mis mee is om Hungarian notation te gebruiken?
Ik vind het zelf meestal wel makkelijk om aan de naam van de variabele te zien wat het type is, zonder het op te zoeken (of in vs.net) er met je muis boven te hangen.

Microsoft vond het eerst ook handig.

Als je een goede ide hebt kan je snel zien welk type je hebt als je een punt achter je variabele zet. Er komt dan een lijstje met het type en alle methoden die je kan gebruiken.

[ Voor 8% gewijzigd door Daos op 01-04-2005 15:16 . Reden: andere url ]

[Verwijderd]

Het probleem met de tabs zie ik niet zo? Zolang je toch overal tabs enkel gebruikt om te indenten, zijn er geen problemen bij coders met verschillende tabsettings:

@ tabstop 2

C++:

class X {
  int i;
  X(int i) : i(i) { } 
}

@ tabstop 4

C++:

class X {
    int i;
    X(int i) : i(i) { } 
}

@ tabstop 8

C++:

class X {
        int i;
        X(int i) : i(i) { } 
}

[ Voor 8% gewijzigd door Verwijderd op 01-04-2005 15:16 ]

[Verwijderd]

Jaspertje schreef op vrijdag 01 april 2005 @ 15:10:
Spaties, of tabs maakt volgens mij niet meer of minder uit dan het lettertype wat je gebruikt, want als de ene programmeur op 10px programmeert en de ander op 12px, dan komt er alsnog een verschil bij het uitlijnen

Als lettertype heb je meestal een monotype lettertype, dus wordt alles wel groter, maar lijnt het nog hetzelfde uit

[Verwijderd]

IK BEN ERG BOOS OP MICR S FT

En dat ben ik al een tijdje. Dat iemand een coding-stijl opstelt en dat aan blijft hangen OK. Vernieuwde inzichten dus nieuwe coding-stijl is ook OK. Echter MicroSoft verandert elke 2 jaar van stijl waarbij een paar brokjes van willekeurige andere stijlen met drogredenen ammekaar gebreeen worden. En vervolgens zeiken ze je af als je op die zogenaamde examens van ze de stijl van vorig jaar gebruikt .
De enige die hier beter van wordt is MicroSoft zelf want ze hebben weer een (drog)reden meer om je examens eerder te laten verlopen.

Oef zo dat moest er even uit.

[DaFeliX]

leuk en aardig, maarover bijvoorbeeld commenting zijn coders het altijd nog niet eens. De een zegt dat je zoveel mogenlijk moet commenten (zodat je code leesbaarder zou zijn), de ander zegt dat je code sowieso goed leesbaar moet zijn, en dat commenting alleen maar tijd vergt en onnodig is

Over het bracket-systeem, dat slaat nergens op. In PHP deed ik bijvoorbeeld:

PHP:

if (statement == answer) {
  // Good
}
else {
  // False
}

Het maakte PHP niet uit of er tussen de statement en '{' nog een enter zit, maar bijvoorbeeld met TCL gaat dat niet werken (else unknown command/unknown character '{'), dus daar moet je het zo doen

code:

if {statement == answer} {
  # Good
} else {
  # False
}

Het is gewoon een kwestie van gewenning, de coder moet het zelf gemakkelijk vinden, de taal moet het toelaten, en dan pas houd je rekening mee dat je code door anderen gelezen kan worden

[flowerp]

DaFeliX schreef op vrijdag 01 april 2005 @ 15:35:
Het is gewoon een kwestie van gewenning, de coder moet het zelf gemakkelijk vinden, de taal moet het toelaten, en dan pas houd je rekening mee dat je code door anderen gelezen kan worden

Vertel dat maar niet tijdens een solicitatie, want ik kan je dan garanderen dat je niet eens het gesprek hoeft af te maken. Geen enkele opdracht gever of collega zit te wachten op een team-genoot die slecht leesbare code schrijft omdie ie zelf een eigenwijze style perse wil aanhouden.

Neem nou maar van mij aan vriend, dat leesbaarheid van code veel belangrijker is. Code wordt altijd vaker gelezen dan geschreven, en code moet altijd onderhouden worden. Ik heb het overigens nog pas gezien dat iemand niet meer op het werk hoefde te komen omdat keer op keer de code die ie schreef onleesbaar bleek, en het de andere collega's onmogelijk veel moeite kostte om maar de kleinste aanpassingen te maken.

[Zoijar]

whoami schreef op vrijdag 01 april 2005 @ 14:29:
en ik vind het ook vreemd dat ze private members niet prefixen met een underscore.

Het is ook nog zo dat een underscore prefix vaak iets reserved is. In C++ is het zelfs zo dat een identifier die met een underscore begint, gevolgd door een hoofdletter officieel reserved is. Als je dan prefixed en een keer per ongeluk een hoofdletter gebruikt, is het eigenlijk geen goed C++. Zelf postfix ik privates met een underscore; dat heb ik bij anderen ook voor zien komen. Plus, bij postfix, zie je het eerder bij het accessen van de member. Vergelijk _longIdentifierNameWossname->x en longIdentifierNameWossname_->x

(je ziet ook vaak dit: #ifndef _HEADER_H_, oid, wat eigenlijk niet mag)

[ Voor 18% gewijzigd door Zoijar op 01-04-2005 21:30 ]

[PrisonerOfPain]

flowerp schreef op vrijdag 01 april 2005 @ 21:04:
Vertel dat maar niet tijdens een solicitatie, want ik kan je dan garanderen dat je niet eens het gesprek hoeft af te maken. Geen enkele opdracht gever of collega zit te wachten op een team-genoot die slecht leesbare code schrijft omdie ie zelf een eigenwijze style perse wil aanhouden.

Mag ik me bij deze dan (wellicht onterrecht..) afvragen waarom de meeste IDE's dan nogsteeds geen functionaliteit hebben voor polystyle achtige features? Na het out checken laten converteren naar mijn stijl, en voor het in check converteren naar de 'gewenste' stijl. Niemand die meer problemen maakt over op welke regel die brackets nu moeten staan, of hoeveel spaties er dit project gebruikt gaan worden.
Alleen zit je dan nog met de naamgeving, maar zelfs daar zou een IDE iets aan kunnen doen.

[Annie]

Using statements should be inside the namespace declaration.

Kan iemand me uitleggen wat het nut hiervan is?

[Zoijar]

Annie schreef op vrijdag 01 april 2005 @ 21:46:
[...]

Kan iemand me uitleggen wat het nut hiervan is?

Dat je je global namespace niet polute ij het includen van headers. Bv:

C++:

//header
using std::cout;
namespace MyCompany {
...
}

//andere file
#include <header>

class cout {}; // ugh
// 'cout' is hier nu global

////////
namespace MyCompany {
using std::cout;
}

// geen problemen

[Verwijderd]

whoami schreef op vrijdag 01 april 2005 @ 14:29:
coding guidelines MS

Lijkt me niet dat dit de coding guidelines zijn van Microsoft. Let wel dat dit een blog is.

Wat ik irritant vind is dat vb-mensen alles willen afkorten. bijv.
lbl ipv label
txt ipv textbox
dsklanten ipv DataSetKlanten.
frm ipv form
... ipv frame

Ik zag overigens wel in MSDN wat guidelines staat voor wat betreft de naamgeving.


Doe eens een vergelijking met Object pascal Style Guide

[ Voor 8% gewijzigd door Verwijderd op 01-04-2005 23:01 ]

[klinz]

drice schreef op vrijdag 01 april 2005 @ 14:37:
Als jij tab op 4 spaties hebt ingesteld en ik op 8 spaties ziet het er niet uit op mijn machine.

Enkel de indentation is dan groter. Het echte probleem krijg je pas als je spaties en tabs door elkander gaat gebruiken.

[Verwijderd]

klinz schreef op vrijdag 01 april 2005 @ 23:01:
[...]
Enkel de indentation is dan groter. Het echte probleem krijg je pas als je spaties en tabs door elkander gaat gebruiken.

Dan krijg je inderdaad het zelfde probleem als dat mensen niet goed met MS Word kunnen omgaan en bijvoorbeeld enters geven om op de volgende bladzijde te komen. Of tabs en spaties door elkaar gebruiken om regels onderaan te gaan uitlijnen.
Tsja, en dan heb je en probleem als je wilt printen op verschillende printers, omdat de verschillende printers anders marges hanteren en alles dus niet goed wordt afgedrukt. Of als je op een ander papierformaat wilt afdrukken en de tekst automatisch aangepast wordt bij het afdrukken.

[Cyphax]

klinz schreef op vrijdag 01 april 2005 @ 23:01:
[...]
Enkel de indentation is dan groter. Het echte probleem krijg je pas als je spaties en tabs door elkander gaat gebruiken.

En DAT krijg je met name als anderen in dezelfde bestanden moeten sleutelen. Ik merk dat op het werk weleens, allemaal ASP pagina's waar door verschillende mensen aan gewerkt wordt. Sommige pagina's zijn gewoon door meerdere mensen gemaakt en dan krijg je qua layout mede door tabs/spaties echt een dramatische layout...

[Verwijderd]

PrisonerOfPain schreef op vrijdag 01 april 2005 @ 21:39:
Mag ik me bij deze dan (wellicht onterrecht..) afvragen waarom de meeste IDE's dan nogsteeds geen functionaliteit hebben voor polystyle achtige features? Na het out checken laten converteren naar mijn stijl, en voor het in check converteren naar de 'gewenste' stijl.

Lijkt me de meest zinloze toevoeging aan een IDE ooit.
Als je met meerdere mensen aan een project werkt, gewoon samen afspreken wat de coding style is, of de coding style die de 'baas' dicteert gebruiken. Dan is er geen enkele conversie nodig.

[Mithrandir]

Verwijderd schreef op vrijdag 01 april 2005 @ 23:39:
[...]

Lijkt me de meest zinloze toevoeging aan een IDE ooit.
Als je met meerdere mensen aan een project werkt, gewoon samen afspreken wat de coding style is, of de coding style die de 'baas' dicteert gebruiken. Dan is er geen enkele conversie nodig.

Het lijkt mij juist extreem makkelijk als je een paar stukjes (enkele honderden regels bijvoorbeeld) van code gebruikt waar verder geen rechten op liggen (of open-source met bronvermelding etc) dat je dat snel kun tconverteren naar je eigen gangbare leesstijl.

[Verwijderd]

In zo'n geval vind ik 't juist prettig dat de coding style afwijkt.
Als je dan een half jaar later nog 's naar die code kijkt (met alle Delphi keywords in CAPS bijvoorbeeld), dan zie je direct: "o ja, dat stukkie is niet van ons".

[Delphi32]

Ik sluit me aan bij de polystyle-mensen. Het maakt me in principe weinig uit welke stijl gehanteerd wordt bij het coden, ik lees alles wel. En als het echt onleesbaar wordt gooi ik er een pretty printer overheen en voilà: leesbaar. Leesbaar? VOOR MIJ. Maar niet voor degene die het stukje code oorspronkelijk heeft geschreven.
Stijl is een kwestie van smaak, waarom zou je die opdringen aan een ander?

Wat anders is de naamgeving van variables, files, classes, dat soort dingen. Als iemand hungarian wil gebruiken, be my guest, maar ik hoop niet dat je dat van mij ook verwacht Of een project (heb ik pas verbouwd) dat uit 70 files bestaat die Unit1, Unit2... Unit70 heten, dat werkt natuurlijk ook niet. Daar wordt de grens tussen leesbaarheid en inzichtelijkheid ernstig overschreden imho.

offtopic:
Dan heb ik het nog niet over het feit dat UnitX stiekum UnitY gebruikt, alles in forms geprogd was en de forms allemaal afhankelijk zijn van elkaar... dat is geen kwestie van style guide, dat is een kwestie van onhandig programmeren. En helaas mag ik daar onderhoud op doen

[TheGhostInc]

Jemig, ik hoop echt dat ik nooit een "polystyle"-collega krijg.
Het continu gezeik over tabs, haakjes en andere meuk.

Het klinkt in mijn ogen als puberaal gedrag "Ik wil het net even anders doen, lekker puh"

Daarnaast word je in een CVS systeem helemaal knetter als iedereen net iets andere formatters gebruikt, continu updates zonder verschil.

Over variabelen namen, tja, dat is echt iets wat je per project kunt bepalen.
Het ene project zit bomvol met verschillende typen en casts en omzettingen.
Andere projecten komen niet veel verder dan wat int's, strings en een lokale boolean.

Stijl is een kwestie van smaak, waarom zou je die opdringen aan een ander?
Mijn smaak is om mensen op de weg altijd af te snijden... waarom moet iemand mij corrigeren?

Stijl is niet alleen een kwestie van smaak, maar ook een vorm van communiceren, door jouw stijl te gebruiken dring je die al op aan een ander, dus kun je maar beter 1 stijl aan iedereen opdringen.

[whoami]

Annie schreef op vrijdag 01 april 2005 @ 21:46:
[...]

Kan iemand me uitleggen wat het nut hiervan is?

Dat snap ik ook niet; vooral omdat de using statements die door vs.net al gegenereerd worden, ook buiten je namespace staan.

[whoami]

PrisonerOfPain schreef op vrijdag 01 april 2005 @ 21:39:
[...]

Mag ik me bij deze dan (wellicht onterrecht..) afvragen waarom de meeste IDE's dan nogsteeds geen functionaliteit hebben voor polystyle achtige features? Na het out checken laten converteren naar mijn stijl, en voor het in check converteren naar de 'gewenste' stijl. Niemand die meer problemen maakt over op welke regel die brackets nu moeten staan, of hoeveel spaties er dit project gebruikt gaan worden.
Alleen zit je dan nog met de naamgeving, maar zelfs daar zou een IDE iets aan kunnen doen.

Je houden aan de coding style binnen het bedrijf is gewoon belangrijk.
Ik dacht dat in VS.NET 2005 er wel een functie is waarmee je je formatting kunt gaan bepalen.

[ATS]

Zelf prefereer ik spaties boven tabs, omdat je dan ook dingen als

eenFunctie(lang_argument,
nog_een_lang_argument,
foo);

netjes kan uitlijnen, wat met alleen tabs nooit lukt, terwijl het mengen van tabs en spaties helemaal een recept voor chaos is. Voor wat betreft member variabelen (die horen bijna per definitie private te zijn) is een andere methode ze te prefixen met m_. Puur een _ wil nog wel eens een speciale betekenis hebben. Hungarian gaat mij ook te ver, daar wordt m.i. de code uiteindelijk niet leesbaarder van. Veel belangrijker is het duidelijk te zijn in wat de variabele representeert. Simpele afkortingen zoals txt, lbl, zijn daarin wat mij betreft geen probleem, maar voor de rest is het uitkijken met afkortingen.

Wat je precies gebruikt is inderdaad niet zo belangrijk, als je het maar consistent doet en als je maar, als je in een team werkt, allemaal hetzelfde doet.

[whoami]

Verwijderd schreef op vrijdag 01 april 2005 @ 23:00:
[...]

Lijkt me niet dat dit de coding guidelines zijn van Microsoft. Let wel dat dit een blog is.

Brad Adams is een MS employee, en aangezien de titel 'internal guidelines' is....

[Infinitive]

Deze coding styles staan ook gewoon in MSDN opgeschreven, wat is daar zo bijzonder aan?

[Zoijar]

ATS schreef op zaterdag 02 april 2005 @ 09:57:
Zelf prefereer ik spaties boven tabs, omdat je dan ook dingen als

eenFunctie(lang_argument,
nog_een_lang_argument,
foo);

netjes kan uitlijnen, wat met alleen tabs nooit lukt,

C++:

    eenFunctie(
        lang_argument,
        nog_een_lang_argument,
        foo
    );

[Delphi32]

TheGhostInc schreef op zaterdag 02 april 2005 @ 01:36:
Jemig, ik hoop echt dat ik nooit een "polystyle"-collega krijg.
Het continu gezeik over tabs, haakjes en andere meuk.
...
Daarnaast word je in een CVS systeem helemaal knetter als iedereen net iets andere formatters gebruikt, continu updates zonder verschil.

Het idee achter polystyle is nou juist dat het gezeur over tabs, haakjes en andere meuk niet meer nodig is Even wat voorbeelden, 2 styles om hetzelfde te bereiken in Delphi:

Delphi:

//voorbeeld 1
if (a > 10) then begin
  DoSomethingSpecial;
end;

//voorbeeld 2
if (a > 10) then
begin
  DoSomethingSpecial;
end;

Welke stijl jouw persoonlijke voorkeur heeft doet voor het uiteindelijke programma niet terzake: beide statements doen hetzelfde. Stel jij hebt 10 jaar gewerkt in een bedrijf dat voorbeeld 1 als stijlnorm heeft gehanteerd, en je komt daarna in een bedrijf dat stijl 2 gebruikt. Hoe lang duurt het voor je omgeschakeld bent? Mijn ervaring is dat dat best lang kan duren (hangt van de lengte en gedetailleerdheid van de syle guide af natuurlijk).
Zou het niet simpeler zijn als alle code in de CVS er op een zekere manier uit zag (welke doet niet terzake) en bij het ophalen naar jouw systeem automatisch naar jouw ingestelde stijl geconverteerd werd? En bij het inchecken wordt de boel uiteraard weer automatisch geconverteerd naar het uniforme formaat -> iedereen de leesbaarheid die hij wil bereiken zonder gezeur over 'je bent de style guide weer vergeten'! Uitchecken + aanpassen aan jouw stijl, geen wijziging en opnieuw inchecken = geen wijziging in CVS, dus je argument is niet valide.
Zeker als je voor meerdere opdrachtgevers werkt (als freelancer of detacheerder) lijkt me dit een ideale situatie.

Stijl is een kwestie van smaak, waarom zou je die opdringen aan een ander?
Mijn smaak is om mensen op de weg altijd af te snijden... waarom moet iemand mij corrigeren?

Beetje flauw argument, ga ik niet op in (tenzij uitgedaagd )

Stijl is niet alleen een kwestie van smaak, maar ook een vorm van communiceren, door jouw stijl te gebruiken dring je die al op aan een ander, dus kun je maar beter 1 stijl aan iedereen opdringen.

Geloof ik niet in. Zolang de code hetzelfde blijft doen, maakt het echt geen ene ruk uit in welke stijl dat geschreven is. En dus is een tool die de code automatisch formatteert naar jouw gewenste stijl een prachtige zaak, want dan is het voor jou leesbaar en schrijfbaar. Als programmeur 2 een andere stijl wil, stelt ie die gewoon in en ook hij is tevreden.

Dat heeft niets met puberaal gedrag te maken, maar alles met scheiding van data en presentatie, een concept dat de meeste programmeurs hier toch bekend in de oren moet klinken

[flowerp]

Opzich heb je natuurlijk wel gelijk dat je zelf je view op je source wilt kunnen bepalen, maar bij formattering werkt dat toch anders. Een automatische formatter neemt namelijk je hele source mee volgens bepaalde regels. In sommige situaties wil je toch een kleine uitzondering maken, of doe je iets wat wel binnen de style van je team valt, maar wat de formatter weer niet mee neemt.

Verwacht dus niet dat je bij het inchecken en uitchecken volgens jouw gedachte exact dezelfde source terug krijgt.

Met VS valt er weinig in te stellen voor de automatische formatting, maar bij Eclipse heb je iets van 100 opties die je kunt instellen daarvoor. En zelfs daar heb je nog dingen die weer niet automatisch gaan: bijvoorbeeld, wij hebben de style regel dat er na de function signature een lege regel moet als de functie meer dan 'enkele' regels lang is. Nu heeft Eclipse meer dan 100 opties, maar die zit er dan weer net niet bij.

Voorderest lost het het haakjes probleem wel goed op. Voor Java heb je ook een conventie, en die zegt dat openings haakjes op dezelfde regel moeten als de construct waar het bij hoort. Het is bijna een cult, maar je hebt altijd mensen die hem perse op een aparte regel willen. (nooit begrepen waarom, maar goed). Zulke dingen los je wel op met auto formatting.

Een tool die ook kan helpen is checkStyle. Daarmee kun je veel dingen style dingen testen in je source en zelfs automatisch als warnings of errors laten weergeven in je IDE. Je kunt dan bijvoorbeeld voor variable namen reguliere expresses opstellen. Handig voor collega's die elke variable altijd value, values, theValues oid willen noemen in plaats van wat er echt inzit, of collega's die hardnekkig underscore style gebruiken (dit_is_een_var ipv ditIsEenVar) etc.

[Sv3n]

in een variable naam meegegeven welke type het is, hoeft toch helemaal niet ? instance variablen zet je altijd boven of onderaan (ik boven) en variablen die binnen een functie worden gemaakt boven/onderaan de functie, dan kun je toch altijd snel opzoeken welke type het is als je het even niet weet, meestal is het toch wel duidelijk, want bijv. een naam is niet vaak van het type int

verder gebruik ik ook altijd spaties, word me zo aangeleerd op school, qua naamgeving moeten we "ditIsEenVariable" gebruiken

[ Voor 8% gewijzigd door Sv3n op 03-04-2005 23:09 ]

[flowerp]

Wat ik me wel eens afvraag, waar komt nou die rare style vandaan met accolades recht onder elkaar (heeft deze style eigenlijk een naam?

Ik bedoel dus:

Java:

void func( int bar ) {
   // body
}

VS

Java:

void func( int bar )
{
   // body
}

Wat me opvalt is dat echt elk boek dat over programmeren gaat in Java, C# of C++ en zelfs javascript, de eerste style gebruikt. En ik heb best wel veel boeken gelezen. In magazines eigenlijk hetzelfde, CUJ, Dr Dobs, JavaPro, online mags, allemaal die eerste style. Kijk je in diktaten op hoge scholen of universiteiten, weer alleen die eerste style.

Waar komt dus de 'rare' style met accolades onder elkaar toch vandaan? Mensen moeten toch ooit leren programmeren? Gaan ze dan zomaar automatisch vanuit hun zelf de haakjes onder elkaar zetten? De meeste beginnende programmeurs gaan toch niet source code van andere door spitten om zo door deze style beinvloed te worden ofzo?

[megamuch]

flowerp schreef op zondag 03 april 2005 @ 23:54:
Wat ik me wel eens afvraag, waar komt nou die rare style vandaan met accolades recht onder elkaar (heeft deze style eigenlijk een naam?

Ik bedoel dus:

Java:

void func( int bar ) {
   // body
}

VS

Java:

void func( int bar )
{
   // body
}

Wat me opvalt is dat echt elk boek dat over programmeren gaat in Java, C# of C++ en zelfs javascript, de eerste style gebruikt. En ik heb best wel veel boeken gelezen. In magazines eigenlijk hetzelfde, CUJ, Dr Dobs, JavaPro, online mags, allemaal die eerste style. Kijk je in diktaten op hoge scholen of universiteiten, weer alleen die eerste style.

Waar komt dus de 'rare' style met accolades onder elkaar toch vandaan? Mensen moeten toch ooit leren programmeren? Gaan ze dan zomaar automatisch vanuit hun zelf de haakjes onder elkaar zetten? De meeste beginnende programmeurs gaan toch niet source code van andere door spitten om zo door deze style beinvloed te worden ofzo?

Waar het vandaan komt weet ik niet, maar ik vind style 2 veel prettiger werken Ik schrijf dus zelf ook alleen code met haakjes onder elkaar. Bij diepgeneste if's enzo vind ik style 2 gewoon beter leesbaar en kan ik eerder zien in welke 'laag' ik bezig ben.

Goed, ik schrijf dan ook voornamelijk procedural code in PHP en heb er nooit voor gestudeerd, maar vanuit mijn oogpunt is style 1 juist weer zwaar onduidelijk.

[Daventry]

flowerp schreef op zondag 03 april 2005 @ 23:54:
Wat ik me wel eens afvraag, waar komt nou die rare style vandaan met accolades recht onder elkaar (heeft deze style eigenlijk een naam?

Ik bedoel dus:

Java:

void func( int bar ) {
   // body
}

VS

Java:

void func( int bar )
{
   // body
}

Is een eeuwig discussiepunt wat nou precies het beste is ... heeft op zich niks met java of C te maken - ik gebruikte meestal het tweede tot ik op mijn bedrijf nu gevraagd werd het eerste te doen. Maakt dus geen moer uit - ben je gewoon op een uurtje.

Wat wel behoorlijk irritant is, is dat (als ik me niet vergis) om een of andere reden in C# methoden met een hoofdletter beginnen en in JAVA niet - da's het soort dingen wat veel lastiger gewoon te worden is

[rapture]

flowerp schreef op zondag 03 april 2005 @ 23:54:
Wat ik me wel eens afvraag, waar komt nou die rare style vandaan met accolades recht onder elkaar (heeft deze style eigenlijk een naam?

Ik bedoel dus:

Java:

void func( int bar ) {
   // body
}

VS

Java:

void func( int bar )
{
   // body
}

Wat me opvalt is dat echt elk boek dat over programmeren gaat in Java, C# of C++ en zelfs javascript, de eerste style gebruikt. En ik heb best wel veel boeken gelezen. In magazines eigenlijk hetzelfde, CUJ, Dr Dobs, JavaPro, online mags, allemaal die eerste style. Kijk je in diktaten op hoge scholen of universiteiten, weer alleen die eerste style.

Waar komt dus de 'rare' style met accolades onder elkaar toch vandaan? Mensen moeten toch ooit leren programmeren? Gaan ze dan zomaar automatisch vanuit hun zelf de haakjes onder elkaar zetten? De meeste beginnende programmeurs gaan toch niet source code van andere door spitten om zo door deze style beinvloed te worden ofzo?

eerste variant, het minste typwerk, gewoon spatie, accolade open, een brok code en accolade sluiten.

tweede variant, iets overzichtelijker. De accolades staan lekker onder elkaar, zodat je kan zien welke accolade bij welke accolade hoort. Dit wordt bij ons in de Java-lessen aangeraden, het is iets handiger om te debuggen.

[Verwijderd]

flowerp schreef op zondag 03 april 2005 @ 23:54:
Wat ik me wel eens afvraag, waar komt nou die rare style vandaan met accolades recht onder elkaar (heeft deze style eigenlijk een naam?

Jawel, en die heet BSD stijl.

Wikipedia weet het, zoals gewoonlijk, beter.

[Zoijar]

Ik heb zo'n gruwelijke hekel aan die accolades-onder -elkaar-stijl....ugh, hoe verspil ik het meeste ruimte op een scherm dat toch al niet zo groot is...Plus dat het er gewoon niet mooi uitziet, niet gebalanceerd. (K&R is de enige correcte stijl)

[ Voor 9% gewijzigd door Zoijar op 04-04-2005 01:52 ]

[megamuch]

Zoijar schreef op maandag 04 april 2005 @ 01:50:
Ik heb zo'n gruwelijke hekel aan die accolades-onder -elkaar-stijl....ugh, hoe verspil ik het meeste ruimte op een scherm dat toch al niet zo groot is...Plus dat het er gewoon niet mooi uitziet, niet gebalanceerd. (K&R is de enige correcte stijl)

buy a bigger screen then...

Het ziet er duidelijker uit, en please, opmerkingen als "enige correcte stijl" zijn zeer negatief. Laat dat gewoon weg. Voor jou is het misschien beter, voor mij is BSD style "de enige correcte stijl".

Er is niet 1 correcte, er zijn gewoon verschillende smaken.

[rapture]

Zoijar schreef op maandag 04 april 2005 @ 01:50:
Ik heb zo'n gruwelijke hekel aan die accolades-onder -elkaar-stijl....ugh, hoe verspil ik het meeste ruimte op een scherm dat toch al niet zo groot is...Plus dat het er gewoon niet mooi uitziet, niet gebalanceerd. (K&R is de enige correcte stijl)

Daarom hebben de laptops bij ons op de hoge school een 1600x1200 scherm, sommige laptops zijn zelfs special-editions voor onze hoge school only. Deze kan ik direct op eBay of in de krant herkennen.

K&R is minder handig om te debuggen, in VB.net is dat niet zo belangrijk, want de meeste dingen gaan toch automagisch. Als je in jGrasp/Textpad Java zit te programmeren, dan weet je waarom ik voor accolades-onder elkaar kies.

[T-MOB]

* T-MOB checkt code...
Jep, gebruikt "vreemde accolades onder elkaar"-methode. Ik vind het er wel netjes uitzien omdat je redelijk snel kunt zien welke opening bij welke sluitingsaccolade hoort: makkelijk debuggen dus. Maar eigenlijk boeit codingstyle me niet zo, zolang ze maar consequent is in een enkel bestand is het toch wel leesbaar en werken als programmeur zal ik toch nooit doen...

[Verwijderd]

ach jullie moesten eens weten......

Ooit al eens in Navision geprogrammeerd ? De taal is Pascal ( Navision heeft toendertijd Pascal 3 o.i.d. gekocht van Borland voor gebruik in Navision ).
Maar : je mag spaties, punten etc in variabele-namen gebruiken ! Wil je dan je variabele gebruiken, moet je er dubbele quotes omheen zetten. Dan krijg je dus code als

code:

"Sale Line"."Item No." := 'AB123' ;

is wel ff wennen als je talen als VB etc. gewend bent.

Nog een leuke : In Powerbuilder mag je zowel ' als " als string delimiter gebruiken. Kan wel eens handig zijn als je quotes in je string nodig hebt, maar kan ook verwarrend zijn.

[Verwijderd]

Trouwens, om terug te komen op hoe je in Pascal/Delphi achtige talen een if-statement indent : Ik doe het zo :

Delphi:

if Voorwaarde then
  begin
    {hoop code}
  end
else
  begin
    {andere hoop code}
  end ;

Veel mensen vinden de indent van de begin onzinnig. Ikzelf vind dit goed leesbaar, omdat zowel de delen van de if-statement alsmede de begin/end paren onder elkaar staan.

[Verwijderd]

Sv3n schreef op zondag 03 april 2005 @ 23:04:
(...)
verder gebruik ik ook altijd spaties, word me zo aangeleerd op school, qua naamgeving moeten we "ditIsEenVariable" gebruiken

camelCasing heet die

[Genoil]

Ik moest een keer een klusje via een reclamebureau voor Microsoft NL doen, en op een gegeven moment moest m'n code naar zo'n ventje bij MS omdat die er nog wat aan toe moest voegen. Kreeg ik alles terug met de accolades onder elkaar, ipv '1e { op dezelfde regel'. Ik moest toen zelf ook weer wat wijzigingen doorvoeren, dus ik dacht ik ga dat ventje een beetje zieken door alle { weer terug te zetten.

Kreeg ik zoo'n mailtje terug, geCCed aan m'n opdrachtgever bij dat reclamebureau, over dat dat toch echt niet de bedoeling was, blahdieblah MS coding conventions enzo. M'n opdrachtgever begreep er niks van maar vond het wel grappig dat ik dat die gast van MS op de kast had gekregen, deed ie zelf ook graag

[riezebosch]

whoami schreef op vrijdag 01 april 2005 @ 14:29:
Mjah, gewoon een wat luchtiger topic en wat leesvoer zo op de vrijdagmiddag:

coding guidelines MS

Wat ik wel vreemd vind, is het feit dat hun guideline is om spaties te gebruiken ipv tabs om te indenteren, en ik vind het ook vreemd dat ze private members niet prefixen met een underscore.

Nuja, het is natuurlijk niet iets waar je zwaar moet aan tillen ofzo. Ieder bedrijf of iedere hobbyist heeft wel z'n eigen guidelines / style, maar ik dacht dat dit wel eens een leuk linkje kon zijn.

In de wikipedia link van OneOfBorg staat misschien de verklaring voor het gebruik van spaties ipv tabs:

quote: http://en.wikipedia.org/wiki/One_True_Brace_Style

They can also help with the cross-platform tab confusion by being configured to insert only spaces.

[Verwijderd]

riezebosch schreef op maandag 04 april 2005 @ 10:54:
In de wikipedia link van OneOfBorg staat misschien de verklaring voor het gebruik van spaties ipv tabs:
http://en.wikipedia.org/wiki/One_True_Brace_Style

Wow, is die GNU style voor mensen met dyslexie of iets dergelijks? Dat wordt echt duidelijk een indentie-hel.

Een programmeur zou zich niet bezig moeten houden met opmaak, dat zou een IDE moeten doen. Ik vind dus dergelijk delen van guide-lines onzinnig. Naamgeving daarentegen zou veel meer aandacht moeten krijgen; Goede naamgeving maakt immers commentaar overbodig (niet te verwarren met documentatie).

[Daventry]

Genoil schreef op maandag 04 april 2005 @ 10:36:
Ik moest een keer een klusje via een reclamebureau voor Microsoft NL doen, en op een gegeven moment moest m'n code naar zo'n ventje bij MS omdat die er nog wat aan toe moest voegen. Kreeg ik alles terug met de accolades onder elkaar, ipv '1e { op dezelfde regel'. Ik moest toen zelf ook weer wat wijzigingen doorvoeren, dus ik dacht ik ga dat ventje een beetje zieken door alle { weer terug te zetten.

Kreeg ik zoo'n mailtje terug, geCCed aan m'n opdrachtgever bij dat reclamebureau, over dat dat toch echt niet de bedoeling was, blahdieblah MS coding conventions enzo. M'n opdrachtgever begreep er niks van maar vond het wel grappig dat ik dat die gast van MS op de kast had gekregen, deed ie zelf ook graag

Ik hoop van harte dat ik NOOIT in hetzelfde bedrijf als jij landt en jouw code moet onderhouden

[Verwijderd]

Al is het op zich ook een fout van Microsoft dat ze iemand die wat bij moet programmeren niet van de coding-guidelines op de hoogte stellen.

Als wij een project doen, en er zou een programmeur bijkomen, mag hij naast de documentatie over het project ook de coding-guidelines doornemen. En of hij het met die guidelines eens is of niet, daar zal iemand zich aan moeten houden.

In hoevverre is het bij anderen eigenlijk gebruikelijk om bij *elke* functie (in commentaar) aan te geven wat de pre- en post- condities zijn?

[Verwijderd]

Verwijderd schreef op maandag 04 april 2005 @ 11:26:
In hoevverre is het bij anderen eigenlijk gebruikelijk om bij *elke* functie (in commentaar) aan te geven wat de pre- en post- condities zijn?

Bij mij volledig gebruikelijk. Ik moet er niet aan denken dat iedereen de methodes/functies/subroutines door moet spitten om aan dergelijke informatie te komen.

[Zoijar]

megamuch schreef op maandag 04 april 2005 @ 02:02:
buy a bigger screen then...

Het ziet er duidelijker uit, en please, opmerkingen als "enige correcte stijl" zijn zeer negatief. Laat dat gewoon weg. Voor jou is het misschien beter, voor mij is BSD style "de enige correcte stijl".

Er is niet 1 correcte, er zijn gewoon verschillende smaken.

Haha, dat was toch een sarcastisch bedoelde opmerking Zoals je op wikipedia kon lezen, is K&R 'the one true brace style' Maar serieus, ik blijf er toch bij hoor. Een groter scherm kopen...ehh ja, een duurder scherm en in hogere resolutie zodat je letters kleiner worden en moelijker te lezen...dit allemaal om maar vast te houden aan accolades onder elkaar. Bij mij sluit een accolade gewoon de functie of het block dat op dezelfde hoogte begint.

C++:

// dit is gewoon niet duidelijk:
void foo()
{
   struct A
   {
      int i;
   };

   try
   {
      {
         // allocate stuff in auto ptr
      }
      // use out-of-scope stack unwinding to automatically deallocate
   }
   catch (...)
   {
      // handle
   }
}

////////////
void foo() {
   struct A {
      int i;
   };

   try {
      {
         // allocate stuff in auto ptr
      }
      // use out-of-scope stack unwinding to automatically deallocate
   } catch (...) {
      // handle
   }
}

Maar ik ga geen holy war beginnen; doe wat je wilt

(als je productiviteit in regels code wordt gemeten, dan is BSD natuurlijk zeker aan te raden...)

[ Voor 7% gewijzigd door Zoijar op 04-04-2005 12:13 ]

[Verwijderd]

Ik vind beide even leesbaar. Alleen heeft die BSD variant gewoon een hoop nutteloze regels

[riezebosch]

Zoijar schreef op maandag 04 april 2005 @ 12:10:
[...]

C++:

// dit is gewoon niet duidelijk:
void foo()
{
   struct A
   {
      int i;
   };

   try
   {
      {
         // allocate stuff in auto ptr
      }
      // use out-of-scope stack unwinding to automatically deallocate
   }
   catch (...)
   {
      // handle
   }
}

////////////
void foo() {
   struct A {
      int i;
   };

   try {
      {
         // allocate stuff in auto ptr
      }
      // use out-of-scope stack unwinding to automatically deallocate
   } catch (...) {
      // handle
   }
}

Waarom nogmaals accolades openen/sluiten in de try
_{Of heeft dat te maken met allocate stuff in auto ptr?}

Als ik heel eerlijk ben vind ik met name dat try/catch blok in de bovenste beter leesbaar.

[Soultaker]

flowerp schreef op zondag 03 april 2005 @ 23:54:
Wat ik me wel eens afvraag, waar komt nou die rare style vandaan met accolades recht onder elkaar (heeft deze style eigenlijk een naam?

Whoah; kom je dat nooit tegen? Ik schrijft dat zelf altijd zo, voornamelijk omdat je blokken code zo makkelijk kunt copy-pasteën.

Wat me opvalt is dat echt elk boek dat over programmeren gaat in Java, C# of C++ en zelfs javascript, de eerste style gebruikt. En ik heb best wel veel boeken gelezen.

Een goede reden daarvoor is dat die stijl minder ruimte inneemt, en ruimte op papier is 'duur', terwijl ruimte op de harde schijf praktisch gratis is. (Je kunt sowieso ruimschoots voldoende regels kwijt op je scherm, dus er is geen noodzaak om je code verticaal compact te maken.)

Ik gebruik zelf hier op GoT ook vaak die K&R-style, juist om de hoeveelheid code in een post beperkt en overzichtelijk te houden.

edit:
Overigens moet ik zeggen dat ik het wel storend vind dat die try/catch-dingen zoveel ruimte innemen op deze manier, die wil ik nog wel eens afkorten:

C++:

try {
    foo();
} catch(const Bar &bar) {
    // whatever.
};

Anders ben je voor code van twee statements (een regel code en een regel exception handling) al 7 regels kwijt, en zo 'maar' 5.

[ Voor 18% gewijzigd door Soultaker op 04-04-2005 14:18 ]

[Sv3n]

Verwijderd schreef op maandag 04 april 2005 @ 11:26:
In hoevverre is het bij anderen eigenlijk gebruikelijk om bij *elke* functie (in commentaar) aan te geven wat de pre- en post- condities zijn?

word mij op school wel aangeleerd en heb het nut zelf al uitgevonden tijdens een project (waar we ze niet gebruikten )

[eamelink]

Het maakt mij eigenlijk vrij weinig uit wat voor coding guidelines er gebruikt worden, zolang er maar niet teveel commentaar in staat.

Je ziet zo vaak dat het commentaar groter is dan de functies zelf en dergelijke, en dat kan gruwelijk irritant zijn. Je blijft scrollen, en ziet door het commentaar de code niet meer.

Vaak is dat het geval als mensen automatische doc-generators gebruiken, en alle info over een functie erboven zetten. In grote projecten is het haast onoverkomelijk, maar voor simpele kleine dingen, of wat php scriptjes, is het gewoon irritant.

Comments moet je minimaal houden.

[Verwijderd]

Hangt ervanaf... voor een

Visual Basic .NET:

sub PleurOpScherm (byval strMessage) 
  ' Pre: Geen vereisten
  ' Post: Melding staat op het scherm
  ' Deze functie zet een mededeling op het scherm
  if (not isnull strMessage)  
    Response.Write (strMessage & vbCrLF)
  end if
  ' Klaar
end sub

Is inderdaad behoorlijk overkill... maar als je (ook al is het eenregelig) een erg ingewikkeld stukje code hebt, of het niet meteen in een oogopslag duidelijk is wat er gebeurd, is commentaar wel handig

[Daos]

Verwijderd schreef op dinsdag 05 april 2005 @ 09:08:
Hangt ervanaf... voor een

Visual Basic .NET:

sub PleurOpScherm (byval strMessage) 
  ' Pre: Geen vereisten
  ' Post: Melding staat op het scherm
  ' Deze functie zet een mededeling op het scherm
  if (not isnull strMessage)  
    Response.Write (strMessage & vbCrLF)
  end if
  ' Klaar
end sub

Is inderdaad behoorlijk overkill... maar als je (ook al is het eenregelig) een erg ingewikkeld stukje code hebt, of het niet meteen in een oogopslag duidelijk is wat er gebeurd, is commentaar wel handig

Is geen overkill, maar nog te weinig. Je gaat normaal niet bij elke functie in de code kijken. In het commentaar moet er ook bij wat er gebeurt als strMessage null is

[drice]

Ik zit op dit moment in cursus bij Java en die zeggen dat je moet proggen met braces onder elkaar.
Misschien ook omdat je code blocks altijd mag beginnen

code:

    public blaat(blaat owner)
    {
        super(owner, Settings.getString("options"), true);
        {
        setVisible( true );
        }
    }

[Genoil]

Daventry schreef op maandag 04 april 2005 @ 11:13:
[...]


Ik hoop van harte dat ik NOOIT in hetzelfde bedrijf als jij landt en jouw code moet onderhouden

Maak je niet druk! Ik ben namelijk (mede-)eigenaar, en wij nemen geen programmeurs aan die zich druk maken over waar een accolade moet staan

[Michali]

Ik gebruik zelf een super luchtige methode gewoon omdat ik het niet erg vind even te scrollen en omdat ik het de leesbaarheid juist vind vergroten. Vaak zet ik verschillende regels code ook gewoon op lossen regels om zo een hint te geven wat bij elkaar hoort (vaak is het net niet genoeg om in een aparte methode te plaatsen, dan los ik het op deze manier op).

code:

for ( i = 0; i < 10; i++ )
{
    // code
}

while ( conditie() )
{
    functie1(
      param1,
      param2,
      param3,
      param3
    );
}

[Verwijderd]

code:

while(conditie())
    functie1(param1, param2, param3, param3);

Smaken verschillen duidelijk!

[ Voor 3% gewijzigd door Verwijderd op 06-04-2005 12:11 ]

[Woy]

Verwijderd schreef op woensdag 06 april 2005 @ 12:10:

code:

while(conditie())
    functie1(param1, param2, param3, param3);

Smaken verschillen duidelijk!

Ik vind het wel zo duidelijk en consistent om daar altijd accolades voor te gebruiken. Anders kan je al snel onduidelijke dingen krijgen zoals

C#:

if( conditie1 )
    if( conditie2 )
        DoIets();
    else
        DoIetsAnders();

[Zoijar]

rwb schreef op woensdag 06 april 2005 @ 13:12:
Ik vind het wel zo duidelijk en consistent om daar altijd accolades voor te gebruiken. Anders kan je al snel onduidelijke dingen krijgen zoals

Ja, en helemaal als je het verkeerd indent, zoals:

C++:

if( conditie1 )
    DoIets();
else
    DoIetsAnders();

// oh ik bedenk me nu dat conditie2 ook eerst waar moet zijn voor doIets(), dus maak ik er dit van:
if( conditie1 )
    if (conditie2) DoIets();
else
    DoIetsAnders();

// auw...

Heb er ooit dit over geschreven, vond ik net:

2 Repetition Conflicts

A repetition conflict occurs when LLgen cannot determine whether to choose a production inside a repetition block once more, or to continue with another production following it. A well known conflict of this type is caused by if-else statements in a language that has no symbols to denote the ends of if- and else-blocks. The conflict is usually referred to as ‘dangling-else’. For example, in the following code fragment:

if (a=0) then
if (b=0) then c:=1;
else c:=0;

we have no way of telling what if-statement the final else-statement belongs to.
The dangling-else conflict is the only repetition conflict present in our original grammar. It is caused by this grammar rule:

statement -> expression ‘then’ statement [‘else’ statement]?

Unfortunately we cannot resolve it by rewriting the grammar rule, unless we are willing to alter the language our grammar produces. However we can very easily resolve the conflict by making use of a static conflict resolver.

statement -> expression ‘then’ statement [%prefer ‘else’ statement | ε]

The %prefer resolver instructs LLgen to always choose the production following it, every time it has a choice. Also note the alternative epsilon production. This in fact means that an else-statement binds to the closest previous if-statement, and so the else-statement in our example would belong to the second if-statement.

[ Voor 58% gewijzigd door Zoijar op 06-04-2005 13:23 ]

[T-MOB]

Zoijar schreef op woensdag 06 april 2005 @ 13:18:
[...]

Ja, en helemaal als je het verkeerd indent, zoals:

C++:

if( conditie1 )
    DoIets();
else
    DoIetsAnders();

// oh ik bedenk me nu dat conditie2 ook eerst waar moet zijn voor doIets(), dus maak ik er dit van:
if( conditie1 )
    if (conditie2) DoIets();
else
    DoIetsAnders();

// auw...

Heb er ooit dit over geschreven, vond ik net:
[...]

Zoals je het nu opschrijft (2e manier) kun je dan beter

PHP:

if (conditie1 && conditie2)
  doiets();
else
  doietsanders();

Maar volgens mij was de bedoeling:

PHP:

if (conditie1)
{
  if (conditie2)
  {
    doiets();
  } else {
    doietsanders();
  }
}

Verwarring alom dus

[Tukk]

Verwijderd schreef op vrijdag 01 april 2005 @ 23:54:
In zo'n geval vind ik 't juist prettig dat de coding style afwijkt.
Als je dan een half jaar later nog 's naar die code kijkt (met alle Delphi keywords in CAPS bijvoorbeeld), dan zie je direct: "o ja, dat stukkie is niet van ons".

Als er nou iets in het commentaar hoort te staan is het wel de naam van de programmeur, niet?

[Zoijar]

T-MOB schreef op woensdag 06 april 2005 @ 13:44:
Zoals je het nu opschrijft (2e manier) kun je dan beter

Dat is iets anders

Maar volgens mij was de bedoeling:

Ja, dat staat er. Een else bind aan de dichtsbijzijnde if, meestal.

Verwarring alom dus

Precies, en daarom dus altijd accolades gebruiken

[Michali]

Zelf indent ik ook altijd in een blok. Het volgende vind ik echt oerlelijk:

code:

if(conditie)
    {
    doeIets();
    }

Dan heb ik nog liever dat de eerste accolade direct achter het if statement wordt geplaatst. Ik vind het zo niet direct duidelijk dat het blok bij het if statement hoort. Het leest gewoon niet lekker.

Het aller vervelenste vind ik nog wel als iemand geen bepaalde stijl aan houdt. Alles door elkaar en indenten waar het niet hoort etc. Als het consequent is kan ik er nog mee leven. Anders heb ik altijd de neiging om het lekker te herformateren.

[ Voor 27% gewijzigd door Michali op 06-04-2005 14:51 ]

[Verwijderd]

Hee hee ....

Server Error in '/' Application.
--------------------------------------------------------------------------------

SQL Server does not exist or access denied.
Description: An unhandled exception occurred during the execution of the current web request ...

[the_shadow]

Nog een kwestie van smaak:

Java:

if (conditie){
    [doe wat nuttigs]
}
else {
    [doe iets anders]
}

VS

Java:

if (conditie){
    [doe wat nuttigs]
} else {
    [doe iets anders]
}

Ik kan me totaal niet vinden in de tweede, leest naar mijn mening een stuk minder fijn, omdat je else niet op de plaats staat waar hij hoort te staan (direct onder de if).

[ Voor 4% gewijzigd door the_shadow op 07-04-2005 06:32 ]

[Verwijderd]

rwb schreef op woensdag 06 april 2005 @ 13:12:
Ik vind het wel zo duidelijk en consistent om daar altijd accolades voor te gebruiken. Anders kan je al snel onduidelijke dingen krijgen zoals

C#:

if( conditie1 )
    if( conditie2 )
        DoIets();
    else
        DoIetsAnders();

Dat schrijf ik dan ook zo:

C#:

if( conditie1 ){
    if( conditie2 )
        DoIets();
    else
        DoIetsAnders();
}

[Kwistnix]

Precies ik vind dat ook veel leesbaarder.
Ik heb voor m'n studie een boek moeten doorwerken over datastructuren en algorithmen, waarbij de auteur dus behoorlijke lappen code die over meerdere pagina's verspreidt waren volstopte met IF-ELSE structuren met inconsistent accolade gebruik. Zeer irritant.

[ Voor 3% gewijzigd door Kwistnix op 07-04-2005 13:24 ]

[klinz]

Jaspertje schreef op vrijdag 01 april 2005 @ 15:10:
Spaties, of tabs maakt volgens mij niet meer of minder uit dan het lettertype wat je gebruikt, want als de ene programmeur op 10px programmeert en de ander op 12px, dan komt er alsnog een verschil bij het uitlijnen

Jij werkt met een proportioneel font? Bizar :-)