Citat:
Ursprungligen postat av
RostigHink
Som en liten fotnot när man jämför variabel med konstant så skriv hellre if (konstant == variabel), då fångar man enkelt annars svårfunna buggar som if (variabel = constant).
Jag håller med helt och hållet, - Man tycker att kompilatorn skulle varna tex
"Implicit conversion of int to bool" men i C/C++ kan en int ses som en bool ändå,
Jag har sett kod där man använder makron istället vilket minskar risken för felskrivning, tex:
#define AND &&
#define EQ ==
men det försvårar ju att man tar in annan kod som är skriven på traditionellt sätt.
Citat:
Ursprungligen postat av
Annaconda
Kan bara hålla med! Konstigt att jag aldrig sett detta tips förr!?
Ang. GOTO... Jag har faktiskt använt det vid några speciella tillfällen då min kod har blivit alltför svår att överblicka pga massor av if-else if-else if-else if-.... (jag tror i alla fall att så var fallet).
Jag har då alltid hoppat till slutet av den långa if-else-historien (innan return) och alltid benämnt labeln "end<myfunction>".
ETA: "Senast redigerad av christery år 2498 kl. -07:62"! Du lurade mig för ett ögonblick...
Ja riktigt - ja sådana där långa
if -- else sekvenser kan bli snåriga, särskilt om if satsen innehåller flera villkor som måste vara uppfyllda. Ibland kan man istället städa upp sådan
if-else-spaghetti med att använda flaggor istället, en flagga kan tex vara en
enum typ och man kan lägga testandet i en
switch sats istället. Det gör kanske den logiska delen av koden mer komplicerad, men utförandet ser mer överblickbart och snyggare ut.
För sådan programkod som har mängder av villkor i sina if-satser så kan det alltså vara lönt att använda flaggor istället, det innebär att man bara behöver testa alla villkoren en gång, så sätter man flaggan och sen behöver man bara testa på flaggan, det spar några CPU-cykler.
Å andra sidan så kan man ju göra koden ännu rörigare med hjälp av flaggor särskilt om man blandar metoderna hux flux, då begriper ingen vad som menas nä.