[Alg] Programmeerstijl*

[Anoniem: 90904]

Waarom toch vinden sommigen het nodig om zo slordig mogelijk te coden?

Waarom:

code:

if (newvar=="blaat") {
newvar+=5;
}

i.p.v.

code:

if (NewVar == "blaat")
{
      NewVar += 5;
}

MODBREAK

---

meukee, het begint zo langzamerhand een opsomtopic te worden waarin iedereen fijn even komt posten hoe hij programmeert, en niet in gaat op argumenten van anderen.

Als deze trend zich doorzet zal ik toch geneigd zijn om 'm op slot te gooien, puur om het feit dat de topic gewoonweg geen bestaandsrecht heeft in de huidige vorm.

Discussieer dus, kom met argumenten, ga in op argumenten van anderen, maar kom niet alleen maar even je gezicht en je codestyle laten zien

Reacties die er vanaf hier niet aan voldoen zal ik de verdoemenis in helpen

---

EINDE MODBREAK

[ Voor 64% gewijzigd door .oisyn op 05-01-2004 22:00 ]

[whoami]

Omdat iedereen z'n eigen stijl heeft.

Zolang je je maar consistent aan je eigen stijl houdt, is er imo geen probleem.

[Anoniem: 90904]

Misschien moet ik wat specifieker zijn; wat is jou coding-stijl en waarom? Ik ben hier best wel benieuwd naar, aangezien ik ondertussen al vele uiteenlopende stijlen ben tegengekomen.

[Apollo_Futurae]

Edit: reactie was wat bot na de toevoeging van de TS.

Codingstyle is sterk afhankelijk van in de eerste plaats de taal die je gebruikt.
Heb je een specifieke taal/soort taal op het oog?

[ Voor 75% gewijzigd door Apollo_Futurae op 05-01-2004 20:37 ]

[gorgi_19]

Anoniem: 90904 schreef op 05 januari 2004 @ 20:35:
Misschien moet ik wat specifieker zijn; wat is jou coding-stijl en waarom? Ik ben hier best wel benieuwd naar, aangezien ik ondertussen al vele uiteenlopende stijlen ben tegengekomen.

Als reden dat er verschillende 'leerscholen' zijn, en een hoop mensen geen 'leerschool' hebben gehad en maar wat aanprutsen en dus een slecht voorbeeld hebben gehad, of het verkeerd hebben aangeleerd?

Daarnaast hoeft iets niet slordig te zijn; wat jij slordig vindt, kan een ander netjes vinden; belangrijkste is dat het consequent gebeurd.

[Anoniem: 90904]

Door whoami (Moderator P&W) - Monday 05 January 2004 20:35

Omdat iedereen z'n eigen stijl heeft.

Zolang je je maar consistent aan je eigen stijl houdt, is er imo geen probleem.

Klopt! Maar als je met meerdere mensen aan een project werkt leest het toch makkelijker als iedereen de zelfde stijl hanteert. Misschien zou er een soort standaard moeten komen ofzo

[Glimi]

Waarom zijn mensen verschillend? Mensen hebben verschillende definities van netjes. Ook jij en ik, ik vind prefixen en onnodige haakjes weg mooier

Java:

if( l_var == "value" ) 
   l_var.doSomeThing( );

is anders dan jouw voorbeeld

Maar geef eens toe, ruimde jij je kamer altijd netjes op vroeger?

Anoniem: 90904 schreef op 05 januari 2004 @ 20:38:
Klopt! Maar als je met meerdere mensen aan een project werkt leest het toch makkelijker als iedereen de zelfde stijl hanteert.

Als je met elkaar samenwerkt, dan zijn zulke afspraken toch wel te maken? Maar van een enter meer of minder is code mij nog nooit onduidelijk geworden.

Misschien zou er een soort standaard moeten komen ofzo

De meeste talen kennen style-guidelines, dus die 'standaarden' zijn er, maar worden niet opgedrongen. Gelukkig maar

[ Voor 48% gewijzigd door Glimi op 05-01-2004 20:42 ]

[Anoniem: 13874]

Anoniem: 90904 schreef op 05 januari 2004 @ 20:34:
Waarom toch vinden sommigen het nodig om zo slordig mogelijk te coden?

Waarom:

code:

if (newvar=="blaat") {
newvar+=5;
}

i.p.v.

code:

if (NewVar == "blaat")
{
      NewVar += 5;
}

toon volledige bericht

Gehehe je probeert hier meerder fouten (in jouw ogen te vangen in 1 voorbeeld). Dat is dus niet mogelijk.

In jouw ogen is het volgende voorbeeld al fout?

code:

if (expressie) {
   statement;
}

Wat nou als ik je vertel dat deze vorm op enorm veel plaatsen (zelfs als standaard) gebruikt wordt

Waarom zouden variabele perse in camelcaps notatie moeten
Er zijn veel redenen om een andere vorm te gebruiken dan dat namelijk.

Indenting wat je ook aangeeft in je voorbeeld behoort uiteraard te allen tijde te gebeuren.

[whoami]

Anoniem: 90904 schreef op 05 januari 2004 @ 20:38:
[...]


Klopt! Maar als je met meerdere mensen aan een project werkt leest het toch makkelijker als iedereen de zelfde stijl hanteert. Misschien zou er een soort standaard moeten komen ofzo

Dan doe je dat meestal in een bedrijf, en de meeste software-bedrijven hebben wel hun eigen guidelines.

Mijn stijl? Zo:

code:

if( NewVar == "blaat" )
{
    i += 5;
}
else
{
    i -= 5;
}

Er is hier ooit trouwens een topic geweest over codingstyles/guidelines, die dan in de FAQ gestopt is. Ik kan het topic nu echter niet terugvinden.

[Anoniem: 90904]

Ok. Dan ga ik wel even searchen

[-Marshal-]

Misschien moet je, je programmeer stijl vergelijken met je handschrift.

Dat je zelf iets leesbaar vind wil niet zeggen dat andere dit ook vinden. Een duidelijk netjes handschrift is handig zeker als je wilt dat andere het lezen.

Zijn er voor het programmeren geen basis/algemene beginselen?

[Anoniem: 73385]

Ik vind het persoonlijker netter en duidelijker als je de argumenten direct tussen ()-jes zet, dus:

(1, 10, "Hallo")
ipv
( 1,10,"Hallo" )

[Anoniem: 101766]

Mijn 'stijl' zou ik beschrijven als:

code:

int ReturnToMain(char s, int x);

int main()
{
 int x;

 for ( x = 1 ; x != 13 ; x-- )
 {
   ReturnToMain ('a', 13);
   exit (0);
 }

 exit (1);

}

Net zoals jouw tweede voorbeeld spaties tussen dingen als operators. Hoeft niet, maar vind ik mooier staan.
Verder ook een verschil tussen een functie aanroepen, en definiëren. (let op de spatie voor de haakjes)

[Anoniem: 86363]

Ik ben het zelf wel grotendeels 'eens' met deze pagina: C# Coding Style Guide. Wel gebruik ik altijd tabs, wat ze daar niet doen:

code:

if (condition) {
    DoSomething();
}

Maargoed, zoals gezegd; het is nogal persoonlijk. Overigens, in [rml][ Alg] Nieuwe FAQ Naamgeving / Indenteringen[/rml] is het eea ook al langsgekomen, misschien interressant.

[ Voor 24% gewijzigd door Anoniem: 86363 op 05-01-2004 20:51 ]

[Glimi]

Niemand gebruikt scopeprefixes?

[whoami]

Glimi schreef op 05 januari 2004 @ 20:47:
Niemand gebruikt scopeprefixes?

Private members hebben bij mij een _ prefix.

[gorgi_19]

whoami schreef op 05 januari 2004 @ 20:48:
Private members hebben bij mij een _ prefix.

Jups, en hoewel het niet schijnt te mogen, wil ik ook nog wel eens __ gebruiken voor declarations binnen een method.

[Anoniem: 90904]

Ik vind zelf het aangeven van het soort var ook wel handig trouwens: iMyInt

Ik vond het verder ook wel interessant om te lezen dat sommige talen (Ruby) de programmeur dwingen om een bepaalde stijl aan te houden (vanwege het weglaten v/d ';' )

En ik denk dat een standaard van programmeren toch wel erg relaxed zal zijn bij het moeten ontcijferen van andermans code. Je zou dan natuurlijk kunnen denken aan een standaard per taal. Zeg maar net een beetje als bij de XML-standaard...

[Anoniem: 13874]

Glimi schreef op 05 januari 2004 @ 20:47:
Niemand gebruikt scopeprefixes?

Anoniem: 13874 schreef op 05 januari 2004 @ 20:40:
Waarom zouden variabele perse in camelcaps notatie moeten
Er zijn veel redenen om een andere vorm te gebruiken dan dat namelijk.

[Anoniem: 67941]

Programmeer style is heel vervelend. Nouja, vervelden... als je met meerderen aan een project werkt is het vaak lastig. Maar daarom worden er ook vaak regels voor gehanteerd. Gelukkig zijn deze in mijn omgeving bijna altijd hetzelfde, maar het is elke keer even wennen! Maar als je het dat weer gewend bent is het juist weer makkelijker omdat je allemaal dezelfde style heb.

Prefixen doe ik iig nooit aan, die zie ik in me omgeving ook niet echt. Alleen voor controlles worden deze in mijn omgeving gebruikt.

[Anoniem: 13874]

Anoniem: 90904 schreef op 05 januari 2004 @ 20:51:
En ik denk dat een standaard van programmeren toch wel erg relaxed zal zijn bij het moeten ontcijferen van andermans code. Je zou dan natuurlijk kunnen denken aan een standaard per taal. Zeg maar net een beetje als bij de XML-standaard...

Die zijn er ook altijd wel hoor

Alleen niet iedereen krijgt alles hetzelfde aangeleerd. Vergelijk het maar gewoon met handschriften. De een schrijft de letter "t" bijvoorbeeld heel anders dan de andere.

Bij gezamelijk projecten en binnen bedrijven, worden normaliter afspraken over de programmeer stijl gemaakt. Vaak zijn die erg vergaand. Daarentegen lijken ze meestal zeer sterk op de stijl die over het algemeen voor de betreffende taal gebruikt worden. Verder zijn veel van die regels voor een wat meer ervaren programmeur ook vanzelfsprekend.

[Schmoove]

Anoniem: 90904 schreef op 05 januari 2004 @ 20:38:
[...]


Klopt! Maar als je met meerdere mensen aan een project werkt leest het toch makkelijker als iedereen de zelfde stijl hanteert. Misschien zou er een soort standaard moeten komen ofzo

Die is er ook. De Hongaarse notatie bijvoorbeeld is een veel gebruikte coding convention. Het maakt eigenlijk niet zoveel uit hoe je het doet, zoals gezegd, als je het maar consequent doet.

Zelf code ik altijd op deze manier:

code:

if(x==4)
{
  for(int i=0; i<20; i++)
  {
    //do something
  }
}
else
{
  int intTest = 1;

  //do something else
  //etc.
}

Vind dit zelf prettig leesbaar, maar er zijn er genoeg die daar anders over denken.

[gorgi_19]

De Hongaarse notatie bijvoorbeeld is een veel gebruikte coding convention

Klopt, maar niet universeel; voor .Net wordt hij bijvoorbeeld afgeraden om te gebruiken als standard

[.oisyn]

Glimi schreef op 05 januari 2004 @ 20:47:
Niemand gebruikt scopeprefixes?

alleen voor parameters eigenlijk. Als ik een reguliere C++ app van me neem dan zijn de meeste variabelen lokaal of members. Members een scope prefix geven vind ik nogal lelijk, zeker als ze public zijn (of ze überhaupt public horen te zijn is een andere discussie en daar wil ik nu niet op ingaan ). Locals geef ik soms een l prefix, maar alleen als het te verwarrend wordt (door bijv. gelijknamige variabelen voor de local scope en de this scope).

Globale variabelen zonder namespace of class prefix gebruik ik zelden, dus die krijgen er ook geen.

[Glimi]

gorgi_19 schreef op 05 januari 2004 @ 20:50:
Jups, en hoewel het niet schijnt te mogen, wil ik ook nog wel eens __ gebruiken voor declarations binnen een method.

AFAIK is __ alleen binnen C++ gereserveerd voor speciale compiler values.

Anoniem: 13874 schreef op 05 januari 2004 @ 20:51:

Kun je het verband aan me uitleggen, want die zie ik zo 1-2-3 niet helemaal

[.oisyn]

gorgi_19 schreef op 05 januari 2004 @ 20:50:
[...]

Jups, en hoewel het niet schijnt te mogen, wil ik ook nog wel eens __ gebruiken voor declarations binnen een method.

hoe bedoel je, "schijnen niet te mogen"?
Ik weet wel dat in C/C++ identifiers in de vorm van _[A-Z_][A-Za-z0-9_]* gereserveerd zijn voor de compiler en stdlib bouwers

[Juup]

Dit vind ik het mooist:

code:

if (varName == 3)
{
  SomeFunction();
}

[ Voor 3% gewijzigd door Juup op 05-01-2004 21:03 ]

[drm]

Het topic dat whoami bedoelde

[gorgi_19]

.oisyn schreef op 05 januari 2004 @ 21:02:
[...]


hoe bedoel je, "schijnen niet te mogen"?
Ik weet wel dat in C/C++ identifiers in de vorm van _[A-Z_][A-Za-z0-9_]* gereserveerd zijn voor de compiler en stdlib bouwers

Ik kreeg van een niet nader te noemen mod een keer een berichtje waarin stond:

Die dubbele underscores zijn echt ranzig hoor.

offtopic:
Ze gaan trouwens ook uit C++.NET verdwijnen.

Vandaar: schijnt. Ik heb me verder er ook nog niet in verdiept.

[Anoniem: 13874]

Glimi schreef op 05 januari 2004 @ 21:00:
Kun je het verband aan me uitleggen, want die zie ik zo 1-2-3 niet helemaal

Was ook niet helemaal duidelijk

Ik wilde met dat stukje tekst duidelijk maken dat notatie helemaal niet perse op de manier van TS zou moeten gebeuren en dat er legio andere notatie manieren mogelijk waren.

Toen jij begin over scope prefixes wilde ik die uitleg betrekken op mijn eigen manier van programmeren

_{Duidelijk is anders ja}

[BCC]

whoami schreef op 05 januari 2004 @ 20:35:
Omdat iedereen z'n eigen stijl heeft.

Zolang je je maar consistent aan je eigen stijl houdt, is er imo geen probleem.

Hiervoor is toch codereviewen uitgevonden? Dit doe ik met mijn projectgroep ALTIJD. En het scheelt een boel ellende

[curry684]

drm schreef op 05 januari 2004 @ 21:03:
Het topic dat whoami bedoelde

Volgens mij doelde hij op deze: [rml][ Alg] Nieuwe FAQ Naamgeving / Indenteringen[/rml]/

Een topic dat een niet nader te specificeren mod nog steeds eens uit moet werken tot een definitief stukje voor in de FAQ

[Fatamorgana]

Juup schreef op 05 januari 2004 @ 21:02:
Dit vind ik het mooist:

code:

if (varName == 3)
{
  SomeFunction();
}

En ik dit weer (compleet met else):

code:

if(varName == 3){
  SomeFunction();
}else{
  OtherFunction();
}

Dan passen er meer regels op je scherm.

[ Voor 8% gewijzigd door Fatamorgana op 05-01-2004 21:13 ]

[Infinitive]

Glimi schreef op 05 januari 2004 @ 20:47:
Niemand gebruikt scopeprefixes?

Kom nou, das veel te veel werk. Daarvoor moet je én de shift toets en het '-' tekentje tegelijk indrukken en zien te vinden.

Ik vind zelf prefixes niet zo mooi staan. Persoonlijke smaak. En ik heb eigenlijk nog nooit echt gemist dat ik aan de variablenaam kan zien wat de scope en het type is. Dat zou ook wel eens kunnen komen doordat ik vaak met dezelfde personen samenwerk en eigenlijk nooit echt code hoef aan te passen dat nooit door iemand die ik ken is geschreven.

Dan passen er meer regels op je scherm.

Persoonlijk heb ik liever meer tussenruimte dan veel regels op het scherm. Veel witruimte lees lekkerder en verlies je minder snel het overzicht.

Nu zijn er vaak ook dingen die je zonder echt nadenken doet. Zo kwam ik er pas achter dat ik altijd achter een if een spatie zet, maar nooit direct achter een while of for...

[ Voor 25% gewijzigd door Infinitive op 05-01-2004 21:16 ]

[BCC]

Fatamorgana schreef op 05 januari 2004 @ 21:12:
[...]


En ik dit weer:

code:

if(varName == 3){
  SomeFunction();
}

Dan passen er meer regels op je scherm.

Dat vind ik dus echt ranzig Koop dan een groter scherm.. of werk met regions.

Voor zo'n klein ifje zou ik trouwens dit doen:

code:

if(varName == 3)
  SomeFunction();
else
  OtherFunction();

[ Voor 36% gewijzigd door BCC op 05-01-2004 21:17 ]

[Fatamorgana]

BCC schreef op 05 januari 2004 @ 21:13:
[...]
Dat vind ik dus echt ranzig Koop dan een groter scherm.. of werk met regions.

En ik vind een ander manier juist weer ranzig. Het is dus vaak erg persoonlijk.

Bij mijn opleiding was het eerste wat de leraar zei: Programmeurs zijn lui, dus zo weinig mogelijk typen op zo min mogelijk regels en het toch goed leesbaar houden. Nu ben ik daar dus aan gewend en vind ik de manier die ik gebruik voor mezelf het beste leesbaar.

[gorgi_19]

Bij mijn opleiding was het eerste wat de leraar zei: Programmeurs zijn lui, dus zo weinig mogelijk typen op zo min mogelijk regels en het toch goed leesbaar houden. Nu ben ik daar dus aan gewend en vind ik de manier die ik gebruik voor mezelf het beste leesbaar.

Grappig.. Wat ik heb gelezen is om zo veel mogelijk code te hergebruiken en zo weinig mogelijk stukken code te c/p'en. Een iets andere invalshoek.

[Sybr_E-N]

BCC schreef op 05 januari 2004 @ 21:10:
[...]

Hiervoor is toch codereviewen uitgevonden?

Ik heb voor mijn stage zelf Code Conventies aan het begin vast gelegd (Assembly voor een microcontroller red.), en daar kun je je altijd aan houden.

[BCC]

Fatamorgana schreef op 05 januari 2004 @ 21:16:
[...]

En ik vind een ander manier juist weer ranzig. Het is dus vaak erg persoonlijk.

Bij mijn opleiding was het eerste wat de leraar zei: Programmeurs zijn lui, dus zo weinig mogelijk typen op zo min mogelijk regels en het toch goed leesbaar houden. Nu ben ik daar dus aan gewend en vind ik de manier die ik gebruik voor mezelf het beste leesbaar.

Heb je dan wel eens aan grote projecten gewerkt met meerdere programmeurs? Mijn huidige project heeft bijna net zoveel commentaar en intellidoc regels als code (gelukkig!). Dit is echt noodzakelijk om te unittesten, code reviewen en integration testen. En zeker als er een programmeur wegvalt!

[Anoniem: 13874]

BCC schreef op 05 januari 2004 @ 21:13:
[...]


Dat vind ik dus echt ranzig Koop dan een groter scherm.. of werk met regions.

Voor zo'n klein ifje zou ik trouwens dit doen:

code:

if(varName == 3)
  SomeFunction();
else
  OtherFunction();

Gehehe en dat vind ik dus weer ranzig. Ben gewoon consequent in het gebruik van accolades, denk ik dan. Dus ook als het maar om 1 statement gaat i.p.v. meerdere statement als aan de conditie voldaan wordt. Maar goed dat is echt een persoonlijk iets, aangezien je het dagelijks tegenkomt op de manier zoals jij het doet

TS: Zoals je ziet heeft iedereen veel overeenkomsten maar zijn er toch ook legio verschillen

[ Voor 12% gewijzigd door Anoniem: 13874 op 05-01-2004 21:23 ]

[krvabo]

ff stukje mIRC hoor
dit vind ik het lekkerst, lijkt slordig maarja,

code:

on ^*:text:*:#: {
 if ($nick == $me) {
  echo -t  dat ben ikke :o
  haltdef
  }
 else {
  echo -t  dat ben ikke niet :o
  haltdef
  }
}

ziet er raar uit, maar ik vind het makkelijk werken, voornamelijk is dat ook omdat ik _altijd_ met scripting-progjes werk die allemaal auto-tab hebben, en aangeven wanneer er een } of { niet goed staan, groot voordeel voor me

[Tux]

PHP:

if ($melp == "spef")
{
    doe_iets ($param, $param2, $param3);
}
elseif ($waa == "meukee")
{
    doe_iets_anders ($param, $param2, $param3);
}
else
{
    print ("Wegwezen jij!\n");
}

zoiets ofzo

[Wolfboy]

ik doe het meestal zo

code:

if(varName==5)
{
     function()
} else {
     function2()
}

[curry684]

gorgi_19 schreef op 05 januari 2004 @ 21:18:
[...]

Grappig.. Wat ik heb gelezen is om zo veel mogelijk code te hergebruiken en zo weinig mogelijk stukken code te c/p'en. Een iets andere invalshoek.

1-0

[Fatamorgana]

BCC schreef op 05 januari 2004 @ 21:20:
Heb je dan wel eens aan grote projecten gewerkt met meerdere programmeurs? Huidige project heeft bijna netzoveel commentaar en intellidoc regels als code (gelukkig!). Dit is echt noodzakelijk unittesten, code reviewen integration testen. En zeker als er een programmeur wegvalt!

Yep, wel eens aan gewerkt, werkte tot nu toe goed.

Wat ik het belangrijkste vind is dat men het indenten goed gebruikt, dan kom je al heel erg ver en goed nadenken over de classes en functions, deze waar mogelijk zo klein mogelijk houden.

[Anoniem: 13874]

Wolfboy schreef op 05 januari 2004 @ 21:26:
ik doe het meestal zo

code:

if(varName==5)
{
     function()
} else {
     function2()
}

En dat is dus wazig in mijn ogen, mag jij zeggen waarom

[.oisyn]

krvabo schreef op 05 januari 2004 @ 21:21:
ff stukje mIRC hoor
dit vind ik het lekkerst, lijkt slordig maarja,

code:

on ^*:text:*:#: {
 if ($nick == $me) {
  echo -t  dat ben ikke :o
  haltdef
  }
 else {
  echo -t  dat ben ikke niet :o
  haltdef
  }
}

ziet er raar uit, maar ik vind het makkelijk werken, voornamelijk is dat ook omdat ik _altijd_ met scripting-progjes werk die allemaal auto-tab hebben, en aangeven wanneer er een } of { niet goed staan, groot voordeel voor me

toon volledige bericht

mirc is evil om de pure reden dat het je script keihard niet snapt als je de accolade-openen op de volgende regel zet (ik snap wel waarom het zo is gedaan, maar ik snap ook dat dat gewoon totaal niet zo zou hoeven zijn)

Nou ben ik sowieso tegen talen waarbij de formatting van belang is voor de interpretatie van je code, zoals bijvoorbeeld Haskell en makefile. Maar goed, dat is een hele andere discussie wat veel te offtopic is

[ Voor 13% gewijzigd door .oisyn op 05-01-2004 21:30 ]

[BCC]

Fatamorgana schreef op 05 januari 2004 @ 21:27:
[...]


Yep, wel eens aan gewerkt, werkte tot nu toe goed.

Dan heb je tot nu toe erg mazzel gehad ... of weinig stabiele code opgeleverd... of code opgeleverd die niemand meer terug wil lezen waardoor er bij een aanpassing beter opnieuw gecode kan worden dan de oude code proberen te ontcijferen.

[Wolfboy]

tja zo doe ik het gewoon al een tijdje, misschien dat ik nog wel een keer van stijl ga veranderen hoor, ik moet zeggen dat dit:

code:

if(varName == 5)
{
      function()
}
else
{
      function2()
}

ook wel netjes is, maar dat neemt weer zoveel ruimte in

[mr._Anderson]

Het is lastig om er consistent in te blijven, en zeker met een groep mensen. Daarom worden bij projecten, of in bedrijven algemeen altijd afspraken gemaakt waar de programmeurs zich aan moeten houden. Dit geld ook voor commentaar, hoeveelheden, en plek van commentaar.

Documentatie maakt een groot deel van je codeer werk uit, allemaal om het maar leesbaar te houden

[Fatamorgana]

gorgi_19 schreef op 05 januari 2004 @ 21:18:
Grappig.. Wat ik heb gelezen is om zo veel mogelijk code te hergebruiken en zo weinig mogelijk stukken code te c/p'en. Een iets andere invalshoek.

Natuurlijk hergebruik ik ook veel, ik schrijf alles alleen zo kort mogelijk op en houd het goed leesbaar.

[ATS]

Ik doe het eigenlijk altijd zo:

code:

if (blaat) foo();
if (bar) {
  foo();
} else {
  blaat=true;
}

Ofwel: alleen geen accolades als het op dezelfde regel staat (dus alleen bij korte statements), in gevallen met meer dan één statement in een if of een else gebruik ik altijd accolades.

Verder beginnen membervariables met een kleine letter en hebben verder camelcasing. Memberfunctienamen beginnen met een hoofdletter en zijn ook camel-cased. Macro's bestaan uit ALL_CAPS en klasse-interne variabelen beginnen met een _underscore. Geen prefixen van het type, daar kan je niet aan beginnen als je zelf vele klasses gebruikt.

Tenminste, zo doe ik het (in theorie) in C++. In VB gebruik ik wél de Hungarian stijl.

[OnTracK]

ongeveer Wolfboy's stijl, alleen een paar accolades op een andere plek zodat het wat leesbaarder is (mijn mening). verder altijd tabs voor gelijke uitlijning[norml]
[/]

code:

if (NewVar == 8)
{    NewVar += 5;
     Function2();
} else
{    NewVar ++;
}

offtopic:
waarom moet ik nou weer [norml] gebruiken om een extra return tussen mijn tekst en code te krijgen

ohja, en nog wat: hoe wou jij 5 bij "blaat" optellen, als het nou "5" was (hence the quotes), meestal krijg je toch NaN (Not a Number) of iets in die trand

[ Voor 40% gewijzigd door OnTracK op 05-01-2004 21:44 ]

[Anoniem: 13874]

mr._Anderson schreef op 05 januari 2004 @ 21:31:
Het is lastig om er consistent in te blijven, en zeker met een groep mensen.

Dat laatste ben ik volledig met je eens. Daar geef je ook meteen de oplossing voor, zoals al meermaals genoemd in deze topic.

Dat eerste deel is wel erg vreemd. Je zegt daar dus doodleuk dat je als programmeur zijnde zelf ook niet consistent bezig bent
Volgens mij is het basisbeginsel van zo foutloos mogelijk proberen te programmeren juist consistentie. Sterker nog ik snap niet hoe je zelf inconsestent bezig kunt zijn in binnen een en hetzelfde project. Dan ben je i.m.o. of stom bezig, of je bent pas net begonnen met programmeren.

[Spider.007]

Hmm; aangezien mijn stijl () nog niet voorbij is gekomen hier een voorbeeldje:

code:

if (varName == 3) someFunction();
else otherFunction();

Weg met overbodige regels! dat kost alleen maar kostbare bytes in je programmeercode

[.oisyn]

Weg met overbodige regels! dat kost alleen maar kostbare bytes in je programmeercode

dat is de meest onzinnige stelling die ik ooit heb gezien

[Glimi]

OnTracK schreef op 05 januari 2004 @ 21:36:
ohja, en nog wat: hoe wou jij 5 bij "blaat" optellen, als het nou "5" was (hence the quotes), meestal krijg je toch NaN (Not a Number) of iets in die trand

offtopic:
In PHP zeg maar....

[whoami]

Fatamorgana schreef op 05 januari 2004 @ 21:31:
[...]

Natuurlijk hergebruik ik ook veel, ik schrijf alles alleen zo kort mogelijk op en houd het goed leesbaar.

Tja, maar wat win je er dan mee? Als je die code 2 maanden later gaat gaan herbekijken, ben je een hele hoop tijd kwijt met uitvogelen wat die code nu weer precies deed, of waarom het zo geschreven was.

Het is belangrijk dat je goeie, duidelijke namen gebruikt voor je variabelen en functies.
Het lui zijn van een programmeur, gaat dan ook over iets anders:
- werk in de toekomst vermijden; schrijf je code zodanig dat je bepaalde code kunt hergebruiken, zorg dat je veranderingen makkelijk kunt opvangen, etc.... Lui zijn heeft niets te maken met zo weinig mogelijk willen typen enzo.
(Met de IntelliSense enzo van tegenwoordig hoef je trouwens al niet meer zoveel te typen als vroeger).

[gorgi_19]

Spider.007 schreef op 05 januari 2004 @ 21:41:
Weg met overbodige regels! dat kost alleen maar kostbare bytes in je programmeercode

Jij sloopt zeker ook al je comments uit je code?

[Anoniem: 13874]

Wolfboy schreef op 05 januari 2004 @ 21:31:
tja zo doe ik het gewoon al een tijdje, misschien dat ik nog wel een keer van stijl ga veranderen hoor, ik moet zeggen dat dit:
ook wel netjes is, maar dat neemt weer zoveel ruimte in

Zal ik het antwoord dan maar geven waarom ik de stijl in jouw voorbeeld wazig vind?

Achter de conditie van het if statement zet je geen accolade. Die zet je op de volgende regel. Daarentegen zet je bij de andere conditie (de else in dit geval), wel meteen een accolade erachter. Doe het dan op 1 van je 2 manieren, maar ga ze niet mixen:

code:

if (conditie) {
   foo;
} else {
   bar;
}

if (conditie)
{
   foo;
}
else
{
   bar;
}

OnTracK schreef op 05 januari 2004 @ 21:36:
ongeveer Wolfboy's stijl (en wel van meer mensen), alleen een paar returns gescrapt zodat het minder ruimte inneemt. verder altijd tabs voor gelijke uitlijning[norml]
[/]

code:

if (NewVar == "blaat")
{    NewVar += 5;
     Function2();
} else
{    NewVar ++;
}

offtopic:
waarom moet ik nou weer [norml] gebruiken om een extra return tussen mijn tekst en code te krijgen

En dat vind ik dus echt redelijk ranzig als ik eerlijk ben.

Dat is toch nooit overzichtelijk te noemen of wel?
Programmeer je wel eens in groeps/team verband?

gorgi_19 schreef op 05 januari 2004 @ 21:45:
[...]

Jij sloopt zeker ook al je comments uit je code?

LOL

* Anoniem: 13874 verwacht nu als antwoord: "Welke comments "

[ Voor 10% gewijzigd door Anoniem: 13874 op 05-01-2004 21:52 ]

[gorgi_19]

whoami schreef op 05 januari 2004 @ 21:45:
Het is belangrijk dat je goeie, duidelijke namen gebruikt voor je variabelen en functies.
Het lui zijn van een programmeur, gaat dan ook over iets anders:
- werk in de toekomst vermijden; schrijf je code zodanig dat je bepaalde code kunt hergebruiken, zorg dat je veranderingen makkelijk kunt opvangen, etc.... Lui zijn heeft niets te maken met zo weinig mogelijk willen typen enzo.

Dit ben ik niet helemaal met je eens; tot op zekere hoogte moet je dit idd vasthouden. Echter, flexibiliteit heeft z'n grenzen, imho.

Om een quote van geloof ik Einstein te misbruiken:

Keep things as simple as possible. Not any simpler

[BCC]

Spider.007 schreef op 05 januari 2004 @ 21:41:
Hmm; aangezien mijn stijl () nog niet voorbij is gekomen hier een voorbeeldje:

code:

if (varName == 3) someFunction();
else otherFunction();

Weg met overbodige regels! dat kost alleen maar kostbare bytes in je programmeercode

Haha.. zeker nooit van Assembly en Bytecode gehoord wel ?
Lang leve vertalerbouw

[ Voor 5% gewijzigd door BCC op 05-01-2004 21:48 ]

[Sybr_E-N]

Grappig iedereen heeft het net ietjes anders Ik gebruik geen accolades wanneer er maar 1 statement volgt.

code:

if (i < 7) {
  varName = smallVar.substr(3, 2);
  i++;
} else
  varName = StartNext(varName, i);

[Creepy]

Glimi schreef op 05 januari 2004 @ 21:44:
[...]

offtopic:
In PHP zeg maar....

Raad de uitkomst van

PHP:

echo "30 appels" * 40

Ik zet zelf elke begin of eind van een block op een eigen regel

code:

if (iets == 30) then
{
  // blaat
  // meer blaat
}

dat idee dus..

ook laat ik een lege regel vallen VOOR elke if

code:

eenFunctie();
nogMeerOnzin();

if (iets) then
  doeIets();

en geen extra zooi als er maar 1 statement staat in een if..

[/slechte_verhul_actie_voor_een_stukje_php]

Het blijft naar mijn idee persoonlijk wat het meest leesbaar is. Ik ontwikkel redelijk wat in Delphi, en hierbij probeer ik zoveel mogelijk de Borland stijl aan te houden.

[ Voor 14% gewijzigd door Creepy op 05-01-2004 21:50 ]

[whoami]

gorgi_19 schreef op 05 januari 2004 @ 21:47:
[...]

Dit ben ik niet helemaal met je eens; tot op zekere hoogte moet je dit idd vasthouden. Echter, flexibiliteit heeft z'n grenzen, imho.

Om een quote van geloof ik Einstein te misbruiken:

[...]

Dat ben ik idd met je eens. Ik heb ook niet gezegd dat je met alle mogelijke toekomstige veranderingen enzo moet gaan rekening houden, want dat is helemaal niet werkbaar, en zal er alleen maar toe leiden dat het project doodbloed (want het komt niet uit de analyse fase) == paralysis by analysis.

Ik bedoel maar, door bepaalde principes toe te passen, kan je al een redelijk flexibel design hebben.

[RayNbow]

Dan zal ik ook maar 'ns m'n coding style posten

Java:

if (expression1 == expression2) {
    statement1;
    statementN;
}
else {
    statementX;
    statementY;
}

Visual Basic:

' Ik kon het niet laten om wat VB code te typen :P
If Expression1 = Expression2 Then
    Statement1
    Statement2
Else
    Statement3
    Statement4
End If

De stijl die ik in Java gebruik heb ik waarschijnlijk overgenomen van wat (C/C++) boeken die ik ooit gelezen heb.

[BCC]

Kunnen er niet wat echte voorbeelden komen ipv al die onduidelijke foo-bar dingen?

[ Voor 85% gewijzigd door BCC op 05-01-2004 22:07 ]

[Spider.007]

haha... hap hap hap allemaal. Ik las deze quote:

Weg met overbodige regels! dat kost alleen maar kostbare bytes in je programmeercode

in een blad van 25 jaar geleden; toen elke byte je programma twee keer zo lang liet duren. Ik wilde hem jullie niet onthouden en dit was de perfect context

[whoami]

Sybr_E-N schreef op 05 januari 2004 @ 21:48:
Grappig iedereen heeft het net ietjes anders Ik gebruik geen accolades wanneer er maar 1 statement volgt.

code:

if (i < 7) {
  varName = smallVar.substr(3, 2);
  i++;
} else
  varName = StartNext(varName, i);

Tja, ik ben van mening dat je best altijd haakjes gebruikt. Zo blijf je consistent, en als je else - tak plots 2 of meer regels moet bevatten ipv die ene regel, dan heb je ook minder kans op bugs. (Stel nl. dat je toch maar eens vergeet om die haakjes er dan rond te zetten.
Geen haakjes zetten kan ook verwarrend zijn:

code:

if( i < 7 )
{
     varname = "blaat";
     i++;
}
else
    if( i == 10 )
        DoSomething();
     DoSomething2();

[whoami]

Spider.007 schreef op 05 januari 2004 @ 21:52:
haha... hap hap hap allemaal. Ik las deze quote:
[...]
in een blad van 25 jaar geleden; toen elke byte je programma twee keer zo lang liet duren. Ik wilde hem jullie niet onthouden en dit was de perfect context

Haakjes , commentaar, whitespace, etc..... hebben helemaal geen invloed op het aantal bytes dat je executable groot wordt.
Het gaat 'm om 'compiled' codelijnen.

[Creepy]

whoami schreef op 05 januari 2004 @ 21:52:
[...]


Tja, ik ben van mening dat je best altijd haakjes gebruikt. Zo blijf je consistent, en als je else - tak plots 2 of meer regels moet bevatten ipv die ene regel, dan heb je ook minder kans op bugs. (Stel nl. dat je toch maar eens vergeet om die haakjes er dan rond te zetten.
Geen haakjes zetten kan ook verwarrend zijn:

Een kwestie van op de juiste manier blijven inspringen lijkt me (daar is "consistentie" weer )

code:

if( i < 7 )
{
     varname = "blaat";
     i++;
}
else
    if( i == 10 )
        DoSomething();
DoSomething2();

[.oisyn]

MODBREAK

---

meukee, het begint zo langzamerhand een opsomtopic te worden waarin iedereen fijn even komt posten hoe hij programmeert, en niet in gaat op argumenten van anderen.

Als deze trend zich doorzet zal ik toch geneigd zijn om 'm op slot te gooien, puur om het feit dat de topic gewoonweg geen bestaandsrecht heeft in de huidige vorm.

Discussieer dus, kom met argumenten, ga in op argumenten van anderen, maar kom niet alleen maar even je gezicht en je codestyle laten zien

Reacties die hier vanaf nu niet aan voldoen zal ik de verdoemenis in helpen

---

EINDE MODBREAK

[whoami]

Creepy schreef op 05 januari 2004 @ 21:54:
[...]

Een kwestie van op de juiste manier blijven inspringen lijkt me (daar is "consistentie" weer )

code:

if( i < 7 )
{
     varname = "blaat";
     i++;
}
else
    if( i == 10 )
        DoSomething();
DoSomething2();

Inderdaad, inspringen is ook heel belangrijk, maar het moet maar eens niet gebeuren om heel verwarrende code te verkrijgen.

[Anoniem: 13874]

whoami schreef op 05 januari 2004 @ 21:52:
[...]

Daar geef je dus precies weer wat mijn afkeer tegen het niet gebruiken van accolades is.

Creepy schreef op 05 januari 2004 @ 21:54:
[...]

Een kwestie van op de juiste manier blijven inspringen lijkt me (daar is "consistentie" weer )

code:

if( i < 7 )
{
     varname = "blaat";
     i++;
}
else
    if( i == 10 )
        DoSomething();
DoSomething2();

True, maar toch is een accolade i.m.o. duidelijker dan alleen het inspringen.
Om nog maar niet te spreken over het feit dat je ze alsnog moet gaan plaatsen als je meerdere statements wilt gaan gebruiken als aan de conditie voldaan wordt.

[ Voor 14% gewijzigd door Anoniem: 13874 op 05-01-2004 22:00 ]

[SWINX]

valt verder weinig over te discussieren nog denk ik, iedereen heeft al gezegd dattie op zijn eigen manier codert (of prutst ) ....

[gorgi_19]

@whoami

En hier krijg je weer een stukje meningsverschil over wat netjes is..
Ik zou met die code heel snel de draad kwijt zijn, ondanks het inspringen, waar ik eigenlijk ben gebleven. In dat opzicht vind ik de VB syntax een stuk duidelijker, waarin aangegeven wordt wanneer iets eindigt

Visual Basic .NET:

If  i < 7 Then

     varname = "blaat";
     i = i + 1

Else

    If i = 10 Then

        DoSomething()

    End if

    DoSomething2()

End if

Sterker nog, je MAG het afaik niet eens doen zonder end if-statements zonder op een volgende regel te gaan

Visual Basic .NET:

If a = 1 then doactie()

mag dan weer wel, als enige uitzondering.

[ Voor 19% gewijzigd door gorgi_19 op 05-01-2004 22:02 ]

[BCC]

SWINX schreef op 05 januari 2004 @ 21:59:
valt verder weinig over te discussieren nog denk ik, iedereen heeft al gezegd dattie op zijn eigen manier codert (of prutst ) ....

Juist..en dat de meeste prutsers niet tot inkeer te brengen zijn

[Anoniem: 13874]

gorgi_19 schreef op 05 januari 2004 @ 22:00:
@whoami

En hier krijg je weer een stukje meningsverschil over wat netjes is..
Ik zou met die code heel snel de draad kwijt zijn, ondanks het inspringen, waar ik eigenlijk ben gebleven. In dat opzicht vind ik de VB syntax een stuk duidelijker, waarin aangegeven wordt wanneer iets eindigt

Euhm, heb ik het nou mis of gaf whoami nou juist een voorbeeld van wat hij niet netjes vindt?

Hij zegt juist dat er wel accolades gebruikt moeten worden. Dat maakt verder ook geen verschil met het VB voorbeeld dat je geeft. Enige verschil is dat je daar dus ziet wat er precies afgesloten wordt.
Als een taal dat echter niet ondersteunt en het gaat om grote code blokken dan is het gebruik van commentaar bij het afsluiten van zo'n blok een goed alternatief

[whoami]

gorgi_19 schreef op 05 januari 2004 @ 22:00:
@whoami

En hier krijg je weer een stukje meningsverschil over wat netjes is..

Dat wou ik net aantonen.

Ik zou met die code heel snel de draad kwijt zijn, ondanks het inspringen, waar ik eigenlijk ben gebleven. In dat opzicht vind ik de VB syntax een stuk duidelijker, waarin aangegeven wordt wanneer iets eindigt

Inderdaad, dus dat was een argument van mij om altijd { } te gebruiken ( in C - syntax talen dus).
In VB.NET ben je dus blijkbaar verplicht om altijd aan te geven waar je block eindigt. _{VB.NET heeft dan toch nog een goed punt.}

Zelf geef ik in C# (en ook in andere talen) altijd aan waar m'n blocks beginnen/eindigen. Ik gebruik dus ook altijd die haakjes (icm een consistente indentatie).

Visual Basic .NET:

If a = 1 then doactie()

mag dan weer wel, als enige uitzondering.

Dat doe ik dus [meestal] niet.

[BCC]

whoami schreef op 05 januari 2004 @ 22:05:
[...]

Dat doe ik dus [meestal] niet.

Waarom zit die inconsequentie eigenlijk in VB6? Is dat nog vanwege de (Q)Basic backwards compatibiliteit?

[gorgi_19]

whoami schreef op 05 januari 2004 @ 22:05:
Dat doe ik dus [meestal] niet.

Ik ook bijna nooit. Er is maar 1 uitzondering waarbij ik het gebruik.

Visual Basic .NET:

    Private Function GetInfluenceOnEmptynessByPrice() As Double

        Dim __rent As Double = Me.CurrentRentAsPercentOfMaximumReasonableRent
        If IsBetween(__rent, Double.MinValue, 0.1) Then Return 10
        If IsBetween(__rent, 1.8, Double.MaxValue) Then Return 1
        If IsBetween(__rent, 0.1, 0.2) Then Return -25 * __rent + 26
        If IsBetween(__rent, 0.2, 0.4) Then Return (-40 / 3) * __rent + 7
        If IsBetween(__rent, 0.5, 1.8) Then Return -30 * __rent + 55

    End Function

In dit soort statements vind ik het veel duidelijker om het op 1 regel te houden dan om een eindeloze if-else-end if statements te gaan bouwen.

Heb ik een vaste leidraad ervoor? Neuh, dat niet; meer een kwestie van 'gevoel', om het maar heel vaag uit te drukken..

[ Voor 17% gewijzigd door gorgi_19 op 05-01-2004 22:12 ]

[Wolfboy]

hmm wie heeft er zin om na al dit geblaat een mooie samenvatting te maken?

ik ga mijn stijl denk ik toch maar ietsje veranderen

bedankt voor opmerking nelske, ik ga erop letten

[ Voor 3% gewijzigd door Wolfboy op 05-01-2004 22:18 ]

[Anoniem: 13874]

Wolfboy schreef op 05 januari 2004 @ 22:18:
hmm wie heeft er zin om na al dit geblaat een mooie samenvatting te maken?

Ikke

http://www.google.com/sea...+style&btnG=Google+Search

ik ga mijn stijl denk ik toch maar ietsje veranderen

bedankt voor opmerking nelske, ik ga erop letten

Je hoeft van mij niks te veranderen hoor, ik gaf alleen aan wat mij opviel als zijnde een klein beetje inconsistent. Als dat het enige is, dan is er niks aan de hand

[Vaudtje]

Voor Java heeft Sun zelf een aantal handreikingen over code style en code conventions.
(Sowieso staan er in de Java Language Specification al handreikingen mbt source layout)
Wat ik zo snel kon vinden is bijvoorbeeld degene waar ikzelf altijd mee werk, en kennelijk Sun zelf ook:
http://java.sun.com/docs/codeconv/

En ik vond deze ook nog, die is behoorlijk uitgebreid en bespreekt ook bijvoorbeeld naamgeving conventies voor jars e.d. :
http://wwws.sun.com/softw...hitepapers/java-style.pdf

En er zijn natuurlijk ook nog de Javadoc standaarden voor documentatie in de source, die weer zijn eigen style guide kent. Sommige IDE's ondersteunen zelfs syntax checking en code completion in Javadoc (i.i.g. IntelliJ IDEA):
http://java.sun.com/j2se/...ingdoccomments/index.html

En nog iets: In welke taal schrijft iedereen zijn code en commentaar?
_{(Op GoT zeg je er dan bij waarom )}
Als ik in het Nederlands bezig ben dan krijg ik dat meestal toch niet consequent, omdat je ook weer objecten gebruikt uit de standaard libraries, die weer in het Engels zijn. Voor OSS in Engels natuurlijk de de facto standaard, maar ik heb mezelf al wel eens betrapt op zinnen die onderweg echt drie keer wisselden tussen NL en EN

[ Voor 23% gewijzigd door Vaudtje op 05-01-2004 23:14 . Reden: en nog iets... ]

[faabman]

mmm, ik denk dat het ongeacht of je in een projectgroep werkt belangrijk is om je code zo in elkaar te zetten dat een persoon die in de toekomst onderhoud doet aan je code begrijpt waar je mee bezig bent geweest, dat betekend dus regelmatig comments geven en duidelijke namen geven aan je variabelen / constanten...

verder is het natuurlijk gewoon een kwestie van smaak en in de grote bose wereld van microsoft en de rest wordt er afaik toch niet met echt 'grote' standaarden of conventies gewerkt, dus is er ook geen noodzaak om je aan bepaalde regels te houden

de vergelijking tussen programmeren en je eigen handschrift is op zich wel grappig, ik heb eens ergens gelezen dat je iq omgekeerd evenredig is met hoe 'net' je schrijft, dus dat zou slecht nieuws moeten zijn voor alle devvers met een hoog iq

[drm]

Ik las vanavond dat oude topic nog eens terug, en frappant genoeg ben ik van een aantal dingen toch terug gekomen. Vroeger gebruikte ik altijd

code:

if ( a ) 
{

}
else if ( b ) 
{

}
else
{
 
}

Gek genoeg ben ik daar vanaf gestapt. Ik weet niet precies waarom... Waarschijnlijk omdat ik het toch niet erg logisch vindt allerlei enters te zetten waar ze eigenlijk niet zo erg veel toevoegen. Een stukje java code van hoe ik (tegenwoordig) gewend ben te coden:

offtopic:
het eerste het beste wat ik tegenkwam

Java:

package x.y.z;

import java.util.*;

public class ShuffleTest {
   private List list;

   public ShuffleTest () {
      list = new ArrayList ();
   }

   public void go () {
      for ( int i = 0; i < 10; i ++ ) {
         list.add ( new Integer (i) );
      }
      Collections.shuffle ( list, new Random () );

      Iterator iterator = list.listIterator ();
      while ( iterator.hasNext () ) {
         System.out.println ( iterator.next () );
      }
   }

   public static void main ( String args[] ) {
      ShuffleTest app = new ShuffleTest ();
      app.go ();
   }
}

Dat is gewoon een kwestie van smaak denk ik.

Waar ik wellicht nog wel wat zinnigs over kan zeggen is PHP.

Wat ik tegenwoordig doe _{(tipje van Cheatah, ere wie ere toekomt )} met SQL is het in aparte bestanden zetten. Vervolgens met een soort printf-achtige toestand je queries op een wat primitieve manier parametrizeren. Met een db-wrappertje daarbij scheelt dat een hoop meuk in je code.

Voorbeeldje:

PHP:

<?
include ( './inc/inc.stdlib.php' );
include ( './inc/inc.locale.php' );

import ( 'MySQL' );

$db = new MySQL ();
$db->connect (  'server', 'user', 'password', 'dbname' );

if ( isset ( $_GET [ 'page_id' ] ) && is_numeric ( $_GET [ 'page_id' ] ) ) {
   $page = $db->select ( 
      'page/select.by-id', 
      $current_locale_id, 
      (int) $_GET [ 'page_id' ] 
   );
} else {
   $page = false;
}

if ( ! $page ) {
   $page = $db->select ( 'page/select.default' );
}

$nav = $db->selectAll ( 'page/select.nav', $current_locale_id );
$sub_nav = $db->selectAll ( 
   'page/select.children', 
   $current_locale_id, 
   $page [ 'page_id' ] 
);

include ( sprintf ( './template/inc.%s.php', $page [ 'template_core' ] );

Zo'n sql bestandje wordt natuurlijk uit de sql directory gehaald waar je niet in kan browsen ( .htaccess'je met deny from all) en ziet er ongeveer zo uit:

SQL:

SELECT
   page$locale.title,
   page$locale.contents,
   DATE_FORMAT('%%d-%%m-%%Y',page.date_created) as date_created,
   template.core as template_core
FROM
   page 
      INNER JOIN page$locale ON(
          page$locale.locale_id=%1$d
          AND
          page.page_id=page$locale.locale_id
      )
      INNER JOIN template ON(
          page.template_id=template.template_id
      )
WHERE
   page.page_id=%2$d
AND
   page.is_visible='true'

offtopic:
Dit is overigens alweer wat verouderd, want ik ben net toevallig met een wat betere versie begonnen

Ik denk dat dat is wat bij PHP'ers nog veel mist. Gewoon redelijk transparante code gebruiken, en niet elke keer maar weer die mysql_* functies tussen je code door, en weer die queries in een string in je code, je pas met HTML bemoeien als dat interessant is, etcetera, etcetera...

[faabman]

drm schreef op 05 januari 2004 @ 23:16:
Ik denk dat dat is wat bij PHP'ers nog veel mist. Gewoon redelijk transparante code gebruiken, en niet elke keer maar weer die mysql_* functies tussen je code door, en weer die queries in een string in je code, je pas met HTML bemoeien als dat interessant is, etcetera, etcetera...

Ik denk dat de meeste webscripters naast het verzorgen van 'nette' code ook wel eens mogen kijken naar op de juiste manier toepassen van html. Kom heel vaak sites en trouwens ook topics tegen waarbij dat echt slecht is (en dan te bedenken dat er in /13 een hoop mensen zijn die heel goed kunnen vertellen hoe het moet )

[ Voor 3% gewijzigd door faabman op 05-01-2004 23:25 ]

[zoepercavia]

Voor C#:

http://www.idesign.net/id...p%20Coding%20Standard.zip - vrij bekende coding standard voor c#, gebaseerd op Microsoft's standaarden.

http://www.tiobe.com/standards/gemrcsharpcs.pdf - C# guidelines van Philips, errug uitgebreid. Staan ook standaard manieren in om dingen op te lossen. Neemt Microsoft's standaard over en breidt em uit.

[ripexx]

drm schreef op 05 januari 2004 @ 23:16:

Om even te reageren op wat drm hierboven schrijft. Ik code nu ook op de manier waarop drm begonnen is. Voordeel hiervan is dat als je met name een beginnende php-prutser bent Je dan toch een duidelijk overzicht hebt. Vooral met debuggen is het een stuk handiger.

Verder heb ik nog al de neiging om veel HTML direct in mijn scripts te gebruiken. Dit komt deels omdat het hobby is en maar op kleine schaal wordt gebruikt. Eigenlijk is het gewoon luiheid. Verder vind ik die scheiding van SQL en PHP zeker een goede zet. Metname de grotere queries maken het een stuk onoverzichtelijker.

Als ik mijn ranzig constructie van toen vergelijk met nu dan is het als stuk beter. Je leert iig veel door boeken te lezen en code van andere te bekijken.

[Anoniem: 19486]

Ik doe het op deze manier:

code:

if($i < 10) {
    doe iets.....
} else {
    doe iets anders
}

Het argument waarom ik dit doe?
Het is niet dat dit netter of beter is dan andere stijlen. De reden waarom ik dit doe is om mijn bestanden zo klein mogelijk te houden.
Zet dit voorbeeld 10x in een tekstbestand en je hebt een bestand van 696 bytes.
Zet dit:

code:

if($i < 10)
{
    doe iets.....
}
else 
{
    doe iets anders
}

10x in een tekstbestand en je krijgt ineens een bestand van 736 bytes.
Je zou zeggen, dat scheelt toch niets maar denk eens aan projecten waar je ,op mijn manier, meer dan 200.000 regels code hebt (en die zijn er genoeg).
De verschillen worden dan toch behoorlijk groot.

Dit is eigenlijk de reden waarom ik voor deze stijl heb gekozen EN om eerlijk te zijn, ik vind het de meest prettige manier. Inspringen is wel zeeeer belangrijk.

// toevoeging:
Nog 2 dingen die ik erg belangrijk vind in goede overzichtelijke code,
- duidelijk commentaar
- scheiden van (in PHP) code en HTML, oftewel een template systeem gebruiken. Code in de HTML probeer ik zo veel mogelijk tot het minimum te beperken.

[ Voor 14% gewijzigd door Anoniem: 19486 op 06-01-2004 09:40 ]

[whoami]

Anoniem: 19486 schreef op 06 januari 2004 @ 09:35:

10x in een tekstbestand en je krijgt ineens een bestand van 736 bytes.
Je zou zeggen, dat scheelt toch niets maar denk eens aan projecten waar je ,op mijn manier, meer dan 200.000 regels code hebt (en die zijn er genoeg).
De verschillen worden dan toch behoorlijk groot.

Ik vind dat maar een wazig argument hoor.
Dit:

code:

{

is geen regel code.

De grootte van je source-files maakt trouwens niet uit.

[Erkens]

Anoniem: 19486 schreef op 06 januari 2004 @ 09:35:
*iets over filesize*

Ik vind de grote in bytes niet echt boeiend als het gaat om source code, ik bedoel, met de huidige hd's en netwerken (en compressie tools) maakt het dus niet echt uit.
Wel vind ik het handiger source lezen als er minder van deze (in mijn ogen) nutteloze whitespace inzit. Voor en na sommige if-statements, met name als ze wat langer zijn, doe ik wel een lege regel, om de leesbaarheid te vergroten, net zo belangrijk als indenting imo.

[drm]

whoami:
De grootte van je source-files maakt trouwens niet uit.

Op een windows-systeem is elke newline toch gauw 2 bytes, afgezien van het feit dat het imo ook een non-argument is. Tenzij je bedoelt dat je je anders helemaal het leplazarus moet scrollen

[Janoz]

@TheLightwaver
Ik weet niet waar je mee bezig bent, maar door in je bovenstaande code enkele spaties te vervangen in een newline krijg je onderstaande code. Er is dan geen enkel teken toegevoegd! (Tenzij je natuurlijk op windows werkt waar een newline uit 2 bytes bestaat, maar aangezien je met 200.000 regels code werkt en voor jou blijkbaar elke byte telt kan het gewoon niet anders dan dat je onder linux werkt )

ff serieus: Diskruimte is zo'n non argument. Tegenwoordig krijg je een 40 gieg schijf (als ze uberhaupt nog worden gemaakt) bij een zak wortels. Om40 gieg te besparen door dit soort truckjes in je code toe t passen ben je nog wel even bezig. Verder vraag ik me af wat er, waneer dit soort besparingen blijkbaar nodig zijn, met het commentaar gebeurt.

[Janoz]

Hier op het werk zitten we na te denken over een tool waarvan ik de naam even ontschoten (iets met een J). Hiermee kun je code formatten in een afgesproken codestyle. Op die manier kan iedereen zijn eigen code style blijven gebruiken. Zodra een stuk source wordt uitgechecked (uit cvs oid) kan de stijl worden aangepast aan de programmeur die er dan mee werkt, en bij het inchecken wordt het weer omgezet naar de algemene codestyle.

Ik heb echter geen ID of het een beetje fatsoenlijk werkt . Op dit moment zijn er alleen nog vage plannen..

edit: Naam is trouwens jacobe.

[ Voor 8% gewijzigd door Janoz op 06-01-2004 09:58 ]

[whoami]

drm schreef op 06 januari 2004 @ 09:51:
[...]
Op een windows-systeem is elke newline toch gauw 2 bytes, afgezien van het feit dat het imo ook een non-argument is. Tenzij je bedoelt dat je je anders helemaal het leplazarus moet scrollen

Regions gebruiken.

[Creepy]

Onder Linux/Unix gebruikte ik hier indent voor. Ideaal voor schoolprojecten. In je eigen stijl je code inkloppen, indent er overheen met de juiste opties en ineens heeft de code een compleet andere stijl. Indent werkte toen volgens mij alleen met C, en waarschijnlijk ook C++. Geen idee of het nu ook andere talen ondersteunt.

Edit: Ah, jacobe is alleen voor java dus.

[ Voor 7% gewijzigd door Creepy op 06-01-2004 10:04 ]

[Anoniem: 19486]

Ik heb alleen het argument gegeven waarom ik toendertijd ben overgestapt op deze manier. Komt eigenlijk vanuit de periode dat ik begon met C.

Dat schijven tegenwoordig super groot zijn weet ik. Ik hou gewoon mijn bestanden het liefst zo klein mogelijk. Dit heb ik weer vanuit het grafische werk overgenomen. jpg's, gifs etc hou je ook zo klein mogelijk dus waarom de bestanden met code niet?
Misschien een wazig argument maar er werd gevraagd hoe en waarom we een bepaalde stijl hebben.

Of dit de beste manier is weet ik niet, maar daarom heb ik hier toen voor gekozen.
Op den duur een kwestie van gewoonte, niets anders.

[Erkens]

Anoniem: 19486 schreef op 06 januari 2004 @ 10:05:
Dat schijven tegenwoordig super groot zijn weet ik. Ik hou gewoon mijn bestanden het liefst zo klein mogelijk. Dit heb ik weer vanuit het grafische werk overgenomen. jpg's, gifs etc hou je ook zo klein mogelijk dus waarom de bestanden met code niet?
Misschien een wazig argument maar er werd gevraagd hoe en waarom we een bepaalde stijl hebben.

Maar, jpg's en gifs enzo zijn _output_ files, ik neem aan dat het origineel dat je in photoshop ofzo maakt ook niet echt klein is
Zelf zou ik dan de gecompileerde versie klein willen hebben

[curry684]

Janoz schreef op 06 januari 2004 @ 09:56:
Hier op het werk zitten we na te denken over een tool waarvan ik de naam even ontschoten (iets met een J). Hiermee kun je code formatten in een afgesproken codestyle. Op die manier kan iedereen zijn eigen code style blijven gebruiken. Zodra een stuk source wordt uitgechecked (uit cvs oid) kan de stijl worden aangepast aan de programmeur die er dan mee werkt, en bij het inchecken wordt het weer omgezet naar de algemene codestyle.

Ik heb echter geen ID of het een beetje fatsoenlijk werkt . Op dit moment zijn er alleen nog vage plannen..

edit: Naam is trouwens jacobe.

Fascinerend idee.... eens kijken of ik daar op termijn iets mee kan voor C/C++

* curry684 was toch al van plan binnenkort een C/C++ parsertje te schrijven voor iets andere doeleinden.