Net zoals in spreektaal heb je allerlei dialecten. Het is maar wat je gewend bent en waar je vandaan komt. Indien je je bedient van ABN dan is de kans groot / groter dat je overal direct wordt verstaan.
Ik zeg niet dat je altijd ABN zou moeten gebruiken (dit beweer ik ook nergens) maar ik vind het wel heel erg belangrijk dat communicatie altijd zo goed en makkelijk mogelijk verloopt. En daarmee heb je doorgaans het meeste succes wanneer je ABN gebruikt.
Heb je je eigen knutselproject: leef je uit. Maar ben je met iets groters bezig en werk je hier met anderen aan of communiceer je hier met anderen over, dan is het wel zo beleefd om zoveel mogelijk een algemeen geaccepteerde spreektaal (of programmeerwijze) te hanteren. Niemand heeft zin om rare constructies te ontcijferen en meestal hield dat al in dat de aanpak gewoon verkeerd was.
Zo had ik een buitenlandse collega in een vorige baan. Deze kerel had zijn inburgeringscursus met de hakken over de sloot gehaald en ging er zelf nogal prat op dat hij dit met enige handigheid voor elkaar had gekregen door bij het theoretische deel (het was een multiple choice toets) slim te gokken. Het praktijkdeel was nogal desastreus. Desalniettemin was hij geslaagd... maar sprak eigenlijk geen woord Nederlands.
Dit was verder ook helemaal niet erg, want wij communiceerden gewoon in het Engels en dat ging prima. Totdat ons bedrijf werd ingelijfd bij een ander bedrijf waarbij uitsluitend in het Nederlands werd gecommuniceerd. Ik heb de reden voor deze "regel" nooit kunnen achterhalen, waarschijnlijk was het ook echt nergens op gebaseerd en was het gewoon breinloze, stompzinnige kortzichtigheid. Maar goed, dit werkte dus averechts.
Het kan nooit de bedoeling zijn dat je een methode voorop stelt om een doel te behalen en dit doe ik ook niet. Het gaat erom dat de methode zorgt voor minimale weerstand bij het bereiken van het doel, of in ieder geval het zo dicht mogelijk in de buurt komen hiervan.
Geloof het of niet, maar hier zijn standaarden (mede) voor bedoeld.
Thomas, het is prima om standaarden/conventies te volgen.
Wat ik als toevoeging probeer aan te geven, is dat standaarden zinvol zijn om te volgen, maar dat het geen harde regels zijn. Vaak worden hier op het forum zaken als regels/verplichtingen gepresenteerd. Voor mensen die nog niet zo heel lang programmeren, is dit enerzijds interessant omdat het ze in de goede richting kan sturen. Maar anderzijds geeft het de indruk dat iets op een bepaalde manier móet ... omdat het anders niet werkt. Ik probeer daar zelf wat nuance in aan te brengen.
Nu gaat het over iets realtiefs kleins/simpels als naamgeving, maar dit soort discussies heb ik ook veelvuldig voorbij zien komen over de implementatie van een MVC-systeem, waarbij conventies werden gepresenteerd als keiharde regels die gevolgd móeten worden.
Dus, ja ... standaarden/conventies zijn super nuttig, maar er mag als daar behoefte is ook van worden afgeweken.
Programmeren is een beetje als het schrijven van een boek. Zet 10 mensen naast elkaar en ze zullen een bestaand verhaal allemaal op een andere manier opschrijven. En daar kunnen dan meerdere heel goede boeken uit voortvloeien.
Programmeren is een beetje als het schrijven van een boek. Zet 10 mensen naast elkaar en ze zullen een bestaand verhaal allemaal op een andere manier opschrijven. En daar kunnen dan meerdere heel goede boeken uit voortvloeien.
Syntaxisstandaarden zijn vergelijkbaar met spellingregels: schrijf gerust je eigen verhaal, maar begin een zin bij voorkeur met een hoofdletter.
Bedenk dat coding standards mede zijn bedoeld om discussie over dit soort beslissingen te voorkomen, daar zo min mogelijk over te hoeven nadenken en er geen tijd aan te hoeven verspillen.
Bedenk dat coding standards mede zijn bedoeld om discussie over dit soort beslissingen te voorkomen, daar zo min mogelijk over te hoeven nadenken en er geen tijd aan te hoeven verspillen.
Wat ik als toevoeging probeer aan te geven, is dat standaarden zinvol zijn om te volgen, maar dat het geen harde regels zijn.
Okay kapitein Barbossa. Ben het hier overigens mee eens, maar... (zie vervolg)
Ozzie PHP op 30/08/2020 21:55:48
móet
Niets moet, maar als je geen beter idee hebt kun je net zo goed een werkwijze of voorstel volgen. Als de enige motivatie "dwarsliggen" is zou je je ook kunnen afvragen waarom iemand vragen stelt terwijl deze persoon het beter denkt te weten. Dan is er iets anders aan de hand lijkt mij, en dat kan alleen door de persoon in kwestie zelf opgelost worden, mits je een optimistische kijk op de wereld hebt.
Ozzie PHP op 30/08/2020 21:55:48
Nu gaat het over iets realtiefs kleins/simpels als naamgeving, maar dit soort discussies heb ik ook veelvuldig voorbij zien komen over de implementatie van een MVC-systeem, waarbij conventies werden gepresenteerd als keiharde regels die gevolgd móeten worden.
Ik denk niet dat je dit echt kunt vergelijken met codeconventies. Ten eerste omdat het vele malen complexer is dan "simpelweg" conventies. Ten tweede omdat er op het internet een heleboel kampen bestaan die overtuigd zijn van hun eigen gelijk over hoe MVC er uit zou moeten zien (en dit probleem zit weer in hetzelfde straatje als hierboven). Dan is er al geen enkele ruimte meer mogelijk voor echte discussie of nuancering en sterker nog, dat zijn vaak simpelweg geen discussies. En ten derde omdat MVC een idee is. Eenzelfde idee kan op legio manieren geïmplementeerd worden al naar gelang de behoefte. Het laatste wat je zou moeten doen is MVC "voor de vorm" gebruiken omdat je gehoord had dat dat "de shit" was en dat je je vervolgens in allerlei bochten moet wringen om dingen voor elkaar te krijgen door de zelf opgeworpen MVC-muren. Dat is wederom de vorm voorop stellen / het paard achter de wagen spannen. En misschien moet je dat (vorm voorop stellen) bij conventies juist wel doen, het schrijft immers expliciet voor wat deze vorm -met goed beargumenteerde redenen- zou moeten zijn.
Ozzie PHP op 30/08/2020 21:55:48
Dus, ja ... standaarden/conventies zijn super nuttig, maar er mag als daar behoefte is ook van worden afgeweken.
Standaarden zijn er om van af te wijken. Waar heb ik dit eerder gehoord.
kijk, als je alleen werkt kun je dingen zo programmeren dat je er mogelijk alleen zelf chocola van kunt maken, maar indien deze wordt hergebruikt en/of wordt gedeeld, dan zal deze gewoon moeten voldoen aan een bepaalde norm.
Misschien is het enkel discussiëren over conventies in afzondering ook nogal loos zonder het bekijken van toepassingen.
Daarbij, deze "behoefte" zal gemotiveerd moeten kunnen worden. Je moet jezelf en anderen kunnen overtuigen of op zijn minst kunnen uitleggen waarom jij denkt dat de afwijking een betere keuze is dan de standaard uitvoering. Als de behoefte niets meer is dan "laten we het eens over een andere boeg gooien" of "ik heb vanavond zin in chili con carne" dan zijn de argumenten natuurlijk niet zo sterk...
Ook het argument "ik wil kunnen afwijken van de norm" an sich is niet genoeg. Er moet een zekere noodzaak (reden) zijn om dit te doen waarbij de standaard aanpak tekort schiet.
Ozzie PHP op 30/08/2020 21:55:48
Programmeren is een beetje als het schrijven van een boek. Zet 10 mensen naast elkaar en ze zullen een bestaand verhaal allemaal op een andere manier opschrijven. En daar kunnen dan meerdere heel goede boeken uit voortvloeien.
Maar zoals @Ward aangeeft: regels voor de opbouw van zinnen zullen nog steeds van toepassing zijn, anders kan niemand een touw vastknopen aan het verhaal. Dat is waar we het hier ook over hebben: de zinsopbouw, niet het verhaal. Hoe je deze bouwstenen verder tot lopende zinnen combineert en het verhaal wordt verteld is aan de auteur.
Daarover (hoe je goede verhalen zou moeten schrijven) bestaan overigens ook ideeën en best practises.
