Heisann sveisann! Er du interessert i å bidra? Kult!
Det er derimot noen kodestilsregler jeg ønsker at skal følges. Dette dokumentet fungerer som en defacto regelbok for både meg og/eller andre.
All kode skal være typet til beste evne. Dette betyr at man for eksempel også gjerne bør spesifisere typene innad i en dict eller lignende.
Alle funksjoner skal ha docsstrings som følger denne stilen:
def greet(self, navn: str) -> str:
"""
Greets the invoking user using the inputted name
Parameters
----------
navn (str): The user's inputted name
Returns
----------
(str): A greeting
"""
return f"Hello, {name}"
Sløyf alt som ikke brukes.
Hver kommando er en funksjon som har et eller flere decorators over seg. Dette er sjekker som utføres før kommandoen kjøres. En av disse konverterer også funksjonen til en faktisk kommando som vi kan kjøre gjennom Discord.
Decorators skal sorteres som følgende:
- is owner
- Guild only
- Bot permissions
- User permissions
- Cooldown
- Kommando (denne må alltid være med)
Merk deg at ikke alle disse trenger å være med, og ikke alle sjekker som finnes er nevnt her. Bruk hodet og tenk hva som er logisk for deg om du møter på en slik situasjon.
Ja, det tittelen sier. Det er et unntak for returstatements hvis det er tatt i bruk early returning.
Selv om Discord.py 2.0 støtter oversettelser, er ikke dette noe vi implementerer. Med tanke på at botten er norsk og for norske brukere må dette reflekteres i parameternavn siden dette er hva Discord bruker som grensesnitt for kommandoer.
All annen kode holdes på engelsk. Dette inkluderer kommentarer.
Et tips er å ha et engelsk funksjonsnavn, men spesifisere i decoratoren over med navnparameteren.
error_warning
skal brukes om det er feil brukerinput, mangel på data eller generelt sett en feil som er forventet/ikke av utenforstående årsåker
error_fatal
brukes når en uventet feil skjer. Ofte på grun av utenforstående årsaker som et API som er nede osv.
success
kan brukes til å gi brukeren en bekreftelse på at operasjonen som ble forespurt gikk fint. Det vil si at den ikke skal brukes til å vise spesifikk data, men heller brukes når det ikke er noe å vise.
Generelt sett unngår vi bruk av leading underscores for variabelnavn og metoder. Ja, de har sin bruk, men Python var aldri ment til å være objektorientert på samme måte som f.eks Java. Uansett skal en ikke bruke metoder fra andre cogs. Dermed er regelen: greit overalt utenom i cogs.
Hvis en ny avhengighet trengs, sørg for å spesifisere major og minor versjon i requirementsfila.
- Bruk embeds til feilmeldinger og som respons om mulig.
- Sett cooldown til 5 sekunder for kommandoer som krever eksterne API kall eller særlig mye prosessering.
- Ellers, settes denne til 2 sekunder.