Het programmeren, wat onthoud je en wat zoek je op?

[AW_Bos]

Ik ga over een weekje dan eindelijk aan mijn nieuwe baan beginnen waar ik ga programmeren met PHP, xHTML, JS, CSS en MySQL en CRM systemen ga ontwikkellen.

Nu vraag ik me af, op welke manier de programmeurs hier op Tweakers applicaties in elkaar zetten, en dan bedoel ik vooral het benutten van de kennis ervoor.
Kijken jullie vaak op php.net en de andere manuals en references, of kennen jullie de functies en de opbouw uit jullie hoofd van bijv. de setcookie functie?
En copy-paste je ook veel (om het vervolgens vaak iets aan te passen) of doe je dat ook uit het blote hoofd?
Of gebruiken jullie voor de functions een auto-completer in jullie editor die na mysql_co.. jouw al kan vertellen dat je vast wel mysql_connect bedoelt?

Ik ben er gewoon erg benieuwd naar, ik wil namelijk graag verwachten hoe dat gaat bij een bedrijf.
Ik heb wel gekeken op de vloer daar tijdens de sollicitatie, maar je gaat natuurlijk geen hele minuten kijken naar hoe iemand een code aan het inkloppen is.

Dus... ik ben er benieuwd naar...

Ikzelf ben meer de man van copypasten, en niet het wiel dubbel uitvinden.

[Xcalibur]

De php manual zit wel bij m'n favorieten zeg maar, maar veelgebruikte functies weet je op een gegeven moment wel natuurlijk. Hoewel de needle/haystack volgorde nog wel eens wil wisselen in PHP...

Ik probeer zoveel mogelijk 'generieke' code te maken die ik gemakkelijk kan hergebruiken. Ik ben ook heel consequent in de naamgeving van variabelen en arrays, zodat ik niet gelijk in de knoei kom als ik iets wat ik al eens heb gemaakt hergebruik

Autocompletion gebruik ik zelden eigenlijk...

[Kaastosti]

Ik stel me altijd voor dat ik morgen ineens van het project wordt gehaald en een ander het over moet nemen... aannemende dat de vervanger de basics wel kent. Dan moet dat relatief makkelijk gaan

Duidelijke code, commentaar er tussen, uitlijning, alles in blokjes met een specifiek doel verwerken etc. etc.

Werkt tot zover echt prima... want als ik een paar dagen op een ander project heb gezeten moet ik soms ook weer even bedenken wat ik de week ervoor ook al weer voor briljante oplossingen heb verzonnen

En inderdaad cheat sheets hier en daar, alhoewel die er voor mij weinig zijn. Lang leve persoonlijke archieven

[ Voor 10% gewijzigd door Kaastosti op 06-11-2008 19:21 ]

[Hillie]

Richt je op methodiek, algoritmiek, begrijp hoe je complexe problemen op kunt splitsen in behapbare stukken die je op kunt lossen. En, maar da's soms afhankelijk van wat je doet, naar Xcalibur luisteren: Herbruikbare code, fatsoenlijke naamgeving, etcetera.

Ik ondersteun tools met een paar talen, maar ik kijk ook gewoon in de documentatie. Weten waar je iets kunt vinden is misschien nog wel belangrijker dan nutteloos allerlei syntax oplepelen. Spul wat je veel gebruikt heb je vanzelf in de vingers. En in m'n supportrol geef ik ook trainingen. Soms heb je een trotse deelnemer die alles zo oplepelt, en met z'n in 1x goed geschreven code mij in 2500 regels laat huilen met prutscode die een goede klopper in een paar honderd neerlegt.

[phobosdeimos]

Goed zijn in software ontwikkeling heeft absoluut niets te maken met de setcookie functie, MySQL, PHP, of welke andere techniek dan ook.
Dat zijn allemaal slechts hulpmiddelen om een doel te bereiken.
Net alsof je zou zeggen dat het bij hardlopen vooral om de schoenen draait
Programmeren vergt, naar mijn mening, vooral 2 zaken om echt goed te worden:
- veel praktijk ervaring
- specialisatie, maar ook vooral diversificatie

Met dat laatste bedoel ik dat iemand die enkel Java of enkel C#.NET op zijn CV heeft staan je moeilijk als een "goeie programmeur" kan beschouwen (en nee, HTML/CSS/XML/XSLT zijn geen programmeertalen).
Je zou minstens 1 programmeertaal uit elke filosofie onder de knie moeten hebben (procedureel, functioneel, object-oriented).

[PolarBear]

Ariën Clay schreef op donderdag 06 november 2008 @ 18:53:
Kijken jullie vaak op php.net en de andere manuals en references, of kennen jullie de functies en de opbouw uit jullie hoofd van bijv. de setcookie functie?

Gebruik de mogelijkheden die de IDE en de taal bieden, VS.Net biedt heel wat nuttige code completion mogelijkheden, code snippets etc. Het laat me zien welke welke parameters er mogelijk zijn en waarvoor ze dienen. Vervolgens heb ik een integratie met MSDN voor verder uitleg over van alles en nog wat in het .Net framework. En als laatste maar niet als minste Google.

En copy-paste je ook veel (om het vervolgens vaak iets aan te passen) of doe je dat ook uit het blote hoofd?

Copy pasten betekent dat je naamgevingen van een ander overneemt. Je kan het aanpassen (wat met refactoren soms best goed gaat), maar vaak ben je netto net zo snel door het zelf te schrijven.

Of gebruiken jullie voor de functions een auto-completer in jullie editor die na mysql_co.. jouw al kan vertellen dat je vast wel mysql_connect bedoelt?

Ik zelf ben heel erg blij met Intellisense, zeker in VS.Net 2008 werkt het als een trein.

Ikzelf ben meer de man van copypasten, en niet het wiel dubbel uitvinden.

Toch denk ik dat je van zelf doen meer leert en sneller een taal onder de knie hebt. Voorbeelden gebruiken doet iedereen maar copy-pasten is mij een stap te ver.

[NMe]

* NMe ziet een geinige discussie en bietst hem snel naar een écht forum.

SG>>PRG

[Deviruchi]

Mijn inziens is het niet belangrijk of je alle functies van een taal kent, of misschien maar enkele. Het gaat om de denkwijze, zolang die goed is kun je uiteindelijk alle code wel schrijven. Functies kun je opzoeken, een denkwijze kun je niet zomaar opzoeken en komt voor uit ervaring.

Zelf ben ik een vrij vlugge typer dus ik copy & paste vrij weinig. Mijn collega's kopieëren vaker uit oude code, het is denk ik maar net wat je gewend bent. Copy & paste of zelf typen maakt niet het verschil tussen een goede en slechte programmeur.

Uiteindelijk gaat het erom dat alle betrokken partijen van een project tevreden zijn. Of dit nou gebeurd doordat jij allerlei open-source projecten samenvoegd, ofdat je zelf teken voor teken hebt getyped is onbelangrijk. Je programmeerstijl is slechts een middel om je doel te bereiken. Dat een goede en zorgvuldige programmeerstijl en syntax leidt tot betere aftersales (immers is het makkelijker en dus goedkoper een aanpassing te doen) is echter een ander verhaal en staat dus in zekere zin in relatie tot het wel of niet slagen van een project.

Ieder bedrijf heeft uiteindelijk zijn eigen regels qua syntax en denkwijze, geen één is goed of fout.

[ Voor 37% gewijzigd door Deviruchi op 06-11-2008 20:00 ]

[FragFrog]

Aangezien ik een groot voorstander ben van DRY programming copy-paste ik eigenlijk nooit. Kan me serieus niet herinneren wanneer ik voor het laatst code gekopieerd heb - let wel, dat is overigens niet hetzelfde als verplaatsen. Soms komt een klant met een zut extra wensen terwijl een project al in testfase is, mijn baas heeft dan de neiging dat alles (onder een leuke rekening, dat wel) ook gewoon toe te staan, als een class dan te lang wordt gooi ik al snel generieke functionaliteit in een nieuwe class - die vervolgens ook weer op andere plekken gebruikt kan worden. Tussen verschillende projecten uiteraard wel, maar dan pakken we ons generieke framework en bouwen we daar op verder.

Code-completion gebruik ik ook nooit in PHP trouwens; in JAVA wel, maar die taal ken ik minder goed en het helpt me als naslagwerk Overigens is de PHP handleiding geniaal in dat alles wat je moet onthouden is php.net/[naam functie].

Zorg dat je snel bekend raakt met de huisstijl, als die aanwezig is. De manier waarop je brackets zet, naamgeving van variabelen al dan niet met underscores, constanten met hoofdletters, dat soort zaken. Het zorgt ervoor dat anderen je code makkelijker kunnen herkennen. Wat eerder al gezegd is, zorg ook voor goede documentatie: standaard pak ik vaak het laatste half uurtje van de dag / een subproject om de geschreven code bij langs te lopen, van comments te voorzien, dubbele functionaliteit eruit te slopen, classes op te splitsen waar ze te groot worden, etc. Na een uurtje of zeven coden ben ik toch niet meer zo helder dat ik nieuwe code wil tikken, documenteren is dan een mooi alternatief

Heb ooit eens een college gehad die classes van 600, 700 regels schreef met heel veel dubbele functionaliteit, zo goed als geen comments, absurde functienamen, variabelen als $sql_query_1, $sql_query_2, etc, toen die de laan uit gestuurd is en we de puinhoop op zijn gaan ruimen hebben we na een half uurtje maar besloten om zijn werk (van een maand of drie) overnieuw te doen; kostte uiteindelijk maar anderhalve week en de bugreports waren gehalveerd

[zwippie]

Ik ben zelf een enorme liefhebber van autocompletion en parameter hints, al is het maar dat ik dan minder hoef te typen. Of de lijst met member variabelen en methodes die je krijgt als je een . of -> tikt na een objectnaam. Ook ben ik erg blij als mijn IDE met een druk op de knop de reference guide kan openen voor de functie of klasse die ik onder de cursor heb.

Dat soort dingen werken voor het grootste deel natuurlijk het beste in ((bijna) puur) object georienteerde talen. Bij PHP wordt het al weer een stuk lastiger, dan krijg je bijvoorbeeld 30 suggesties als je ->save intikt.

In de praktijk ken je na een paar weken de meest gebruikte functies wel uit je hoofd. De autocompletion is vooral erg handig bij nieuwe libraries of de eigen code van het bedrijf. Helemaal als je daar net begint. Succes btw!

[Zoijar]

Alles zo snel mogelijk wrappen met classes, en dan auto-completion gebruiken als "reference".

[phobosdeimos]

Zoijar schreef op donderdag 06 november 2008 @ 20:40:
Alles zo snel mogelijk wrappen met classes, en dan auto-completion gebruiken als "reference".

OO is niet de heilige graal van software development

[Zoijar]

phobosdeimos schreef op donderdag 06 november 2008 @ 21:06:
OO is niet de heilige graal van software development

Heeft op zich vrij weinig met OOP te maken, het is meer een vorm van functionaliteit groeperen en encapsuleren die je later makkelijk terug kan vinden in een relevante namespace. Of dat nou een instantieerbaar object is of niet maakt niet echt uit, zolang gelijksoortige functionaliteit maar op dezelfde plek te vinden is. Ik gebruik vrij weinig OO technieken zelfs. Maar als ik bijvoorbeeld een OpenGL texture ID heb, dan wrap ik daar alle relevante opengl calls omheen in een object. Op die manier zie ik in mijn auto-completion meteen wat ik ook al weer met een texture kan doen, zonder elke keer de OpenGL reference open te slaan. Voor mijn part groepeer je het in namespace globale functies zodat je kan doen "GL::texture::create(), GL::texture::bind". zodar ik dan GL::texture:: intype, dan hoef ik niet meer op te zoeken hoe de bind call ook al weer heet; was het nou glBindTexture of glTextureBind of glSetTextureState(GL_BIND) etc. Dat was wat ik bedoelde.

[.oisyn]

phobosdeimos schreef op donderdag 06 november 2008 @ 19:32:
Je zou minstens 1 programmeertaal uit elke filosofie onder de knie moeten hebben (procedureel, functioneel, object-oriented).

Totaal niet mee eens, en bovendien is het een beetje een raar lijstje (waarvan ik de indruk heb dat jij die 3 opnoemt omdat je ze toevallig op de universiteit hebt gehad). Zeg dan: imperatief en declaratief. Daarnaast zijn er nog zo veel meer paradigima's en subparadigima's. Het is echt onzin dat je de meeste of zelfs maar de helft oid onder de knie hoeft te hebben om een goede programmeur te zijn. Zolang je maar weet dat er meer is.

Een goede programmeur kan een probleemoplossing vertalen naar een computerprogramma en dat op een zo'n praktische manier mogelijk (dus onderhoudbaar, performant waar van toepassing, etc.), en weet wanneer welke keuze de juiste is. Het doet er daarbij echt niet toe welk paradigima je aanhoudt (zolang het maar een goede keuze is).

[ Voor 10% gewijzigd door .oisyn op 06-11-2008 21:35 ]

[phobosdeimos]

oisyn:
als je op wikipedia een programmeertaal opzoekt, is die altijd in één van de grote "gedachtegangen" ingedeeld, met name procedural (C), functional (Scheme) of object-oriented (Java). (of je hebt python, die doet het allemaal
Ga je betwisten dat 90% van de gebruikte programmeertalen tot één (of soms meerdere) van die klasses behoren?
Grappig hoe je met zo'n zwak aanvalletje komt, net alsof IK die drie paradigma's uit m'n mouw heb geschud Op mijn 5 jaar aan de unief heb ik ze inderdaad alle 3 gezien, maar ik kende ze alle 3 al voor ik aan de unief begon, dus maak je geen zorgen.
Je leest ook niet wat ik zeg, ik zeg helemaal niet dat deze of deze manier de beste is, of dat je het op die of een andere manier MOET doen.
Ik zeg gewoon dat het positief is voor je ontwikkeling als programmeur als je op zijn minst wat kennis hebt van alle 3 de manieren van denken.
Dat helpt je beter om concepten als tail-recursion en dergelijke te begrijpen.
Net zoals je beter wordt in natuurlijk talen in het algemeen, telkens je meer in aanraking komt met vreemde talen.
Toen ik Italiaans begon te studeren, had dat onrechtstreeks ook een positieve invloed op mijn kennis van Frans.
Als je als programmeur denkt dat de enige vorm van programmeren het OO-obsessief denken van Java is, dan kom je tekort, imho.

Zoijar: ik snap wat je bedoelt, maar als je spreekt van klasses, dan neem ik aan dat je het over OO hebt, en niet over C structs

[ Voor 17% gewijzigd door phobosdeimos op 06-11-2008 21:43 ]

[.oisyn]

phobosdeimos schreef op donderdag 06 november 2008 @ 21:39:
oisyn:
als je op wikipedia een programmeertaal opzoekt, is die altijd in één van de grote "gedachtegangen" ingedeeld, met name procedural, functional en object-oriented.

Sure, maar er zijn er zoveel meer, en waar procedureel en OO nauw aan elkaar verwant zijn is functioneel dat nou weer juist niet. Je keuze voor die 3 leek wat arbitrair (en bovendien absoluut) .
Procedureel en OO zijn subparadigima's van het imperatieve paradigima. Deze twee subparadigima's worden idd het meest gebruikt. Maar aspect oriented programming is bijvoorbeeld ook imperatief (en zie je ook regelmatig terugkomen). Ik wil trouwens niet spreken van taal, omdat het een manier is om je programma te beschrijven. Natuurlijk helpt de opzet van de taal bij een bepaald paradigima, maar het wil niet zeggen dat je in C niet OO kunt programmeren of in Java niet procedureel.

Functioneel valt verder onder declaratief, maar logische talen ook - Je hebt vast weleens gehoord van Prolog? Vrij vergelijkbaar met een functionele taal, maar de ene is bottom-up en de ander top-down.

En zo zijn er tal van anderen, zoals event based programming wat weer een heel eigen genre is. Hier staat een mooi lijstje.

Ga je betwisten dat 90% van de gebruikte programmeertalen tot één (of soms meerdere) van die klasses behoren?

Als je het hebt over 90% van de gebruikte programmeertalen kon je functioneel ook wel achterwege laten. En nee, dat wil ik trouwens niet betwisten, en dat deed ik ook niet.

ik zeg helemaal niet dat deze of deze manier de beste is, of dat je het op die of een andere manier MOET doen. Ik zeg gewoon dat het positief is voor je ontwikkeling als programmeur als je op zij minst wat kennis hebt van alle 3 de manieren van denken.

Nee, dat zei je niet. Je zei vrij letterlijk dat een goede programmeur een taal uit elke filosofie (imperatief, OO, functioneel) onder de knie moest hebben. Dát is wat ik betwist, maar dat is wat je nu aan het nuanceren bent.

Dat helpt je beter om concepten als tail-recursion en dergelijke te begrijpen.

Daarom zei ik ook dat het zeker handig is als je weet wat afweet van andere paradigima's. Dat is echter wat anders dan dat je die talen onder de knie moet hebben.

.edit nav jouw edit:

Grappig hoe je met zo'n zwak aanvalletje komt, net alsof IK die drie paradigma's uit m'n mouw heb geschud

Het is geen aanval(letje), het is een indruk die ik had. Omdat je er 3 noemt, terwijl er tientallen zijn, maar waar je op een opleiding vaak niet van hoort

[ Voor 14% gewijzigd door .oisyn op 06-11-2008 22:07 ]

[phobosdeimos]

Ok, vervang "onder de knie hebben" dan door "bekend zijn met". Ik heb wel wat code in Scheme geschreven, maar om te zeggen dat ik het "onder de knie heb" is idd veel gezegd.

[Data-base]

Ik denk dat je vooral niet moet proberen om dingen te gaan onthouden of uit je hoofd te leren. Wanneer je een goede IDE hebt, vult deze jou aan met de informatie die je mist.
Functies die JIJ vaak gebruikt (afhankelijk van tijd en voorkeur) zul je na een tijdje kunnen dromen, terwijl je de andere functies die je eens per maand gebruikt even moet opzoeken. Om de syntax(volgorde / typen van parameters) of functienaam te achterhalen gebruik ik de handigheden van visual studio.

Wat ik nog kwijt wil is dat mensen die beweren dat auto complete onzin / zinloos imo heel erg eigenwijs en totaal neit praktisch bezig zijn. Met goede autocomplete ben ik (dat is dus persoonlijk) 20-50% productiever. Nu zal dat natuurlijk per persoon verschillen. Maar ik geloof niet dat je zonder auto-complete sneller of even snel kan zijn aangezien je minder toetsaanslagen nodig hebt en minder fouten kan maken(qua naam dan).

Wat de paragima's betreft,
Waarom moet een gemiddelde huis tuin en keuken software engineer het functioneel programmeren beheersen? Zolang je niet mathematisch (of wetenschappelijk) bezig bent, heb je geen flikker aan haskall. En idem voor prolog, dat je er van gehoord moet hebben, oke, en als je t kan, super. Maar ik denk niet dat je een minder goede programmeur bent als je alleen de huis tuin en keuken talen kent.

[ Voor 18% gewijzigd door Data-base op 06-11-2008 22:15 ]

[Gomez12]

Uit eigen ervaring kan ik je zeggen dat ik erg hang op language manuals.

Hoe langer ik met een project op 1 taal bezig ben hoe minder ik op die betreffende language manuals hoef terug te vallen.

Imho moet je als programmeur gewoon op verschillende manier kunnen programmeren / denken en dit moet gewoon taalonafhankelijk zijn.

Als ik een waarschuwing aan de gebruiker aan de gebruiker wil geven dan wil ik een waarschuwing aan de gebruiker geven waar hij gewoon niet omheen kan, of ik dan in javascript library x een modal moet gebruiken of in winforms applicatie y een msgbox dat vind ik wel terug in de language reference.
Net zoals wanneer ik 2 variabelen wil vergelijken. De gedachtengang is taalonafhankelijk, dat ik in VB een enkele = moet gebruiken en in php een === dat staat wmb mooi in de language reference...

Concepten kan je wmb leren, maar taalspecifieke dingen vind ik vrij nutteloos, dat heb ik in een paar minuten opgezocht in de language reference of mbv een intellisense gevonden.

Maarja ik pretendeer dan ook in bijna alle talen te kunnen programmeren en heb hooguit een voorkeur voor een bekende als het snel, snel moet gebeuren.
Moet het goed gebeuren dan maakt het mij weinig uit of het in cobol of in java of in php moet gebeuren. 80% van de achterliggende processen zijn hetzelfde alleen de uitvoering is taalspecifiek

Data-base schreef op donderdag 06 november 2008 @ 22:12:
Wat ik nog kwijt wil is dat mensen die beweren dat auto complete onzin / zinloos imo heel erg eigenwijs en totaal neit praktisch bezig zijn. Met goede autocomplete ben ik (dat is dus persoonlijk) 20-50% productiever. Nu zal dat natuurlijk per persoon verschillen. Maar ik geloof niet dat je zonder auto-complete sneller of even snel kan zijn aangezien je minder toetsaanslagen nodig hebt en minder fouten kan maken(qua naam dan).

Tsja, ben ik een beetje dubbel in. Autocomplete is soms te makkelijk.
Onbekende taal en ik begin wat te gokken voor een functie, autocomplete komt met een suggestie die mij wel goed lijkt dus gebruik ik die. Later blijkt opeens dat deze functie in deze taal toch niet 100% het resultaat bereikt en dat ik dus een stuk kan gaan refractoren. Stond netjes in de help uitgelegd wat het wel / niet deed. Maar die heb ik niet gelezen want ik gokte dat de autocomplete functie deed wat ik dacht...

En bovenstaande is iets wat ik redelijk vaak in de praktijk zie gebeuren met autocomplete. Mensen die om een niet-bestaand probleem heen gaan werken omdat autocomplete hun een functie voorschotelde die niet 100% deed wat hun dachten.
Vervang de 1e functie door een andere en het probleem is weg, maar in de praktijk zie ik mensen om de beperkingen van de door autocomplete aangedragen functie heenwerken ipv even F1 drukken...

[ Voor 35% gewijzigd door Gomez12 op 06-11-2008 22:20 ]

[.oisyn]

Data-base schreef op donderdag 06 november 2008 @ 22:12:
Wat ik nog kwijt wil is dat mensen die beweren dat auto complete onzin / zinloos imo heel erg eigenwijs en totaal neit praktisch bezig zijn. Met goede autocomplete ben ik (dat is dus persoonlijk) 20-50% productiever. Nu zal dat natuurlijk per persoon verschillen. Maar ik geloof niet dat je zonder auto-complete sneller of even snel kan zijn aangezien je minder toetsaanslagen nodig hebt en minder fouten kan maken(qua naam dan).

Met die mindering in toetsaanslagen scheelt het al een hoop, maar nog veel belangrijker vind ik dat het een vorm van instant documentatie is. Opzoeken hoe iets werkt kost op zich gigantisch veel tijd, tijd die compleet teniet wordt gedaan door zinnige code completion. Al zou je het daarna alsnog los in zou moeten typen dan scheelt dat al enorm .

Wat de paragima's betreft,
Waarom moet een gemiddelde huis tuin en keuken software engineer het functioneel programmeren beheersen? Zolang je niet mathematisch (of wetenschappelijk) bezig bent, heb je geen flikker aan haskall. En idem voor prolog, dat je er van gehoord moet hebben, oke, en als je t kan, super. Maar ik denk niet dat je een minder goede programmeur bent als je alleen de huis tuin en keuken talen kent.

Exactly my point idd.

[Data-base]

Gomez12 schreef op donderdag 06 november 2008 @ 22:14:
...

Voor productiviteit is het niet onhandig als je de basis van een taal kent. Wanneer je voor ieder functie aanroep naar de manual moet grijpen ben je fout bezig (tenzij je hobby't). Als software ontwikkelen (onderdeel) van je baan is, moet je de basis van de taal waar je mee bezig bent redelijk kennen.

[ Voor 61% gewijzigd door Data-base op 06-11-2008 22:23 ]

[Data-base]

.oisyn schreef op donderdag 06 november 2008 @ 22:18:
Met die mindering in toetsaanslagen scheelt het al een hoop, maar nog veel belangrijker vind ik dat het een vorm van instant documentatie is. Opzoeken hoe iets werkt kost op zich gigantisch veel tijd, tijd die compleet teniet wordt gedaan door zinnige code completion. Al zou je het daarna alsnog los in zou moeten typen dan scheelt dat al enorm .

Ja, een van de dingen die ik als eerst doe als ik een VS installatie heb is GhostDoc installeren. Die kan met een druk op de knop (xml)documentatie genereren aan de hand van je functienaam en parameters (mits deze goed zijn).
Als je deze documentatie dan nog een klein beetje fine-tuned dan heb je zelf instant documentation voor je eigen functies.
Leuker kunnen we t niet maken, wel makkerlijk

Edit voor hieronder:
Ja dat bedoel ik ook. Met ghostdoc maak je automatisch comments voor je functie, welke vervolgens als tooltip zichtbaar is wanneer je de functie wil gaan aanroepen.

[ Voor 10% gewijzigd door Data-base op 06-11-2008 22:28 ]

[.oisyn]

Ik denk dat Gomez' punt meer is dat een goede programmeur vrijwel elke taal eigen kan maken (door de docs te lezen). Als je er even in werkt dan onthoud je dingen wel. De standaard dingen natuurlijk. Hoewel ik als een geïnteresseerde in de taal C++ waarschijnlijk meer weet dan voor m'n werk nuttig is (hoewel dit me wel weer de wandelende C++ manual voor m'n collega's maakt RTFM!! ), en ik de laatst 10 jaar bijna onafgezonderd in die taal programmeer, moet ik ook altijd even kijken welke functies ik ook alweer moet overriden als ik m'n eigen streambuf ga implementeren, omdat ik dat simpelweg vrijwel nooit doe. Dit is natuurlijk iets anders dan kijken hoe de vergelijkingsoperator ook alweer eruit zag - dat doe je 1 keer en vervolgens gebruik je 'm zo vaak dat je het niet meer vergeet . Maar in feite zou je een willekeurige programmeur zomaar ineens op een andere taal kunnen zetten. Hij zal er in het begin even iets meer moeite mee hebben dan een ervaren programmeur in die taal omdat hij de syntax niet goed kent, maar hij zal weldegelijk een degelijke applicatie erin kunnen ontwerpen.

En de post eronder: ik bedoelde instant documentatie over het ding dat je aan het gebruiken bent, in de vorm van een tooltip tijdens het typen. Maar goede code documenters zijn natuurlijk ook belangrijk

[ Voor 97% gewijzigd door .oisyn op 06-11-2008 22:30 ]

[steffex]

Wat ik kan aanraden is: probeer het niet eens uit je hoofd te leren. Je zal knettergek worden van alle functies die in een taal als PHP zit. Zoals hierboven ook genoemd wordt is het veel belangrijker om oplossingsgericht te zijn. Als je een oplossing kunt bedenken, kun je aan de hand van een manual al snel de juiste functies erbij vinden.
Toen ik aan mijn baan als webdeveloper begon dacht ik ook dat ik snel alles uit mijn hoofd moest leren, het tegendeel was echter waar. Niemand zal raar kijken als jij een manual op je scherm hebt staan!

Daarnaast zul je in het begin ook niet meteen de meest perfecte code schrijven. Dit hoef je ook helemaal niet te proberen, want zonder ervaring gaat je dit toch niet lukken. Als je eenmaal wat werkervaring hebt en een aantal applicaties hebt geschreven, kun je veel efficienter werken.

Niets is lastiger dan een ingesleten werkmethode te veranderen, dus probeer je niet vast te pinnen op een werkmethode. Op de hoogte blijven van ontwikkelingen en technieken is zeker ook aanrader. Dit voorkomt situaties dat je met je bek vol tanden staat als je andermans werk over moet nemen. Het voornaamste in dit is dat het je een hoop inleestijd scheelt. Dat zal je werkgever altijd toejuichen

Een extra tip die ik kan geven is: ken je wiskunde. Nu hoef je geen wiskunde gedaan te hebben op universitair niveau, maar goed overweg kunnen met mavo niveau wiskunde is zeker een grote hulp.
Nu zeg ik niet dat je niet kunt programmeren zonder overweg te kunnen met wiskunde. Mijn collega zuigt in wiskunde, maar knalt er ook mooie applicaties uit

edit naar aanleiding van mijn trage posten:
je kunt prima uit oude code kopieren, maar loop het altijd na. Het zou jammer zijn als je gekopieerde code achterhaald en niet efficient meer is. Ik kopieer ook wel eens wat omdat ik herinner dat een soortgelijke oplossing in een ander (ouder) project heb toegepast. Als het hele oude projecten zijn, moet ik soms nog wel eens lachen om knullige manier van programmeren wat ik toendertijd had toegepast.

[ Voor 12% gewijzigd door steffex op 06-11-2008 22:33 ]

[Gomez12]

Data-base schreef op donderdag 06 november 2008 @ 22:19:
[...]
Voor productiviteit is het niet onhandig als je de basis van een taal kent. Wanneer je voor ieder functie aanroep naar de manual moet grijpen ben je fout bezig (tenzij je hobby't). Als software ontwikkelen (onderdeel) van je baan is, moet je de basis van de taal waar je mee bezig bent redelijk kennen.

Basis van een compleet onbekende taal ( maar wel volgens de standaard concepten ) heb je imho binnen een week aangeleerd.
Dan heb je misschien nog niet de finesses door hoe je een nette / leuke grafische frontend moet bouwen.
Maar een degelijke backend die berust op een dbase in combinatie met business logica in code en enkele zakelijke concepten moet je dan imho toch wel op een goede manier ( as in niet elke 2 seconden in de documentatie kijken ) kunnen bouwen.

De wiskundige / database technische / business logica implementaties verschillen nou niet echt 100% per taal. 2 getallen bij elkaar optellen is in 99 vd 100 talen gewoon : getal1 + getal2.
Om je invoer van die 2 getallen te controleren zijn er nou ook niet echt 1001 mogelijkheden ( het is een getal binnen een toegestane reeks of niet ).
Om die 2 getallen op te halen zijn er ook niet 1001 mogelijkheden ( het is meestal sql of flat-file of een variabele )
Dat de uitkomst presentatie dan per taal kan verschillen dat vind ik dan weer niet zo boeiend, zorg eerst maar dat de te tonen gegevens juist zijn, dan kan er altijd nog een frontend op gebouwd worden...

[Data-base]

stef-o schreef op donderdag 06 november 2008 @ 22:27:
Een extra tip die ik kan geven is: ken je wiskunde. Nu hoef je geen wiskunde gedaan te hebben op universitair niveau, maar goed overweg kunnen met mavo niveau wiskunde is zeker een grote hulp.
Nu zeg ik niet dat je niet kunt programmeren zonder overweg te kunnen met wiskunde. Mijn collega zuigt in wiskunde, maar knalt er ook mooie applicaties uit

Daar ben ik het idd ook helemaal mee eens. Sterker nog, ik denk dat het naast de wiskunde heel makkelijk is als je ook nog je logica kent. Regels voor distributie (a or (b and c)) == ((a or b) and (a or c)) en de morgan (!(a or b)) == (!a and !b) gebruik ik dagelijks.

[Gomez12]

.oisyn schreef op donderdag 06 november 2008 @ 22:22:
Ik denk dat Gomez' punt meer is dat een goede programmeur vrijwel elke taal eigen kan maken (door de docs te lezen). Als je er even in werkt dan onthoud je dingen wel.

Inderdaad. Als je even in een taal werkt dan onthoud je vanzelf taal-specifieke dingen, 50% van de basis dingen zijn bijna linea recta toe te passen in een andere taal. De rest is of concepten / werkwijzen of taal-specifieke dingen die snel zijn op te zoeken.

Het in je kop stampen van 1 taal is imho gewoon gekkenwerk omdat je sowieso de basis-concepten al moet kennen ( en deze zijn taal-onafhankelijk ) en het taal-specifieke gedeelte is tegenwoordig zo snel aangeleerd / opgezocht dat je alleen maar eenkennig wordt door er 1 uit je hoofd te leren...

De syntax is extreem aan veranderingen onderhevig tussen de talen, de concepten minder. Als jij syntax van een taal kent zegt dit nog niets over een andere taal, ken jij de concepten dan is de syntax zo aan te leren.

[OxiMoron]

Bij PHp weet ik nooit of ik nou de needle in de haystack zoek of de haystack in the needle

strpos is haystack, needle
array_key_exists is weer needle, haystack

Komt erop neer dat ik voor PHP de functie naam onthoud en snel even opzoek als ik hem nog heb om te checken wat de parameter volgorde was

Aan de andere kan heb ik hier op m'n werk het hele framework waar we mee werken opgezet en daar weet ik eigenlijk wel alles uit m'n hoofd.

Zijn hier ook mensen die eclipse ofzo gebruiken om te programmeren en die zoekt alles automatisch op, wat natuurlijk handig kan zijn, maar naar mijn idee niet tot betere kennis van de taal zelf leid.

[phobosdeimos]

offtopic:
Komaan, we hebben het hier over serieuze programmeertalen, waarom zie ik dan telkens PHP opduiken?

[Zoijar]

phobosdeimos schreef op donderdag 06 november 2008 @ 21:39:
Zoijar: ik snap wat je bedoelt, maar als je spreekt van klasses, dan neem ik aan dat je het over OO hebt, en niet over C structs

Een class gebruiken is geen OO: dat hangt namelijk op encapsulatie en polymorphism. Een wrapper class op zichzelf biedt misschien iets van encapsulatie, maar meestal geen polymorphism, en is strict gezien dus niet OO.

Wij gebruikten overigens deze paradigma indeling: imperatief, object oriented, functional, logical, parallel/distributed, overig (oa. constraint-based, access-oriented, data-flow) Vooral data-flow en parallel zijn erg in opmars nu. (http://www-graphics.stanford.edu/projects/brookgpu/lang.html bv) (en uiteraard ontbreken mijn persooonlijke favorieten: generic en concept based) Maar op die manier zijn er zo veel...

[ Voor 10% gewijzigd door Zoijar op 07-11-2008 10:28 ]

[Verwijderd]

Wiskunde is zeker belangrijk bij het programmeren, hoewel ik 'nuttig' een beter woord vind. Naar mate je steeds verder komt met 'het programmeren op zich', merk je het pas. Ik weet nog hoe ik vroeger sceptisch was over wiskunde en of je het nodig zou hebben. Ben nu blij, dat ik vroeger wel eens opgelet heb!

OxiMoron schreef op vrijdag 07 november 2008 @ 08:47:
Bij PHp weet ik nooit of ik nou de needle in de haystack zoek of de haystack in the needle

strpos is haystack, needle
array_key_exists is weer needle, haystack

Komt erop neer dat ik voor PHP de functie naam onthoud en snel even opzoek als ik hem nog heb om te checken wat de parameter volgorde was

Dit is een manier van werken die ik wel vaker terug zie bij mensen die met PHP werken. Doe het zelf ook meestal zo, behalve de meest bekende en voor de hand liggende functies natuurlijk.

phobosdeimos schreef op vrijdag 07 november 2008 @ 10:09:

offtopic:
Komaan, we hebben het hier over serieuze programmeertalen, waarom zie ik dan telkens PHP opduiken?

offtopic:
PHP begint er steeds meer op te lijken En is natuurlijk immens populair...

[Hydra]

Gomez12 schreef op donderdag 06 november 2008 @ 22:14:
Tsja, ben ik een beetje dubbel in. Autocomplete is soms te makkelijk.
Onbekende taal en ik begin wat te gokken voor een functie, autocomplete komt met een suggestie die mij wel goed lijkt dus gebruik ik die.

Tja, omdat je lui bent (en welke programmeur is dat nu niet) gebruik je autocomplete als hulp functie. En dat is dus niet waar het voor bedoeld is, het is puur om je productiviteite te verhogen (en de kans op RSI te verlagen).

Verwijderd schreef op vrijdag 07 november 2008 @ 10:48:

offtopic:
PHP begint er steeds meer op te lijken En is natuurlijk immens populair...

Bij beginners en kleine webdesignerbureau's. Ik ben nog geen enkel groot project zelf tegengekomen waar ze PHP gebruiken. Maar een van onze klanten gebruikt PHP, en die maakt echt kleine sites voor kleine gebruikers.

[ Voor 28% gewijzigd door Hydra op 07-11-2008 10:50 ]

[Zoijar]

Verwijderd schreef op vrijdag 07 november 2008 @ 10:48:
Wiskunde is zeker belangrijk bij het programmeren, hoewel ik 'nuttig' een beter woord vind. Naar mate je steeds verder komt met 'het programmeren op zich', merk je het pas. Ik weet nog hoe ik vroeger sceptisch was over wiskunde en of je het nodig zou hebben. Ben nu blij, dat ik vroeger wel eens opgelet heb!

Ligt er heel erg aan wat je doet. Als je gewoon websites of office applicaties maakt dan heb je het eigenlijk geheel niet nodig. Pas bij applicaties in ingewikkelde gebieden heb je het echt nodig, en dan kan je ook niet zonder. Maar ik denk dat een heel groot deel van de programmeurs nooit wiskunde nodig heeft. Tenzij je optellen als wiskunde rekent...

[D-Raven]

Hydra schreef op vrijdag 07 november 2008 @ 10:48:
[...]


Tja, omdat je lui bent (en welke programmeur is dat nu niet) gebruik je autocomplete als hulp functie. En dat is dus niet waar het voor bedoeld is, het is puur om je productiviteite te verhogen (en de kans op RSI te verlagen).

Ben ik het niet mee eens. Als je de complete property en method list van een object opvraagt via autocomplete, waar is dan het verschil met een manual page ? Helemaal als je bij elk element in de lijst de comments erbij ziet.

[Hydra]

D-Raven schreef op vrijdag 07 november 2008 @ 11:26:
Ben ik het niet mee eens. Als je de complete property en method list van een object opvraagt via autocomplete, waar is dan het verschil met een manual page ? Helemaal als je bij elk element in de lijst de comments erbij ziet.

Ik reageerde op iemand die autocompletion gebruikt om functies te gokken, had het niet over functieargumenten e.d. Als het op de volgorde daarvan aankomt gebruik ik ook autocompletion als 'documentatie', maar niet voor dingen waarvan ik niet weet hoe ze werken. Over het algemeen zit in een API reference een stuk meer informatie m.b.t. hoe je bepaalde zaken gebruikt dan in het commentaar dat je van IntelliSense bijvoorbeeld voorgeschoteld krijgt.

[!null]

Je moet natuurlijk wel een deel van de functies uit je hoofd weten, maar vaak ga ik de mist in bij datum en string functies (verschillen toch vaak per taal). Ik doe altijd wel m'n best om dingen snel op te kunnen zoeken. Bij PHP bjivoorbeeld, een editor als PHP Expert Editor waar je code completion hebt inclusief parameters (dan valt er weinig meer op te zoeken). En in Firefox zo'n PHP zoekextensie om snel op php.net naar de juiste pagina te gaan. (niet dat php.net/... veel moeite is, maar dit werkt toch sneller)

Met andere talen, zoals Delphi bijvoorbeeld, dat je een volledige IDE voor je neus hebt heb je altijd wel code completion met vermelding van de parameters. Als je het dan nog niet weet heb je toch wel een goeie help file onder je F1 zitten.

[ Voor 19% gewijzigd door !null op 07-11-2008 11:48 ]

[.oisyn]

Hydra schreef op vrijdag 07 november 2008 @ 11:34:
[...]


Ik reageerde op iemand die autocompletion gebruikt om functies te gokken, had het niet over functieargumenten e.d. Als het op de volgorde daarvan aankomt gebruik ik ook autocompletion als 'documentatie', maar niet voor dingen waarvan ik niet weet hoe ze werken. Over het algemeen zit in een API reference een stuk meer informatie m.b.t. hoe je bepaalde zaken gebruikt dan in het commentaar dat je van IntelliSense bijvoorbeeld voorgeschoteld krijgt.

Exact. De documentatie bij van autocompletion gebruik je om snel even te kijken hoe je die functie ook alweer moest aanroepen. De keuze om die functie te gebruiken heb je dan al gemaakt, en weet je dus al wat ie doet. Als je niet weet welke functie je moet aanroepen of wat z'n gedrag is mbt bepaalde parameters, dan zul je toch echt de echte documentatie in moeten.

[Verwijderd]

Ik vraag me zelf ook vaak af hoe veel je nou uit je hoeft moet weten... Ik heb net 'geleerd' hoe je een venster moet maken met windows.h(C++). Kan iemand mij vertellen of het snappen hoe het werkt voldoende is of zou je ook gewoon uit je hoofd al die code moeten kunnen typen?

[!null]

De werking en het principe is veel belangrijker dan het exact weten van de code. Echter wil je straks een beetje productief zijn moet je wel het e.e.a. uit je hoofd weten natuurlijk. Beetje een gulden middenweg dus.

[Hydra]

Verwijderd schreef op vrijdag 07 november 2008 @ 14:15:
Ik vraag me zelf ook vaak af hoe veel je nou uit je hoeft moet weten... Ik heb net 'geleerd' hoe je een venster moet maken met windows.h(C++). Kan iemand mij vertellen of het snappen hoe het werkt voldoende is of zou je ook gewoon uit je hoofd al die code moeten kunnen typen?

Het is IMHO onmogelijk alles uit je hoofd te leren. De meest gangbare zaken, zoals veelgebruikte collections e.d., leer je vanzelf wel uit je hoofd omdat je ze gewoon veel gebruikt.

[EfBe]

Wat ik niet onthoud zoek ik op wanneer ik het nodig heb. Al doende onthoud je meer details van tools (== talen, IDE's, platforms, frameworks, libraries, controls etc. ) en bv ook quircks en dingen die undocumented zijn en bv fout gaan wanneer je ABC doet ipv XYZ. dat kost gewoon tijd en na een tijdje heb je een redelijke set van dit soort 'kennis'. Volstrekt vervangbaar overigens, want vervang je een tool voor een andere, dan zul je veelal weer bijna van voor af aan moeten beginnen qua details.

Deze details hebben overigens niets te maken met software engineering kennis, wat ik meer 'kunde' zou willen noemen. Beheers je die niet, dan wordt het toch een lang verhaal en zul je van tutorial naar example strompelen.

[Gomez12]

Verwijderd schreef op vrijdag 07 november 2008 @ 14:15:
Ik vraag me zelf ook vaak af hoe veel je nou uit je hoeft moet weten... Ik heb net 'geleerd' hoe je een venster moet maken met windows.h(C++). Kan iemand mij vertellen of het snappen hoe het werkt voldoende is of zou je ook gewoon uit je hoofd al die code moeten kunnen typen?

Simpel gezegd biedt uit je hoofd leren geen voordeel als je daarna hetzelfde venster in een andere taal moet maken, de exacte syntax is altijd anders in een andere taal.

Als jij snapt/weet dat je alleen winforms element x moet aanroepen dan kan dit behulpzaam in een volgende taal ( omdat je alleen maar in de documentatie hoeft op te zoeken hoe je van winforms functie x aanroept ).

Een gemiddelde documentatie bevat geen vertaling van syntax in C++ naar taal x, maar over het algemeen wel een stukje over hoe je de winforms collectie aanspreekt...

[osorkon!]

In het begin zal je idd veel opzoeken op php.net enzo (ook got ), en veel de autocompletion doorzoeken om een bepaalde functie te vinden. Maar naarmate de tijd voorbij gaat leer je dit vanzelf vanbuiten en wordt het een automatisme. Je zal minder en minder de docs moeten doorzoeken en gewoon weten wat te gebruiken. Zeker bij php leer je alles zeer vlug