Wat is mooie code? [gesloten]

“Schoonheid wordt gekocht door oordeel van het oog”.

Dat gezegd hebbende, denk ik dat de meeste programmeurs het ermee eens zullen zijn dat mooie code een evenwicht laat zien tussen duidelijkheid en transparantie, elegantie, efficiëntie en esthetiek.

• Duidelijkheid en transparantie : Duidelijkheid is hoe gemakkelijk een lezer kan afleiden wat de code doet. Transparante code doet wat het lijkt te doen. Als code één ding lijkt te doen, maar eigenlijk iets anders doet (of iets meer), is het niet transparant – het is misleidend.

• Elegantie : er zijn veel manieren om de meeste algoritmen te implementeren, maar sommige manieren zijn onhandig, terwijl andere manieren netjes en gracieus zijn. Beknoptheid voegt vaak elegantie toe, maar overdreven beknoptheid kan de duidelijkheid verminderen.

• Efficiëntie : vermijden van onnodig gebruik van bronnen (zoals CPU-tijd, geheugen en I / O).

• Esthetiek : prettig voor de ogen. Dit is nogal subjectief. Het komt vooral neer op stijl. Een belangrijke overweging is om een consistente stijl te hebben. Code die bijvoorbeeld halverwege de stijl van inspringen verandert, is lelijk.

Reacties

• een mooie uitleg, +1
• Ik zou " Efficiëntie " eruit halen. Hoewel het in strikte zin positief is, kan het opnemen in de lijst op zijn best misleidend zijn. Het is normaal gesproken een bijproduct van de andere en zou een secundaire zorg moeten zijn op het moment van codering. De belangrijkste reden is dat het zich voor het grootste deel pas manifesteert nadat de compiler zijn duistere magie heeft gewerkt.
• @Jubbat Inderdaad – soms leidt de meest efficiënte oplossing in feite tot erg lelijke code. (Bijv. De klassieke Fast Inverse Square Root-functie)
• @DarrelHoffman Juist, hoewel dat compromis ook waar is voor meer variabelen die goede code definiëren, niet alleen efficiëntie en de rest (er is een goede, lange uitleg van in " Code compleet " – helaas kan ik ' niet onthouden in welke sectie van de boek, waarschijnlijk aan het begin -)
• @Jubbat: ik ben het ermee eens dat efficiëntie meestal een secundaire zorg is, maar ik denk nog steeds dat het een rol speelt in de schoonheidsvergelijking.

Laat mensen je niet voor de gek houden door te denken dat mooie code de volgende is:

• slimme algoritmen
• stiekeme taalkenmerken
• een probleem oplossen met zo min mogelijk toetsaanslagen

Omdat het dat niet is. Zulke code is schattig , en het is zeker een blik waard, maar het is niet het soort code waarmee je tot rust wilt komen.

En je kent dat fraaie recursieve meta-templated statische polymorfisme dat verschillende lambdas erft – of waar je ook online over hebt gelezen? Misschien wil je graag op innovatieve en handige trucs springen zonder een duidelijke reden om ze te gebruiken. Maar code die de grenzen van een taal verlegt, is ook niet mooi.

Ze zijn sexy .
Veel plezier, maar stel jezelf de volgende vraag: wil ik echt tijd besteden aan het verkennen van de anatomie van deze taal, of wil ik samenwerken met een taal en iets moois opbouwen? Een programmeertaal is immers slechts het hulpmiddel om te creëren.

Wat is dan mooie code?

Mooie code = onderhoudbare code. DAT “IS HET!
DAT” IS DE FORMULE !

Als je iets kunt schrijven, er een paar maanden later op terugkomt en er vooruitgang mee blijft boeken, dan is dat prachtig. Als je een jaar later beseft dat je ook functionaliteit wilt toevoegen als tweak een bestaande functie, en je slaagt erin om het relatief gemakkelijk te doen, dan DAT “S mooi. Als andere mensen in uw codebase kunnen stappen en snel kunnen achterhalen wat er aan de hand is omdat de dingen georganiseerd zijn, zullen ze meer haar hebben en ook mooi zijn.

Dus de echte vraag die u wilt stellen is : “Hoe schrijf ik meer onderhoudbare code?”. Ik ben bang dat dat een grotere vraag is en dat het een behoorlijk creatieve discipline is. Blijf gewoon code schrijven, maar vraag jezelf deze keer niet af of het mooier kan zijn. Vraag uzelf af of u het onderhoudbaarder kunt maken.

Opmerkingen

• om de problemen die u naar voren brengt te bestrijden is er ook het advies aan c2.com/cgi/wiki?KillYourDarlings

Mijn mening hierover is dat “Beautiful Code” geen objectieve of bijzonder nuttige term is. En we moeten het niet proberen te definiëren.

Typische woordenboekdefinities van het Engelse woord “schoonheid” gaan als volgt:

• “1. de combinatie van alle de kwaliteiten van een persoon of ding die de zintuigen prikkelen en de geest behagen “
• ” 1. de kwaliteit die aanwezig is in een persoon of ding dat intens esthetisch plezier of diepe bevrediging geeft aan de geest of de zintuigen. ”
• “1. De kwaliteit die plezier geeft aan de geest of de zintuigen en wordt geassocieerd met eigenschappen als harmonie van vorm of kleur, voortreffelijkheid van kunstenaarschap, waarachtigheid en originaliteit.”

(Bron http://dictionary.com )

De rode draad is dat “schoonheid” gaat over wat esthetisch aantrekkelijk is. Dat is noodzakelijkerwijs subjectief … zoals geïllustreerd door het gezegde “Schoonheid is in de ogen van de toeschouwer”.

We kunnen het woord “schoonheid” toepassen op code , en de voor de hand liggende betekenis is dat de code “esthetisch aangenaam” is.

Maar om dan te zeggen dat “mooie code” een bepaalde set attributen heeft (zoals gesuggereerd door andere Answers) is in tegenspraak met de duidelijke betekenis van esthetisch. Esthetiek gaat over hoe mensen … individuele mensen … dingen waarnemen.

Of om te zeggen Op een andere manier is er iets weerzinwekkend aan iemand die me vertelt wat ik mooi zou moeten vinden, of het nu gaat om mensen, kunstwerken of … code.

Wat betreft wat mij betreft mooie code is code die ik mooi vind, en dat is het dan. Het is subjectief en individueel, en laten we het daar maar bij laten.

Hier is mijn advies.

Bekijk de antwoorden op Hoe kun je " mooie code " uitleggen aan een niet-programmeur? en kijk op welke kenmerken hij zich moet concentreren. Pak dan een boek als Code Complete op en lees het door voor advies over hoe je betere code kunt schrijven.

Op een gegeven moment zal het je raken als je naar oudere code van je kijkt , “Dit is lelijk.” Het zal een directe esthetische reactie zijn. En als je ernaar kijkt, zul je je realiseren dat je je code bekijkt als een programmeur, en de lelijkheid kunt zien omdat je weet hoe beter uitziende code eruit zou moeten zien.

Alleen omdat je vaak over mooie code leest, betekent niet dat mensen die erover schrijven dezelfde definitie hebben. Helaas lijkt het erop dat ze, te oordelen naar je vraag, niet eens de moeite namen om definieer het in de eerste plaats.

Voor mij is mooie code:

• Expressief
• Beknopt

Beknopte code die niet expressief is, kan cryptisch zijn, en expressieve code die niet beknopt is, is vaak opgeblazen en vervelend om te lezen, dus je hebt beide nodig.

Ik zou onderhoudbaarheid niet opnemen als onderdeel van wat code maakt mooi, want schoonheid is iets dat je ziet / leest, niet iets waar je naar handelt. Maar nogmaals, het is mijn persoonlijke mening.

De term mooie code is een erg vage en abstracte term. Het is gemakkelijk om erachter te komen wat het vertegenwoordigt en wat het betekent, maar het mag nooit worden gezien als meer dan een secundair doel.

Het doet me veel denken aan de statistiek voor codedekking. Als je het aantal hoog genoeg hebt, kun je ontspannen en naar iets anders gaan. Een codebase hebben met ongeveer 80% dekking is geweldig, niet kogelvrij, maar genoeg om te chillen en andere dingen te doen. Een dekking van 40% hebben is behoorlijk eng en zou je moeten aanmoedigen om dat aantal te verhogen.

Het punt is alleen dat codedekking alleen echt zinvol is als het aantal laag is. Dus laat het niet laag zijn. Als de dekking tot een bepaald punt stijgt, ga dan verder met iets anders.

Evenzo mooie code is geweldig. Als je mooie code hebt, ga dan verder met iets anders. Maak er niet te veel stress over. U zult nooit dat 100% -cijfer halen, en als u dat wel doet, zult u merken dat u zich te veel heeft gericht op wat het leest, of hoe het eruit ziet, en niet genoeg op wat het doet, of hoe het het doet. Dus ga naar een redelijk punt en stop dan.

Maar als je code fugly is, als het een gigantische ingewikkelde puinhoop van spaghetticode is, als het je fysiek pijn doet om het bestand te openen, als je geen opmerkingen hebt of documentatie etc etc etc, repareer het dan. En doe het zo snel mogelijk.

U zult na verloop van tijd merken dat uw codebasis over het algemeen schoner, over het algemeen helderder en over het algemeen mooier en, nog belangrijker, bruikbaarder wordt als u zich concentreert op het minder fugly maken. Het schrijven van mooie code is geen eenstapsproces.

Er is geen magische filosofie. De 1000 kleinere stappen die allemaal samen worden gedaan, die allemaal een concreet doel dienen dat niets te maken heeft met hoe mooi de code eruitziet. Maar als je serveren ze allemaal samen, ze vormen prachtige code als de som der delen. Zoals voltron. Of kapitein planeet.

Ik ben het echt eens met de antwoorden hier, maar als ik een minder technische benadering neem, zou ik zeggen dat mooie code een uitdrukking is van de “helderheid van het denken over het probleem bij de hand die zich manifesteert door middel van een goed geformuleerde en precieze maar toch eenvoudige taal.

Voor mij is door mooie code kijken net als naar een kunstwerk kijken, steeds nieuwe details zien die de maker intentie, maar ook hoe de verschillende onderdelen werden gerealiseerd, die elk een antwoord gaven op zoveel vragen, en dan, ten slotte, hoe het bestaan ervan aanvoelt als een natuurwet waarop alles op één lijn ligt, zodat het alleen kan worden beschreven met woorden van ontzag: magnifiek , inspirerend, mooi.

Dus vanuit dat perspectief zou je in je carrière als programmeur ontdekkingen kunnen doen van mooie code die anderen misschien niet begrijpen omdat ze de kennis niet hebben of misschien niet opmerkelijk meer vinden omdat ze verwend zijn door te veel schoonheid;)

Mooie code heeft alle pragmatische kwaliteiten zoals anders vermeld, daar ben ik het helemaal mee eens.

Ik heb drie criteria:

• Eenvoudig: Het moet tenminste door mensen gelezen kunnen worden. Je kunt bijvoorbeeld een code schrijven die werkt bij O (1) voor een oplossing met tonnen regels, maar ik geef de voorkeur aan code die werkt met 0 (n) -oplossingen met weinig regels. Dit kan veranderen voor extreme situaties, maar voor het begin is eenvoud belangrijk.
• Herbruikbaar: Code moet herbruikbaar, maar niet overschreven. Als u een bewerking nodig heeft, moet u deze definiëren zoals u deze jaren later kunt gebruiken.
• Inspringing: Misschien is dit geen probleem voor jou, maar voor beginners is dit het eerste dat moet worden opgelost.