Wiktionary:Stilguide/Skapa en modul

Moduler på Wiktionary liknar mallar, men tack vare att de utnyttjar programmeringsspråket Lua så är de både kraftfullare och mer effektiva. Denna sida innehåller rekommendationer för hur en modul på svenska Wiktionary bör vara utformad.

Tillägget som erbjuder detta är Scribunto, och på den sidan finns mer teknisk information och till exempel hjälp om felsökning. Det finns även en referensmanual.

Låt säga att denna exempelkod är innehållet i ]:

-- Alla moduler ska ha en local export-tabell som returneras i slutet av modulen.
-- Det är så man kommer åt och kan anropa funktionerna i modulen.
local export = {}  

-- Funktioner som ska anropas från mallar ska ta endast argumentet frame, via frame får man tag på argument.
-- De flesta moduler kommer bara ha en funktion som anropas från mallar för att skapa Wikitext, den ska heta getWikitext.
-- Funktionsnamn skrivs med camelCase
function export.getWikitext(frame)
	local short_message = "Hej snyggingar!"  -- variabelnamn skrivs med snake_case
	return short_message
end

-- Funktioner som bara används inom modulen ska deklareras som lokala.
local function myFunction()
	-- Funktionens innehåll...
end
 
return export  -- Alla moduler avslutas med att returnera export

Ovanstående exempel skulle anropas med {{#invoke:module-name|getWikitext}}.

• Moduler som hör ihop med en specifik mall ska ha samma svenska namn som mallen. I andra fall ska modulens namn vara på engelska.
• Modulens namn ska ha små bokstäver där orden är förbundna med bindestreck (dashed-lowercase). (Undantag är moduler som har importerats från en annan språkversion och som då kan få behålla sitt engelska namn men med avvikande versalisering (t.ex. PascalCase).
• Namn på variabler och funktioner ska ska vara på engelska.
• Variabler ska deklareras local och skrivas med små bokstaver och med orden separerade med understeck (snake_case).
• Objektegenskaper/tabellnycklar räknas till variabler och skrivs med snake_case
• Funktionsnamn skrivs med camelCase
• Undvik kommentarer i koden. Koden ska vara lätt att läsa och förstå även utan kommentarer.
• Kommentarer bör inte dokumentera modulen, detta ska göras i modulens dokumentation.
• Lätt kod är bättre än smart kod.
• Se gärna till Kategori:Sidor med skriptfel efter att du har ändrat i någon modul.
• Kod ska vara indenterad med tabbar.
• Använd med fördel Modul:parameters för att ta emot argument från en mall- eller modul-inkludering. Med den modulen så begränsas vilka parametrar som är tillåtna att skicka in så att man kan upptäcka om man t.ex. stavat en parameter fel. Använd med fördel Modul:param för att detektera icke-uppskattade parametrar.

• https://blog.codinghorror.com/spartan-programming/
• https://blog.codinghorror.com/coding-without-comments/
• https://www.python.org/dev/peps/pep-0020/

Alla funktioner i en modul ska ha tester som återfinns på undersidan /test till modulen. Testerna ska ge en snabb överblick över alla användningsfall i modulen så att man som utvecklare lätt kan se att modulen fungerar som det är tänkt och på så vis förhindra att man publicerar ändringar som har sönder mallen. Testramverket som vi använder oss av är Module:UnitTests.

Testen bör inkluderas i (slutet av) dokumentationssidan så att de enkelt blir synliga.