Reacties

Answer

Een goede coder is als een goede poolspeler.

Als je een professionele poolspeler ziet, ben je in eerste instantie misschien niet onder de indruk: “Natuurlijk, ze hebben alle ballen erin, maar ze hadden alleen gemakkelijke schoten!” Dit komt omdat, wanneer een poolspeler haar slag maakt, ze niet bedenkt welke bal in welke pocket zal gaan, maar ze denkt ook aan waar de speelbal terecht zal komen . Voor het voorbereiden van de volgende opname is een enorme vaardigheid en oefening nodig, maar het betekent ook dat het er gemakkelijk uitziet.

Nu deze metafoor naar code wordt gebracht, een goede coder schrijft code die eruitziet alsof het gemakkelijk en ongecompliceerd was om te doen . Veel van de voorbeelden van Brian Kernighan in zijn boeken volgen dit patroon. Een deel van de “truc” is het bedenken van een juiste conceptualisering van het probleem en zijn oplossing . Als we een probleem niet goed genoeg begrijpen, is de kans groter dat we onze oplossingen te gecompliceerd maken en zullen we geen verenigende ideeën zien.

Met een goede conceptualisering van het probleem krijgt u alles anders: leesbaarheid, onderhoudbaarheid, efficiëntie en correctheid. Omdat de oplossing zo eenvoudig lijkt, zullen er waarschijnlijk minder opmerkingen zijn, omdat extra uitleg niet nodig is. Een goede codeur kan ook de langetermijnvisie van het product zien en zijn conceptualisaties dienovereenkomstig vormen.

Opmerkingen

  • " een goede coder schrijft code die eruitziet alsof het gemakkelijk en duidelijk was om te doen. " < < PRECIES! Ik denk dat dit komt omdat mensen meestal denken dat een goede coder iemand is die zeer " slimme " hacks kan schrijven. Als de code schoon is en niet overdreven " slim ", moet het gemakkelijk zijn, toch?
  • Mijn 2 cent: wanneer je ' een taal hebt met EASY automatische refactorings – Java en C # zijn de twee voorbeelden die ik het beste ken – het ' s gemakkelijk iteratief naar goede code te verplaatsen. Anders moet je in de eerste plaats een goed beeld krijgen, maar daar is een soort kippenei-probleem.
  • Sommige algoritmen zijn intrinsiek complex. Een goede coder zou er geen probleem mee moeten hebben om ze te schrijven wanneer ze echt nodig zijn – en ze zo leesbaar mogelijk te houden.
  • @hasenj: ja, dit komt door dit lemma: domme mensen schrijven code die de compiler begrijpt. Slimme mensen schrijven code die domme mensen begrijpen.

Antwoord

WTF

s per minuut

( origineel )

BEWERKEN: het basisidee is dat codekwaliteit niet in regels kan worden omgezet, net zoals je goede kunst of goede poëzie niet in regels kunt zetten, zodat je een computer kunt laten zeggen ja, goede kunst “of” Nee, slechte poëzie “. Momenteel is de enige manier om te zien hoe gemakkelijk de code te begrijpen is voor andere mensen.

Reacties

  • We hebben dit op het werk op ons whiteboard geplakt: -)
  • @Cape Cod Gunny Was in an Uncle Bob ' s boek ook
  • Behalve dat het een geweldige tekenfilm is, denk ik dat het echt komt ter zake – goede code is code die andere mensen prettig vinden om te lezen en te onderhouden.
  • Het is dus waar, goede code is elke code die niet slecht is. Het is bijvoorbeeld moeilijk om goede code te definiëren, het is gemakkelijker om slechte code te definiëren.
  • Meestal vind ik die " WTF? " ' s in de goede codevergadering worden kort gevolgd door " Oooooh Oké … ik zie wat je hebt gedaan."

Antwoord

Er zijn echt geen goede criteria anders dan hoe snel je de code kunt begrijpen. U laat uw code er goed uitzien door het perfecte compromis te vinden tussen beknoptheid en leesbaarheid.

De “WTF” s per minuut “(hierboven) is waar, maar het is slechts een uitvloeisel van de meer algemene regel. Hoe meer WTFs, hoe langzamer het begrip.

Opmerkingen

  • @rmx: definieer " het werk doet nou "
  • Nou, dat de RemoveCustomer methode eigenlijk de cutomer verwijdert zonder te verknoeien. Je kunt er uren aan besteden om het er mooi uit te laten zien, maar dat betekent niet dat het echt werkt. ' Hoe snel u code kunt begrijpen ' is niet het enige criterium voor ' goede code ' is wat ik ' m zeg.
  • @rmx: maar bugvrij zijn impliceert, isn ' niet? Als uw code ' het werk niet goed doet, ' is (nog) geen code.
  • @ rmx: in feite nee. Als uw code gemakkelijk te begrijpen is, dan is het ' gemakkelijk te begrijpen als het het ' werk slecht doet. OTOH, als het ' moeilijk te begrijpen is, is het ' moeilijk te begrijpen als het het doet ' s helemaal niet.
  • @rmx: PS Simpel gezegd, uw decrement () is een klassieke WTF en vertraagt dus het begrip van delen van de code waar deze functie wordt gebruikt

Answer

Je weet dat je goede code schrijft als …

  1. De klant is blij
  2. Collegas lenen je code als uitgangspunt
  3. De kersverse gast / meid werd zojuist verteld om wijzigingen aan te brengen in een systeem dat je 6 maanden geleden hebt gebouwd en hij / zij heeft je nooit een vraag gesteld
  4. Je baas vraagt je om nieuwe widgets te ontwikkelen voor het te gebruiken team
  5. Je kijkt naar de code die je vandaag schrijft en zegt tegen jezelf: “Ik wou dat ik twee jaar geleden code op deze manier had geschreven”

Hoe gaat het meet of de code goed is …

  • Wat is de reactietijd?
  • Hoeveel retourvluchten naar de server maakt het?
  • Zou je de applicatie persoonlijk gebruiken of vind je het onhandig?
  • Zou je het de volgende keer op dezelfde manier bouwen?

Goede code werkt als het het is de bedoeling dat. Goede code kan eenvoudig worden gewijzigd wanneer dat nodig is. Goede code kan worden hergebruikt om winst te maken.

Opmerkingen

  • " De klant is tevreden " is hier orthogonaal op.
  • @TRA – Als de klant tevreden is, betekent dit dat u de vereisten begreep en een oplossing bood die zij verwachtten.
  • zeker, maar slechte code kan hetzelfde doen.

Antwoord

Een code die is

  1. bugvrij

  2. herbruikbaar

  3. onafhankelijk

  4. minder complex

  5. goed gedocumenteerd

  6. gemakkelijk te wijzigen

wordt goede code genoemd.

Een goed programma werkt foutloos en bevat geen bugs. Maar welke interne kwaliteiten produceren zon perfectie ?. Het is geen mysterie, we hebben af en toe een herinnering nodig. Of je nu codeert in C / C ++, C #, Java, Basic, Perl, COBOL of ASM, alle goede programmering vertoont dezelfde aloude kwaliteiten: eenvoud, leesbaarheid, modulariteit , gelaagdheid, ontwerp, efficiëntie, elegantie en helderheid, efficiëntie, elegantie en helderheid

Bron: MSDN

Opmerkingen

  • Eenvoud, leesbaarheid, elegantie en duidelijkheid zijn allemaal hetzelfde. Modulariteit en gelaagdheid zijn slechts methoden om uw code duidelijk te maken en elegant. Het enige dat dan nog in de lijst staat, is efficiëntie, wat een beetje geïmpliceerd is, en bovendien is het vaak een kwestie van compromissen sluiten tussen efficiëntie en duidelijkheid.
  • Controleer dit: goo.gl/hdQt8
  • Code mag geen fouten bevatten?
  • Nee, het kan ' t. (Praktisch)
  • Efficiënt zou aan je lijst moeten worden toegevoegd. Snelheid is niet ' t nodig is eigenlijk een primaire indicator van goede code, maar goede code mag niet ' niet onnodig traag of verkwistend zijn.

Antwoord

Komt dit u bekend voor?

Philips gaf me de kans om het ontwerp van een nieuw product te bekijken. Naarmate het zich ontwikkelde, werd ik steeds ongemakkelijker en begon ik mijn zorgen aan mijn supervisor te vertellen. Ik heb hem herhaaldelijk gezegd dat de ontwerpen niet schoon waren en dat ze mooi moesten zijn zoals Dijkstras ontwerpen mooi waren. Hij vond dit geen bruikbare opmerking.Hij herinnerde me eraan dat we ingenieurs waren, geen kunstenaars. In gedachten drukte ik gewoon mijn smaak uit en hij wilde weten welk criterium ik gebruikte om mijn oordeel te vellen. Ik kon het hem niet vertellen! Omdat ik niet kon uitleggen welke principes werden geschonden, werden mijn opmerkingen eenvoudigweg genegeerd en ging het werk door. Omdat ik voelde dat er een manier moest zijn om mijn “smaak” uit te leggen en te motiveren, begon ik een principe te vinden dat goede ontwerpen van slechte onderscheidt. Ingenieurs zijn erg pragmatisch; ze kunnen schoonheid bewonderen, maar ze zoeken nut. Ik heb geprobeerd een verklaring te vinden waarom “schoonheid” nuttig was.

Bekijk de rest hier .

Reacties

  • Aangezien de link in het bericht van @mlvljr ' s bericht is verbroken , hier is een link naar de pagina van Google Boeken: books.google.co.in/…
  • @balajeerc Bedankt (ik heb ook de link gerepareerd, zodat deze verwijst naar een door Springer gehoste versie van dezelfde pdf) 🙂

Antwoord

afgezien van natuurlijke code kwaliteitscriteria (minimaal kopiëren / plakken, geen spaghetti, etc.) moet een goede industriële code er altijd een beetje naïef uitzien, een beetje te uitgebreid, zoals 

int key = i; const bool do_not_create = false; Record r = cache.get(key, do_not_create); ++i;

in tegenstelling tot 

Record r = cache.get(i++, false);

Reacties

  • Maar betekent do_not_create = false “geef false door als het do_not_create -argument zodat het zal worden aangemaakt ”of“ pas s false als het do_create -argument, zodat het niet wordt aangemaakt “? In een taal waarin je argumentnamen kunt gebruiken, zou ik de voorkeur geven aan cache.get (key:i, create: false); i += 1;.

Antwoord

Misschien zou een antwoord door het tegenovergestelde te illustreren helpen (plus het” is een excuus om XKCD hier te krijgen).

alt-tekst

Goede code is

  • eenvoudig te begrijpen,
  • gemakkelijk te onderhouden ,
  • probeert niet alle problemen op te lossen, alleen het probleem dat voorhanden is.
  • leeft lang voort zonder de ontwikkelaars naar alternatieven te laten zoeken

Voorbeelden zijn:

  • Apache Commons
  • Spring-framework
  • Hibernate-framework

Antwoord

Ik “ga gewoon met” onderhoudbaar “

Alle code moet worden onderhouden: het is niet nodig om die taak moeilijker te maken dan nodig is

Als een lezer deze eenvoudige vereiste niet begrijpt of het duidelijk moet maken, dan zou die lezer geen code moeten schrijven …

Antwoord

Goede code zal voor elke persoon anders zijn en de taal waarmee ze werken heeft ook invloed op wat zou kunnen worden overwogen om een goede code te zijn. Als ik een project benader, kijk ik meestal naar de volgende dingen:

  • Hoe is het project georganiseerd? Zijn de bronbestanden netjes georganiseerd en kan ik code vinden zonder al te veel moeite?
  • Hoe is de code georganiseerd? Is duidelijk gedocumenteerd wat de code in het bestand doet, zoals door het gebruik van een bestandsheader, of door het gebruik van elke klasse die in zijn eigen bestand zit? Zijn er functies in het bestand die niet langer in de applicatie worden gebruikt?
  • Hoe zijn de functies georganiseerd? Is er een duidelijk patroon waarin variabelen worden gedeclareerd, of is het een redelijk willekeurig patroon? Heeft de code een logische flow en worden onnodige controlestructuren vermeden? Is alles duidelijk gedocumenteerd, waarbij code zelfdocumenterend is waar nodig en commentaren duidelijk het waarom en / of hoe van wat de code doet weergeven?

Afgezien van dit alles, is het ontwerp van de toepassing als geheel zinvol? De code in de applicatie kan de beste ter wereld zijn, maar het kan nog steeds lastig zijn om mee te werken als het algehele ontwerp van de applicatie niet klopt.

Antwoord

Laat me het vriendelijk oneens zijn over de leesbaarheid. Nee, niet helemaal: goede code moet leesbaar zijn, en dat kan met voldoende commentaar eenvoudig worden bereikt.

Maar ik beschouw twee soorten WTF: die waarbij je je afvraagt of de programmeur verder is gekomen dan programmeren 101, en die waarbij je de genialiteit van de code absoluut niet begrijpt. Sommige code kan er heel vreemd uitzien ten eerste, maar is eigenlijk een zeer inventieve oplossing voor een moeilijk probleem. De tweede zou niet moeten tellen in de WTF-meter, en kan worden vermeden door commentaar.

Zeer leesbare code kan heel, heel langzaam zijn . Een minder leesbare oplossing kan een veelvoudige verbetering van de snelheid opleveren. R is een geweldig voorbeeld van een taal waar dat vaak waar is. Men vermijdt daar zo veel mogelijk for-loops.Over het algemeen zou ik de snelste code als de betere code beschouwen, ook al is deze minder leesbaar. Dat wil zeggen, als de verbetering natuurlijk substantieel is en er voldoende commentaar wordt ingevoegd om uit te leggen wat de code doet.

Bovendien kan geheugenbeheer cruciaal zijn in veel wetenschappelijke toepassingen. Code die zeer leesbaar is, is nogal slordig in geheugengebruik: er worden gewoon meer objecten gemaakt. Slim gebruik van geheugen maakt in een aantal gevallen de code weer minder leesbaar. Maar als je bijvoorbeeld goochelt met gigabytes aan DNA-sequenties, is het geheugen een cruciale factor. Nogmaals, ik beschouw de minder geheugenintensieve code als de betere code, ongeacht de leesbaarheid.

Dus ja, leesbaarheid is belangrijk voor goede code. Ik ken het adagium van Uwe Liggis: denken doet pijn en computers zijn goedkoop. Maar in mijn vakgebied (statistische genomica) worden rekentijden van een week en geheugengebruik van meer dan 40 Gb niet als abnormaal beschouwd. Dus een verbetering van tweemaal de snelheid en de helft van het geheugen is veel meer waard dan dat extra stukje leesbaarheid.

Opmerkingen

  • Geen regel / regels zonder uitzondering
  • Ik ben het niet eens met uw meningsverschil: u zegt dat snelheid in uw veld erg belangrijk is en zegt dat het belangrijker is dan leesbaarheid. Ik ben het daar niet mee eens, je moet ernaar streven om de juiste balans te gebruiken. Als snelheid niet nodig is, bijvoorbeeld voor een interface op hoog niveau, geeft u misschien de voorkeur aan iets dat gemakkelijk te onderhouden is, als snelheid nodig is, dan ben ik het met u eens. In plaats van harde regels is het beter om gezond verstand te gebruiken en je moet sowieso voortijdige optimalisatie vermijden.
  • @BlueTrin Waarom compileren niet allebei die uitstekende broncodez, en documenteren ook de hel van wat ' is daar gaande (daar in reacties)?

Antwoord

Voor zover het voor mij geldt … ik weet dat ik goede code schrijf wanneer een collega die wel aan een ander project werkt, langskomt en in staat is om in te springen en te begrijpen wat ik aan het doen ben zonder dat ik elk blok doorloop code en laat zien wat het doet.
In plaats van dat hij zegt: “Wacht even, wat ?!” Hij zegt: “Oh, oké, ik zie wat je daar hebt gedaan.”

Goede code heeft ook “niet veel stiekeme tijdelijke oplossingen of” hacks “. Regels wanneer je, terwijl je het schrijft, ook tegen jezelf zegt: “Ik weet dat dit geen goede manier is om het te doen, maar ik zal het voorlopig gewoon zo moeten doen. Ik zal mezelf eraan herinneren het later te verbeteren …

Antwoord

Er zijn veel kenmerken van “goede” code , maar het belangrijkste, IMHO, zijn leesbaarheid en onderhoudbaarheid.

Uw code zal bugs bevatten, zal waarschijnlijk worden uitgebreid en hergebruikt, en zou op een gegeven moment opnieuw in rekening moeten worden gebracht – zelfs als u het opnieuw bezoekt, is de kans groot dat u geen idee heeft wat u in vredesnaam moest doen doe jezelf een plezier en plaats geen belemmeringen in de weg.

Natuurlijk, gebruik dat complexe, maar uiterst efficiënte algoritme, maar zorg ervoor dat je wat extra tijd besteedt aan het documenteren ervan, maar zorg er anders voor dat je code duidelijk en consistent.

Geef een reactie

Het e-mailadres wordt niet gepubliceerd. Vereiste velden zijn gemarkeerd met *