9. Kodkonventioner
lyssna!
Mitt i något av ett gemensamt värmeslag i en alldeles för varm lägenhet pratar vi kodkonventioner. Allt från semikolons existensberättigande, om vi föredrar dubbel- eller enkelfnuttar samt starka åsikter om hur filer ska döpas. Dessutom ett skämt om varför Therése inte kan ha en abstraktion på sina SQL-frågor och ett ordentligt missförstånd.
Om du gillar podden blir vi väldigt glada för en liten recension i iTunes eller en prenumeration på Spotify. Följ oss och säg hej på @asdfpodden på Instagram eller Twitter (Anton, Therése) <3
Avsnittets skämt:
Vet du varför jag inte kan ha en abstraktion på mina SQL-frågor?
Jag har ORM-fobi.
Skrapa här!!
Transkribering
Transkriberingen är gjord av nån "AI-grej". Du kan förbättra den genom
att
klicka precis här :)
- Anton, vet du varför jag inte kan ha en abstraktion på mina SKL-frågor?
- Nej. - Ormfobi.
- Alltså...
Det blir bara sämre och sämre.
Har du kommit på det själv, eller? - Ja.
- Okej, då är det ganska relativt sett bra.
- Ja, men vadå? Eller hur?
- Nej, men för att du har kommit på det själv så är det ett bra skämt.
Ja, och den är ju väldigt tydligt kopplad till mig, att jag har ormförening.
Ja, ja, ja.
Jag har tagit med mina egna upplevelser här.
Jag är...
Jag ska lägga det här skämtet i beskrivningen.
Eller jag kanske ska lägga första delen av skämtet.
Så att man får lyssna fast nu så får man höra punchlinen.
Jaha, okej.
Jag vill inte spoila dig när du säger det.
Nej.
- Ja, nej, fan det... Ja, bra. Jag skrattade.
(skratt)
- De här inledningarna blir bara längre och konstigare.
- Ja, jag vet. Men att börja med ett skämt, jag står helt bakom det, oavsett hur dåliga de är.
(skratt)
Ja, nytt avsnitt. Det var ett tag sedan vi spelade in, känns det som.
- Jag tror inte det var det. - Nej, kanske inte.
Det känns bara att... Jag vet inte. Jag har haft semester.
- Ja. Jag har ju inte haft det. - Nej.
Så nu har jag ändå varit tillbaka och jobbat en halv vecka, typ över dag idag, tisdag.
- Tisdag. - Ja, typ en halv vecka.
Så nu är jag ändå på banan igen.
Och min energi är fan, alltså dag och natt, jämfört med innan.
- Ja. - Det är så jävla skönt.
Jag har nog aldrig mått, alltså såhär relativt sett, så mycket bättre efter en semester som jag har gjort efter den här semestern.
Det är fan helt sjukt.
Och då har jag liksom gjort mindre än någonsin i vår.
Ja, men vi kanske är som hälsen då. Det är ju jobbigt att göra samma sak och sitta still på samma ställe i samma lägenhet.
Det är nog jobbigare än vad vi tror.
Ja, Gud ja. Nej fy fan. Det ska vi inte prata om. Jag tänkte, vi pratade lite grann om, jag hade skrivit ner en händelse "Kodkonventioner, bra eller anus?"
Mm, och då frågade jag "Vad menar du med det?"
Exakt. Men jag tänker kodkonventioner kan ju vara ganska mycket.
Jag tänker det behöver kanske inte vara kodkonventioner, kanske kan vara bara konventioner överlag,
alltså när man utvecklar.
Typ om jag ska komma på något exempel nu, döpkomponenter med stort bokstav i React.
Fast jag inser att det är liksom inte riktigt en konvention för att om man inte gör det så pajar det.
Ja, eller det är en tydlig konvention från React-sidan. Det är en vald regelmässig konvention.
Ja, precis. Men okej, kanske mer hur man ska formatera koden.
Mm, vill du köra default exports eller named exports?
Exakt, det har jag starka åsikter om.
Oj, vad jag bryr mig väldigt lite.
Nej, men okej. Just inom React så när man kör default export.
Jag har starka åsikter att det ska vara inte default.
Alltså att de ska vara named, att man namnerar dem.
Mycket för att det blir enklare, om man skulle lägga till någonting mer,
att exportera från samma fil, då är det enklare att den också kommer med.
Då behöver du inte ändra på den tidigare.
Och när det gäller komponenter så vi hade typ så här, om du, nu kanske det är fixat i och för sig, jag vet inte, men förut var det så att om du så här bytte namn på komponenten när den var default export, då byttes inte importnamnet liksom.
Alltså om du gjorde en refakturering med typ F2 i VS Code till exempel.
Okej.
Hänger du med på vad jag menar?
Jag har inte gjort så mycket F2 i VS Code.
Det är ju drömmen.
Min egentligen prefererad IDE är ju Webstorm.
Det borde vara samma där, eller?
Det är ju rename symbol.
Tack för att du förklarade det, för att F2 är den universala.
Inser att F2 kanske inte är universal.
Det kan faktiskt vara så att det är F2 i Webstorm också.
Men jag inser att det är helt rätt, man kanske borde säga att refakturera, byta namn på den här symbolen, alltså variabeln eller funktionen eller vad fan det nu kan vara.
Ja, men det är ändå rimligt att det inte döps om för att de inte kopplar det till varandra.
Nej, precis. Men det vill man ju alltid.
Ja, det kanske är. Alltså det är kul nu när vi ska prata kodkonventioner för att jag är ju inte så himla opinionated.
Jag är mer, jag vill bara att saker ska vara lika.
Ja, liksom igenom hela kodbasen.
Ja, i största möjliga mån.
Sen exakt hur det är, det har jag riktigt svårt för.
Det är dubbelfnuttar i JavaScript.
Där vill jag ha enkelfnuttar så länge det inte är HTML eller JSX.
Ja, det är typ en av de få regler jag brukar ändra i Prettier.
Jag tror den defaultar till dubbelsnyttar, eller har gjort i alla fall.
Tror den kan ha bytt... Nej.
De bytte nånting i alla fall i den senaste major som ändrade allting i hela vår bas.
Exakt. Det är alltid kul.
Man bara kör "default Prettier" och så byter de av och man bara "ja, ja".
Nej, det var nog "trailing commas".
Ja, för den tänkte jag också säga. Det är också en som jag brukar ändra.
fast nu, det visste jag att ni har vändat nu, att ta bort trailingkomma.
Det vill man inte ha.
Ja, jag tycker det är ganska nice.
Det är bara vägen.
Nej, alltså det är ganska nice när man ska lägga till nya rader.
Då behöver man inte tänka på det.
För det är alltid trailingkomma.
Annars blir det så här, "Någonting gick sönder, vad gick sönder?"
Ja, komma.
Vilket otroligt sammanhängande avsnitt det var.
Okej, om vi ska prata lite trailingkommas.
Jag tror att vi får skylla på att vi har värmeslag här, för det är fruktansvärt varmt i lägenhet.
Nej, men alltså trailing-kommas är ju helt onödiga.
Det finns ingen anledning att ha dem.
Nej, men det finns ingen anledning att inte ha dem.
Jo, de är i vägen.
Fast de är ju jättebra att ha när du bara ska lägga till någonting nytt under.
Ja, men då kan man lika gärna trycka enter.
Vadå trycka enter? Ja, men då får du inget komma.
*Skratt*
Ah!
Just det!
Just det!
Jag vet att det här är ljud nu bara men om ni såg hur tydligt man kunde se någonting tändas in i Antonijas huvud nu.
Gud, jag kom på att jag absolut höll med dig.
Vet du vad, som sagt skyllde helt på värmen.
Jag pratade om en helt annan sak.
Jag pratade om semicolon.
Nej, jag inser också det här.
Trailing Commas, skitbra, älskar Trailing Commas.
Det är det jag har sagt i latin.
Du var väldigt rätt.
Hur kan du gilla semicolon?
Det var det jag tänkte. Vilket du kanske gör ändå.
Men okej, trailingar kommer man skitbra för att jag håller helt med att man ska alltid ha det för att då kan man bara trycka enter och lägga till en ny rad.
Däremot, semicolon i rörelseuppgift. Bort.
Ja, alltså jag är igen inte så opinionated.
Jag känner att det här kommer vara jag som skriker hullt saker och sen rätter du mig när jag skriker om fel saker, uppenbarligen.
Ja, jag var ju, speciellt i början, mycket mer opinionated.
"Du kan inte ha Snake Case här, och även Case är fult."
Precis när man börjar.
För då tror jag att det är de här grejerna som jag förstod i början
och som jag kunde hålla fast vid, att det här måste vara bra.
För jag hade egentligen inget annat.
Jag hade inga patterns, jag hade inga andra kodkonventioner att lägga min tid på.
Så det blev väldigt mycket detaljer.
Nu är jag mer så här...
Ja, det jag tycker är riktigt jobbigt är när det är olika överallt hela tiden.
Som jag sa, jag vill ha det liksom konsekvent över projektet.
Sen utöver det så spelar inte det så jättestor roll för mig känner jag.
Jag har aktivt jobbat på att släppa lite med det också.
Just för att jag... Ja men som konsult så kommer man in i ett projekt.
Och jag vill inte vara en sån konsult som kommer in och börjar ändra allting direkt.
för att jag vill ha det på ett visst sätt.
Det tycker jag är helt fruktansvärt doucheyt bara.
Så jag är mer så här, hur vill ni ha det?
Vad gör jag här?
Absolut, då gör vi så här här.
Semikolon, inga semikolon.
Jag är fine med vilket.
Jag håller helt med i det du säger.
Även om jag nog kan lyfta vissa grejer.
Men de grejerna jag lyfter, jag skulle inte lyfta så här,
vilka prettigare regler vi har.
Till exempel.
För att de spelar egentligen inte så stor roll.
Om det inte är något som är superkonstigt såklart.
Men att ha ett semicolon eller inte, det är ju super opinionated i att
ta bort dem för att det ger mig ingenting att ha dem där.
Medan om man jämför med till exempel
default export eller named export,
då ger det mig ändå någonting att ha dem som named export för att om jag ska refakturera så går det mycket enklare.
Samma sak, en annan grej som jag också, eller om man tittar på det nuvarande projektet jag är på, då har vi typ att
filerna som komponenten ligger i heter med snake case
eller kebab case eller vad man vill kalla det.
Snake case är ju med underscore kebab case, det är ju med dash.
Ja, just det.
Det är det ja.
Jo, men du har helt rätt.
Precis, de heter med kebab case.
Och jag kanske föredrar att ha dem
alltså att filerna heter samma sak som komponenten, det vill säga med
camel case.
Är det den?
När man har stor bokstav i början också?
Nej, det är ju... Då är det något tillägg, va?
Ja, jag har sett det också.
För CamelCase är en liten bokstav i början.
Precis.
Gud, jag kommer inte ihåg.
Nej.
Nej, PascalCase heter det, va?
Ja, det gör det.
Och jag föredrar PascalCase-namnet på både filen och komponenten
för att då heter de samma sak.
Och det är lite mindre att komma ihåg, liksom.
Men det gör mig ingenting nu, att sitta i ett projekt där det inte är så.
Att det skulle ge mig någonting att ändra på alla filer, nej.
Det kommer inte hända.
Men däremot andra grejer som default export eller
något som jag tänkte på nyligen som var
att faktiskt döpa filerna till
namnet
på komponenten. Oavsett hur man formaterar det.
Men många döper dem ju till index.tsx eller index.js eller jsx eller vad fan man nu vill.
Och där drar jag någon typ av gräns.
Alltså, jag fattar att folk vill ha lite snyggare importvägar.
Men det är enda vinsten och det är ingen vinst.
Nej, alltså här är jag väl också.
Jag har väldigt svårt för att det finns fem miljoner indexfilar.
Jag tycker det är jättestökigt och jag ser inte vilken fil jag öppnar på mina tabbar.
Då måste jag in och kolla vilken jävla papp det är.
Och jag kollar ju alltid fel för jag läser ju som en kratta.
Alltså det där håller jag absolut med.
Jag tycker inte det är trevligt, men sen finns det vissa grejer när man samlar allting i en indexfil per mapp.
Vilket jag också kan stämma lite på för då är det en fil med bara exporter.
Men så drar man en import där.
Och så drar man många importer från samma ställe för det är någon typ av utill eller ikon eller någonting.
Och då är det helt plötsligt ganska nice.
Så jag ser ju både fördelar och nackdelar med det.
Ja, det är väl enda fallet jag skulle också liksom tycka att det är okej.
Alltså att du har någonting, men kanske inte liksom om du har komponenter som du är öppet till.
Även om de exporterar flera grejer.
Utan, snarare kanske som du säger, man har en utill-grej eller du vill ha en entry point in i den modulen eller vad det nu kan vara.
Om det är utills eller vad det kan vara.
Men exakt som du säger, det är så mycket negativt, man döper alltid inte index.
Och sen blir det också så här, hur ska man fortsätta följa den standarden då?
Om man har valt att komponenterna ska heta det, ska testerna också heta det?
Ja, vi har ju ganska många index.test.tsx.
Ja.
Och vilket index testar den här nu då?
Exakt.
Och det är bara, för mig så spårar det alltid ur.
För att, sen har jag varit med om att folk gillar att ha sin styling utanför.
Och då är det så här index.style.ts.
Och man bara, ah, en till indexfil.
Så nu är det tre indexfiler på en komponent.
Och man bara, ah.
Ah.
Ja, vi har faktiskt styles.scss.
Nu har den blivit rätt.
Fast det är lite nice med de här import from punkt slash.
När man är i samma mapp.
Det finns färdigheter och nackdelar med allting.
Jag är egentligen mot index och när jag började på ett in-house-projekt
och skrek jag lite om det så var jag lite upprörd och sen så går det över efter en vecka
för att det bara börjar följa strömmen.
Jag orkar inte riktigt bry mig, men jag tycker generellt sett inte riktigt om index.
Vi har ju också ett storybook-projekt, så vi har ju index.tsx, index.test.tsx, index.stories.mdx.
Man hör ju redan här, det skaver igen. Det är hemskt.
Jag kan föreslå att vi ska ta på oss style-filerna till index.se.
Nej, jag har inte det.
Men du kan ju lägga det som ett ironiskt argument åt andra hållet.
När du försöker omvänd psykologi.
Ska vi inte döpa om stylefilerna till index också? Allting måste ju följa samma standard.
Och sen kan du liksom, fast det skulle kanske vara bättre om man kunde skilja på de här.
Som av en händelse, vad det här är.
Exakt, och sedan att någon lyssnar på det här avsnittet.
Men jag berättar ju inte för så många att jag har den här på.
Det har vi ju förstått. En annan konvention, nu är vi inne på React-konventioner, men det här känner jag väl kanske inte, eller jag känner starkt för det, men jag lägger mig väldigt lätt, så att säga.
Typ om man kör style components till exempel.
Aldrig kört style components.
Men det är ju typ att du definierar
Ja, du definierar stylingen i komponenten egentligen
och sen så blir det typ en komponent.
Ja, exakt. Alltså det du kan göra är att du kan skriva typ
styled.div och sen skickar man in
en template literal, det vill säga
de här back, bakåt-fnuttarna.
Som, som, vad heter det?
Markdown?
Ja, men också GraphQL var jag tänkt på.
Ja, precis, precis.
Du skriver typ "style.div" och sen sådana där bakåtfnuttar.
Och sen kan du skriva CSS, precis som du skriver CSS i vanliga fall.
Och då får du tillbaka en, det är väl tekniskt sett typ en komponent.
Fast den har liksom, det blir då en div med den här stylingen på bara den diven.
Och då gäller det liksom bara den.
Och sen kan man även göra typ "style" och sen parenteser istället för punkt.
Och så skicka in en komponent och så kan du styla den och grejer.
Och det är ganska smidigt. Jag tycker det är skitnice att skriva CSS på så sätt.
Och här är också två åsikter egentligen. Det ena är att jag tycker att oavsett om man har sådana eller om du har en hjälpfunktion, du har någon såhär, någon liten hjälpfunktion som inte ligger i komponenten men som du ändå använder i komponenten.
Sådana grejer tycker jag ska ligga nedanför komponenten i filen.
Ja, jag tycker någon sak du ska ligga ovanför.
Ja, innan jag säger varför jag tycker det, varför tycker du att de ska ligga ovanför?
Jag tror det lever kvar den här gamla att saker som ska användas sen ska finnas först.
Jag har nog ingen egentligen, återigen jag kanske inte har så stark åsikt här heller, men jag tror att bara i mitt huvud är det mest naturliga.
Att jag vill se vad jag ska använda och då ska det ligga innan jag använder det.
Jag fattar helt, men det är spännande.
Jag håller med om det argumentet att man vill gärna ha grejer i ordningen de används uppifrån och ner.
Men mitt undantagsfall är just i komponenter.
Jag vill ha komponenten först i filen.
Så när jag öppnar filen så ser jag att det här är komponenten.
Då kan man få en väldigt enkel översikt över vad det är för någonting.
Jag vill inte ha, jag tycker att både style components och hjälpfunktioner och om det kan vara någonting annat som ligger utanför
är liksom implementationsdetaljer
Och jag vill inte behöva bry mig om de funks jag
behöver om
Här var min hjärna bara
Ja men det är ju bara att scrolla
Jo, jag håller helt med. Det låter så, när jag säger det så låter det så i huvudet av mitt hundet
Att säga ja det är bara att skruva ner till komponenten
Men att slippa göra det varje gång man öppnar en komponent
är ganska skönt
Ja, jag förstår absolut vad du säger. Om jag är intresserad av att använda en komponent.
Om du kör sådant som TypeScript till exempel, vill du inte ha interface och sådant först?
Jo, det kanske är något undantag. Props interface till exempel, den brukar jag lägga ovanför.
Ja, för att som du säger, om man vill in i en komponent, ska jag använda den här komponenten, då vill jag ganska snabb info kring
Vad tar den för props, hur funkar den, vad är det för typ av komponent?
Jag är inte intresserad av hur den är implementerad om det inte är så att jag ska in och mecka i den.
Så absolut, jag förstår det om man ska använda det, men då skulle jag nog vilja ha,
använda som du säger, props och sånt högst upp.
För att det är ändå relevant för användandet.
- Ja, men det håller jag helt med om. Och så har jag också gjort, när jag gjort det.
Att så här, propsen ligger omför.
Men det är mycket, argumentet är just att jag vill kunna få en överblick av komponenten
ur perspektivet jag ska använda den.
Eller liksom, vad är det den här tar in?
Eller vad är det? Någonting sånt.
Jag behöver liksom inte veta implementationsdetaljerna
direkt. Jag behöver inte få dem
kastade i ansiktet på en.
Nej, jag har nog inte tänkt
så mycket på det överhuvudtaget.
Men nu är du såld.
Det blir på något sätt absolut
att man ska in en kod och rota, men jag
tänker om man har ett storybookprojekt också
då är egentligen tanken att du
ska kunna vandra in i storybook
och faktiskt titta på komponentens info, se vad är det för någonting, vad ska den ha, hur används den.
Vårt storybookprojekt gör ju inte alls så överhuvudtaget, men det behöver vi inte prata om nu.
Men det är ju tanken tror jag. Så att jag har nog inte tänkt att kod är där man ramlar in först kanske.
Nej, det kan jag ändå förstå också.
att liksom, jag vet inte, jag känner bara att jag hamnar ofta där då,
att då hjälper det ofta att bara ha den högst upp.
Ja.
Så är det ändå. Men som sagt, det här är också en grej jag liksom,
"jaja, det projekt jag sitter i nu har ju inte så här",
då ligger allting ovanför och sen komparenter längst ner.
Ja.
Så några konventioner som jag har, som när jag får härja fritt i en fil,
håller och sen ger upp.
Det är många importer, exporter eller ikoner eller vad det kan vara.
Jag vill ha dem i alfabetisk ordning.
Och det är till och med till den grad att jag orkar inte ta hem ett plugin
eller ett paket för att göra det automatiskt,
utan jag sitter hellre och sorterar dem automatiskt.
Jag tror att det är nog kanske också,
jag tror att det är mycket det som gör att jag inte har så mycket problem med konventionerna.
Jag gör ganska mycket manuellt för att jag orkar inte bry mig till den graden.
Det är så här, det här är ett jättetråkigt arbete, det är fine för mig för jag tycker det är rätt skönt att sitta och göra någonting trögt och bara tänka på molnet tag.
Jag är inte en sån som, det här måste jag automatisera.
Det här borde jag absolut kunna bygga ett skript för att göra, för att sitta och göra det här för hand i tio gånger, det är helt orimligt.
Fattar.
Medan jag är mycket mer så här, ja men typ som, ja jag ska döpa om allting och jag använder Visual Studio Code.
F2 funkar inte på default exports och det driver mig till vansinne.
Jag är mer så här, jag kör en search och en replace på alla namn
och sen så utvärderar jag dem ännu och än för att se om det är någonting jag vill dra på.
Jag är lite mera, jag vill säga analog.
Det är ju fortfarande digitalt men jag skulle vilja säga att jag är lite mera...
Ja.
Men alltså importer i alfabetisk ordning är ju lite intressant ändå.
Det måste vara lite kontroversiellt.
Alltså?
Ja, men det tänker jag.
Vill man inte importera lite mer i semantisk ordning?
Jo, inte komponentimporter, inte importer från olika paketer.
De snarare när jag vill importera alla de här komponenterna för att kunna exportera ut dem i projektet.
Ah, okej, okej.
Jag såg framför mig att det var blandade rader mellan komponenter, hjälpfunktioner, bibliotek.
Allting blandades rakt ifrån ner och jag bara "Oh, här ryser jag av".
Går du in och ändrar alla komponenter och alla gråter?
Nej, absolut inte. Om vi snackar React, React ska vara överst.
Alltid. Sen ska externa paket komma.
Sen kommer typ interna paket.
Och sen komponenter, helpers, alltid styles sist.
Det är det värsta jag vet dock.
När styles kommer i mitten.
För vi kör CSS-module.
React, bla bla bla, komponenter, bla bla bla.
Sen kommer det en import CSS.
From styles.scss.
Och sen kommer det flera JavaScript-importer.
Det driver mig till vansinne, för jag vill ha CSS-importen sist.
Ja, jag förstår din plåga så att säga.
Okej, men då är jag lite lugnare.
Det var inte helt att ha den alfabetiska ordningen.
Nej, jag gillar den här när det är väldigt tydligt i våra huvuden när vi pratar om det och andra panikar lite.
Alla sköntar lite nu.
Jag har lite style components grejer, men det är svårt att skriva style components.
Man kan skriva style components både som en template literal, som en sträng,
och skriver det exakt som du skriver CSS i vanliga fall.
Men du kan också skriva den som ett objekt.
Och då skriver du typ som när du skickar in en style prop till vanlig React JSX.
Ja, jag tror att så är det där i en Next.js-tutorial.
Det såg inte alls trevligt ut.
Nej, jag gillar det inte riktigt.
Jag tycker att det är mycket skönare att skriva vanlig CSS.
För då är det också så här, ja men säg att vi skulle byta från StyleComponents.
Ja, det är bara att kopiera lite.
Ja, men blysa det när du skriver allting inline.
För att jag menar, det beror ju självklart på vad du bygger.
Men CSS kan ju verkligen bloata massor.
Och då bloatar man ju hela JSXen.
Det blir ju inte så läsbart tycker jag.
Nej, exakt. Med style component blir det lite mer läsbart, för då kan du fortfarande bryta ut, du får fortfarande ut en egen komponent så att säga.
Bara att du skriver det fortfarande som ett objekt istället för som en sträng.
Okej.
Så det blir inte inline i din rendermetod om man säger så då.
Nej, för det här jag såg, det var allting var inline i J6n.
Ja, men exakt. För det går ju att göra. Alltså det går ju alltid att skicka ett styleobjekt till allting i
i sextyp.
Ja, det var inte
det var ingen favorit.
Nej, jag gillar inte heller inte det, för ibland kan det bli så jävla mycket.
Ibland har man väldigt mycket CSS och då blir det ju kaos.
Nej, så vet jag inte. Men som sagt, jag tycker ändå
för att komma tillbaka till det temat var egentligen
så tycker jag att konventioner är ganska nice
så länge man inte är liksom
religiös med dem, alltså att man verkligen följer dem för att vi måste följa konventionen typ?
Nej, alltså konventionens är ju jag som är nödvändiga
för ett projekt för att hålla koden konsekvent.
Och det tycker jag är jätteviktigt för att som sagt, det blir jättekausigt när alla gör det på sitt sätt.
Det blir stökigare kod och jag tror att det blir, alltså jag skulle ju säga att det blir mer buggar för att man
läser inte varandras kod lika enkelt och sådana saker.
Så absolut att kodkonventioner är viktiga.
Sen exakt vilka är kanske inte så viktiga.
Nu har vi lallat iväg lite med det,
men vi har också pratat väldigt mycket React.
Det finns ju mer allmänna som jag håller,
typ den här, ska man ha bra variabelnamn
eller ska man kommentera sönder allting hela tiden?
Och vad skriver du för typ av testkommentaren
när du skriver tester och sådana saker?
Där är jag...
Jag vet inte om man ska säga skolad.
Det är nog någon som har lärt mig och den personen har jag tagit efter mycket.
För jag tycker att variabelnamn för mig får ju kanske hellre vara långa.
Det finns ju en gräns. Det finns ju de som skriver hela meningar för att de tycker det makar mer känsl.
Jag är mer så här "kan vi få det kort och koncist och förklarande?"
Det föredrar jag ju hundra gånger mer än att kommentera allting.
Kommentarer tycker jag är till för mera,
"Ja, men den här affärslogiken är skum"
eller "Det här beslutet gjorde att koden ser ut så här".
Sådana saker, så det är sånt jag vill använda kommentarer för.
Jag har lite svårt för hela den här param,
Vad ska in, vad ska ut, vad gör funktionen, vad den tycker jag är?
Ja, jag gör också väldigt mycket, jag vet inte vart det är ifrån riktigt.
Men jag har plockat upp att kommentarer ska beskriva varför och inte vad.
Alltså det ska beskriva syftet bakom koden, om det behövs, mer än vad koden gör.
För koden ska vara självförklarande i stort sett.
Och sen som sagt, om det är någonting konstigt, om man tittar på koden och säger
Varför ser den ut så här? Då behöver man en kommentar.
Ja.
I stort sett.
Jag tror också att några av mina favoritkommentarer var väl någonting i stil med
"We should really fix this but we have no time so it looks like this now because it looks like this."
Jag har jobbat i ett projekt där det stod en kommentar, en lång kommentar, alltså en 10-15 raders kommentar
om typ "här har det spenderats mycket blod, svett och tårar"
Och sen var det liksom en lång kommentar om så här "Vi har gjort vårt bästa" typ.
Det var ett projekt vi tog över från en annan leverantör.
Och sen kom in skuldförvaltare och så öppnade man det här och bara "Ja, okej, okej".
Och sen stod det typ "Lycka till" tror jag.
– Åh Gud, det är ju verkligen domerdagen.
– Och alltså det stämde ju för att den där kodsnutten som den där kommenterade
kommenterade spenderades det mycket blod, svett och tår av till på efter den här kommentaren.
Jag har tittat på ett projekt en gång, där man öppnade P&P, och det var ingen som var P&P-utvecklare,
så öppnade man det, och så var det kommentarer på kinesiska. Man bara "Jajamän, jag stänger den här igen och så backar jag långsamt bakåt".
Det är så klassiska, det var någon kommentar som stod "Here be dragons" som också var viral för ett tag sedan.
Som också var en varning för att försöka inte ens.
Det här är bara farligt att röra sig här i det här området.
Och man bara okej.
Ja, men det är ändå nice på något sätt för då förberedde man sig för det allra värsta.
Det var som någon sa på universitetet att reglerteknik var en helt omöjlig kurs som vi inte kunde klara av.
Och jag nojade över den i några år, sen så fick jag en femma.
Alla andra kurser gick skit, men regler teknik gick bra.
Fyra förväntan, helt enkelt.
Ja, precis. Så att jag tror, ja.
Jag tror också, eller så här,
jag tror när man börjar rota i det och kodkonventioner och se vad man gör
så tror jag det är oändligt mycket mer än vad man tänker på.
Ja, ja Gud, jag känner när vi pratar nu bara att vi skulle lätt kunna återkomma till det här
om ett halvår i ett nytt avsnitt och prata lika mycket mer om kodkonventioner.
Vi skulle kanske också kunna vara lite mer strukturerade.
Det kan vi göra, vi kan vara lite mer preppade.
Ja, jag vet inte om vi någonsin kommer bli mer strukturerade.
Nej, det märks.
Det känns ju inte som en grej.
Nej.
Nej, men typ, alltså en annan sak som jag har tänkt mycket på det är ju tester.
Unittester framför allt.
Jag brukar hålla lite på on the down low, att jag är bra på tester.
Nu är jag inte bra på tester, men jag är helt okej på tester, liksom.
- Du är inte dålig på tester. - Nej, jag orkar inte riktigt rota i dem, men jag kan skriva tester.
Jag kände precis hur Jante kom och kastade en sten i mitt huvud.
Att unitester kan många se som "det suger att skriva test" och lalalala.
Jag är mycket mer som att man ska se det som att man testar.
Dels testar man kontrakt, om det är integrationstester som man har, men även unitester är väldigt tydliga för dokumentation.
Här skriven tydlig beskrivning av vad du testar, vad du förväntar dig
och sen så kommer du ha dokumenterat din kod på ett otroligt bra sätt
som folk efteråt kommer kunna använda för att förstå den bättre.
Och då menar jag, om man tar specifikt React-komponenter, då menar jag ju
sällan att testa att någonting du har skickat in renderas, för det är inte så himla intressant att testa.
Det är mer att då testar jag att React gör det React ska göra, typ.
Men saker som förväntas förändra sig, extra skumma saker,
uttills som du använder till de här grejerna,
alltså att skriva väldigt bra tester.
Och har man väl skrivit ett test, då är det ganska lätt att skriva för några case till.
Och då blir det väldigt tydligt dokumenterat,
jag förväntar mig det här, jag förväntar mig inte det här.
Om det här händer så är det uppenbart en bugg.
Och då har man gjort, ja men alltså, det är ganska vettigt tycker jag.
Likadant som för andra Java-tester och sådana här, om du bara är tydlig i dina tester, du får så himla mycket med det.
Så det är en konvention jag tycker är bra.
Ja, gud ja. Det är också ett avsnitt som kommer.
Alltså?
Ett pratat testning. Lätt.
Vi har nog kanske dragit över lite på tiden, men jag tänker ändå att vi kan återkomma till konventioner lite mer preppade.
med våra favoritkonventioner
och våra hatkonventioner
- Trailingkommas
- Trailingkommas, uppenbarligen
Ja, det är fem minuter i början
men jag har totalt missuppfattat vad jag pratar om
Det är ändå härligt
Jag hade kunnat klippa bort det, men det ska vi inte göra
- Det är för sent
- Nej
Men vi kanske rundar av där, eller?
- Ja
- Och som vanligt, allt som vi brukar säga på slutet
men det är för varmt för att säga det just nu
Ja, men Twitter, review, säg hej till oss, tycka om oss.
Exakt, vi behöver uppmärksamheten.
Ja, ha ett bra bad.
Allt sånt. Men då säger vi så.
Okej.
Hej då.
Hej då.
