Free Press

Välkommen till den underbara världen av mjukvaruutveckling. Förbered dig på en spännande och spännande resa fylld av kod, regler och ännu mer kod. Och nämnde jag att det finns regler? Om du är någon som är bekant med kodning är begreppet kodningsstandarder inget nytt för dig. Du kanske är en stark anhängare av dessa riktlinjer eller en frihetskämpe som anser att kod är en uttrycksform. Oavsett vad som är fallet skadar det inte att titta på några av de bästa metoderna när det gäller att skriva ett bra stycke kod.
Det är värt att nämna att även om kodningsstandarder finns – så finns de i många varianter och är ofta bara riktlinjer som inte behöver följas. Om du inte vill skriva bra kod bör du förmodligen hålla dig till någon form av standarder.

Skriv kommentarer och dokumentation

Kanske är en av de första sakerna du lär dig som utvecklare att kommentera din kod. Till en början kan det tyckas vara slöseri med tid och följa mentaliteten ”Om de också är utvecklare – kan de förstå det”. Även om det är sant en del av tiden kommer kommentering av din kod och ordentlig dokumentation att vägleda de andra utvecklarna genom algoritmen och logiken som du har implementerat. Men låt dig inte ryckas med och kommentera varje kodrad! Uppenbar kod bör lämnas som den är.

Skriv läsbar men effektiv kod

Läsbar kod är lätt att följa, men använder ändå optimalt utrymme och tid. När du skriver kod kan du ofta vilja skriva den med så få rader som möjligt. Kanske kan du skriva en hel metod eller funktion på en rad, men det gör det bara svårare att läsa och förstå.

Använd hjälpmetoder

Det är bra att hålla koden koncis och kortfattad. En metod bör endast implementera det som den behöver göra. Om en del av din implementering gör något annat, lägg den i en separat metod och anropa den inom din metod.

Om det går att undvika, gör INTE hårdkodning!

De enda saker som bör hårdkodas är konstanter. Det är allt.

Skriv testfall. Glöm inte de yttersta fallen: 0:or, tomma strängar/listor, nollor osv.

På så sätt vet du vad din metod gör, vad den tar och vad den ska returnera. Du kommer att veta när den ska fungera eller när den ska misslyckas. En funktion bör alltid baseras på testfall, inte test på funktioner.

Skriv läsbar men effektiv kod.Överensstämmer med kodningsstandarderna för ditt aktuella projekt

”DISCIPLINED PERSONAL PRACTICES CAN REDUCE DEFECT INTRODUCTION RATES BY UP TO UP TO 75 PERCENT”

Varje projekt/företag har sina egna kodningsstandarder. Vissa kanske föredrar en stil framför en annan när det gäller saker som namnkonventioner, filstruktur och avstånd.
Det finns IDE-program där du kan ställa in den föredragna stilen, som kommer att korrigera dig automatiskt när du sparar. Det är lättare att läsa och därmed förstå när alla filer i projekten använder samma stil, namnkonvention, avstånd osv.

Använd IDE:s rullgardinsmeny

Inte så mycket en standard, men en god praxis, dessa är mycket hjälpsamma och hjälper dig att göra färre kodningsfel.

Till exempel:
Om du vill byta namn på en variabel eller en metod är det bara att använda ”refactor”-alternativet i ditt IDE så ändrar det alla anrop till det metod-/variabelnamnet. Du behöver inte ändra dem en efter en, vilket gör din kod känslig för fel.
Om du vill skapa getter/setter-metoder för alla dina privata variabler använder du bara ”create getter/setter” och IDE skapar automatiskt metoderna åt dig.

API:er är praktiska

”CURRENT SOFTWARE PROJECTS SPEND ABOUT 40 TO 50 PERCENT OF THEIR EFFORT ON AVOIDABLE REWORK”

För att implementera en metod ska du se till att de inte är tillgängliga för dig att använda. Du behöver inte koda om du bara kan importera funktionaliteten. Det gör en utvecklares liv superlätt.
Det berömda talesättet är ”Don’t reinvent the wheel” och det stämmer i många fall. Du bör dock alltid överväga konsekvenserna av att importera ett bibliotek, särskilt om det är från tredje part. Bortsett från eventuella licensproblem kan du bara blåsa upp din kodbas. Om allt du behöver är en metod som konverterar temperaturer behöver du inte importera ett bibliotek som gör det och hundra andra saker.

Parprogrammering/kodgranskning

”PEER REVIEWS CATCH 60 PERCENT OF THE DEFECTS”

Dessa är mycket hjälpsamma när det gäller att refaktorisera din kod. Andra kan se bättre implementering för att optimera din kod eller bara göra din kod elegantare. Det säkerställer också att utvecklarna följer standarderna och att arbetet dubbelkontrolleras. Utöver allt detta är det ett fantastiskt sätt för utvecklare att lära sig av varandra.

BACKUP OCH SPARA DITT ARBETE OFTA

Tillräckligt sagt. Dött batteri, strömavbrott, programvarufel, brand, kärnkraftskatastrof – allt detta kan leda till att data går förlorade. Att se till att du sparar ofta och säkerhetskopierar din kod på någon form av versionskontrollsystem är ett enkelt sätt att se till att din kod förblir säker.

Kodningsstandarder och bästa praxis är ett stort ämne – ett ämne som kan fortsätta på många sidor. Om du någonsin vill läsa på om Java-kodningsstandarder har Oracle faktiskt just det. Tillämpningen av dessa standarder och metoder varierar också beroende på tillämpning – oavsett om du arbetar med ett stort företagsprojekt eller hjälper din lillebror med läxorna. Baserat på många faktorer är det i slutändan upp till dig att se till att den kod du utvecklar är bra kod.

Disclaimer: Alla åsikter eller åsikter som presenteras i det här blogginlägget är enbart författarens och representerar inte nödvändigtvis Aversan Inc.

.