Kommentarer
- mulig duplikat av Skriver / diskusjoner om estetikken til koden?
- Det ' er bare en talemåte. Skjønnhet ligger i betrakterens øyne, og utover det handler det ' om klarheten i instruksjonene du ' har lagt ned i en tekstfil for å løse et problem, og hvor enkelt du eller noen andre kan endre og vedlikeholde det i fremtiden. Utover det, hvor mye mer skjønnhet koden din utstråler, er helt opp til deg – fordypninger, modulstruktur, kompleksitet, effektivitet samtidig med enkel lesbarhet, navngivningskonvensjoner osv.
- Du kan være interessert i å lese Vakker kode: Ledende programmerere forklarer hvordan de tenker da!
- mulig duplikat av Hvordan kan du forklare " vakker kode " til en ikke-programmerer?
Svar
«Skjønnhet er kjøpt av øyets dom».
Når det er sagt, tror jeg de fleste programmerere er enige om at vakker kode viser en balanse mellom klarhet og gjennomsiktighet, eleganse, effektivitet og estetikk.
-
Klarhet og gjennomsiktighet : Klarhet er hvor lett en leser kan utlede hva koden gjør. Gjennomsiktig kode gjør hva den ser ut til å gjøre. Hvis kode ser ut til å gjøre en ting, men faktisk gjør noe annet (eller noe mer), er den ikke gjennomsiktig – den er misvisende.
-
Eleganse : det er mange måter å implementere de fleste algoritmer på, men noen måter er klønete mens andre måter er pene og grasiøse. Kortfattethet gir ofte eleganse, men overdreven kortfattethet kan redusere klarheten.
-
Effektivitet : unngå unødvendig bruk av ressurser (som CPU-tid, minne og I / O).
-
Estetikk : å være lett å se for øynene. Dette er ganske subjektivt. Det kommer stort sett ned på stil. En viktig faktor er å ha en konsistent stil. Kode som forandrer seg, for eksempel, innrykk stil halvveis, er stygg.
Kommentarer
- en vakker forklaring, +1
- Jeg tar " Effektivitet ". Selv om det i streng forstand er positivt, kan det i beste fall være misvisende å inkludere det i listen. Det er normalt et biprodukt av de andre, og det bør være et sekundært anliggende på kodingstidspunktet. Hovedårsaken er at den for det meste bare manifesterer seg etter at kompilatoren har arbeidet med sin mørke magi.
- @Jubbat Faktisk – noen ganger fører den mest effektive løsningen faktisk til veldig stygg kode. (F.eks. Den klassiske Fast Inverse Square Root-funksjonen)
- @DarrelHoffman Høyre, selv om dette kompromisset også gjelder ved flere variabler som definerer god kode, ikke bare effektivitet og resten (det er en god lang forklaring på dette i " Kode Fullført " – dessverre husker jeg ikke ' i hvilken del av bok, nær begynnelsen sannsynligvis-)
- @Jubbat: Jeg er enig i at effektivitet vanligvis er et sekundært anliggende, men jeg tror fremdeles at det påvirker skjønnhetsligningen.
Svar
Ikke la folk lure deg til å tro at vakker kode er følgende:
- smarte algoritmer
- snike språkfunksjoner
- løse et problem med minst mulig tastetrykk
Fordi det ikke er det. En slik kode er søt , og den er absolutt verdt et blikk, men den er ikke den typen kode du vil slå deg til ro med.
Og du vet den fancy rekursive metamalerte statiske polymorfismen som arver variatiske lambdas– eller hva det du leste om på nettet? Du kan være ivrig etter å hoppe på innovative og smarte triks uten en klar grunn til å bruke dem. Men kode som presser grensene for et språk, er ikke vakker heller.
De er sexy .
Masse moro, men spør deg selv dette: Vil jeg virkelig å bruke tid på å utforske anatomien til dette språket, eller vil jeg jobbe sammen med et språk og bygge noe vakkert? Tross alt er et programmeringsspråk bare verktøyet for å lage.
Så hva er vakker kode da?
Vakker kode = vedlikeholdbar kode. DET «ER DET!
DET» ER FORMULEN !
Hvis du kan skrive noe, kom tilbake til det noen måneder senere, og fortsett å gjøre fremskritt på det, så er det vakkert. Hvis du et år senere skjønner at du også vil legge til funksjonalitet som finjustere en eksisterende funksjon, og du klarer å gjøre det med relativt letthet, så DET er vakker. Hvis andre kan gå inn i kodebasen din og raskt finne ut hva som skjer fordi ting er organisert, vil de ha mer hår, og også være vakre.
Så det virkelige spørsmålet du vil stille er : «Hvordan skriver jeg mer vedlikeholdbar kode?». Jeg er redd for at det er et større spørsmål, og det er ganske kreativt. Bare fortsett å skrive kode, men denne gangen må du ikke spørre deg selv om det kan være vakrere. Spør deg selv om du kan gjøre det mer vedlikeholdbart.
Kommentarer
- for å bekjempe problemene du tar opp, er det også råd til c2.com/cgi/wiki?KillYourDarlings
Svar
Min oppfatning av dette er at «Beautiful Code» ikke er et objektivt eller spesielt nyttig begrep. Og vi skal ikke prøve å definere det.
Typiske ordboksdefinisjoner av det engelske ordet «beauty» går slik:
- «1. kombinasjonen av alle egenskapene til en person eller ting som gleder sansene og behager sinnet «
- » 1. kvaliteten som er tilstede i en person eller ting som gir intens estetisk glede eller dyp tilfredshet til sinnet eller sansene. »
- «1. Kvaliteten som gir glede til sinnet eller sansene og er assosiert med egenskaper som form eller farges harmoni, dyktighet i kunst, sannferdighet og originalitet.»
(Kilde http://dictionary.com )
Den røde tråden er at «skjønnhet» handler om det som er estetisk tiltalende. Det er nødvendigvis subjektivt … som illustrert av ordtaket «Beauty is in the eye of the beholder».
Vi kan bruke ordet «beauty» på kode , og den åpenbare betydningen er at koden er «estetisk tiltalende».
Men å si at «vakker kode» har et visst sett med attributter (som foreslått av andre svar) er en motsetning til åpenbar betydningen av estetisk tiltalende. Estetikk handler om hvordan mennesker … enkeltpersoner … oppfatter ting.
Eller for å si det det på en annen måte, det er noe motstridende om at noen forteller meg hva jeg skal synes er vakkert, det være seg i mennesker, kunstverk eller … kode.
Så langt når det gjelder meg er vakker kode kode som jeg synes er vakker, og det er den. Det er subjektivt og individuelt, og la oss bare la det være.
Svar
Her er mitt råd.
Se gjennom svarene til Hvordan kan du forklare " vakker kode " til en ikke-programmerer? og se hvilke egenskaper de sier å fokusere på. Deretter plukker du opp en bok som Kode fullført og les den gjennom for å lære råd om hvordan du skriver bedre kode.
På et eller annet tidspunkt vil den treffe deg mens du ser på eldre koden din. , «Dette er stygt.» Det vil være en direkte estetisk reaksjon. Og når du ser på den, vil du innse at du ser på koden din som en programmerer, og kan se styggheten fordi du vet hvordan en bedre kode skal se ut.
Svar
Bare fordi du ofte leser om vakker kode, betyr ikke det at folk som skriver om den har den samme definisjonen. Dessverre, å dømme etter spørsmålet ditt, ser det ikke ut til at de til og med gidder å definere det i utgangspunktet.
For meg er vakker kode:
- Ekspressiv
- Kortfattet
Kortfattet kode som ikke er uttrykksfull, kan være kryptisk, og uttrykkelig kode som ikke er kortfattet har en tendens til å være oppblåst og kjedelig å lese, så du trenger begge deler.
Jeg vil ikke inkludere vedlikeholdsevne som en del av det som lager kode vakkert, fordi skjønnhet er noe du ser / leser, ikke noe du handler etter. Men igjen er det mitt personlige syn.
Svar
Begrepet vakker kode er et veldig vagt og abstrakt begrep. Det er lett å finne ut hva det representerer og hva det betyr, men det skal aldri sees på som mer enn et sekundært mål.
Det minner meg mye om beregningen av kodedekning. Når du får tallet høyt nok, kan du slappe av og gå på noe annet. Å ha en kodebase med omtrent 80% dekning er flott, ikke skuddsikker, men nok til å slappe av og gjøre andre ting. Å ha 40% dekning er ganske skummelt og bør oppmuntre deg til å få det tallet opp.
Poenget er bare at kodedekning bare er meningsfull hvis tallet er lavt. Så ikke la det være lavt. Når dekningen stiger til et visst punkt, gå videre til noe annet.
Tilsvarende vakker kode er flott. Hvis du har pen kode, flott, gå videre til noe annet. Ikke stress for mye med det. Du vil aldri nå det 100% -merket, og hvis du gjør det, vil du finne at du har fokusert for mye på hvordan det leser ut, eller hvordan det ser ut, og ikke nok til hva den gjør, eller hvordan den gjør det. Så kom til et rimelig merke, og stopp deretter.
Men hvis koden din er flyktig, hvis det er et gigantisk kronglete rot av spaghettikode, hvis det fysisk smerter deg å åpne filen, hvis du ikke har noen kommentarer eller dokumentasjon etc etc etc og deretter fikse det. Og gjør det så raskt som mulig.
Du vil finne ut at kodebasen din over tid blir generelt renere, generelt lysere og generelt vakrere og enda viktigere, mer brukbar når du fokuserer på å gjøre den mindre flyktig. Å skrive vakker kode er ikke en prosess i ett trinn.
Det er ingen magisk filosofi. Dens 1000 mindre trinn, alle gjort sammen, som alle tjener et konkret formål som ikke har noe å gjøre med hvor vakker koden ser ut. Men når du server dem sammen, de danner vakker kode som summen av delene. Som voltron. Eller kapteinplaneten.
Svar
Jeg er virkelig enig i svarene her, men ved å ta en mindre teknisk tilnærming vil jeg si at vakker kode er et uttrykk for forfatterens «tankeklarhet om problemet ved hånden, som manifesterer seg gjennom et godt formulert og presist, men likevel enkelt språk.
For meg er å se gjennom vakker kode omtrent som å se på et kunstverk, se stadig nye detaljer som viser produsentens intensjon, men også hvordan de forskjellige delene ble realisert, hver som ga svar på så mange spørsmål, og til slutt hvordan dens eksistens føles som en naturlov som alt stemmer overens med slik at det bare kan beskrives med ærefrykt: magnificient , inspirerende, vakker.
Så fra det perspektivet kan du i din karriere som programmerer gjøre oppdagelser av vakker kode som andre kanskje ikke forstår fordi de mangler kunnskap eller kanskje ikke synes det er verdt å merke seg siden de har blitt bortskjemt av for mye skjønnhet;)
Vakker kode har alle de pragmatiske egenskapene som nevnt ellers, jeg er helt enig.
Svar
Jeg har tre kriterier:
- Enkelt: I det minste må det være menneskelig lesbart. For eksempel kan du skrive en kode som fungerer ved O (1) for en løsning med tonnevis av linjer, men jeg foretrekker kode som fungerer med 0 (n) løser med få linjer. Dette kan endres i ekstreme situasjoner, men for begynnelsen er enkelhet viktig.
- Gjenbrukbar: Koden må være gjenbrukbar, men ikke overskrevet. Hvis du trenger en operasjon, bør du definere den slik du kan bruke den år senere.
- Innrykk: Kanskje dette ikke er et problem for deg, men for nybegynnernivå er dette den første tingen som skal løses.