Next vs }

[Palle500]

Man får intrycket att utvecklarna av C har lagt över mycket på programerarna
för att underlätta sitt eget arbete.

Ja? Allt arbete ligger på programmerarna. Det är de som skall lösa uppgiften med hjälp av programmering, inte tillverkaren av programmeringsspråket.

C ligger väldigt nära assembler. Om man har programmerat i något assemblerspråk tidigare så förstår man direkt hur hur C fungerar.
Loopar, villkor, shift/rull, pekare med basregister, bitmaskning m.m., allt har sina exakta motsvarigheter i assembler.

Vilket gör C så kraftfullt, men samtidigt är risken att "göra fel" större då du måste veta vad du gör, kompilatorn/språket erbjuder få hängslen/livrem/begränsningar.

Vad sägs om det här

} // End if

} // End While

osv.
Enkelt och obyråkratiskt

Mycket bra.
Själv skriver jag typ
} /* endif koll*/
} /* next xpos */
} /* wend pollareg */
då jag programmerar i C och inte C++ och jag lägger gärna till variabeln det handlar om.

Håller med jag gör även så att jag låter vilkoret/variabelnamnet bli en remark.
Problemet med detta är när flera underhåller koden då finns det vissa som struntar i att kommentera och ibland även kopierar en befintlig kommenterad if sats som stome och ändrar massor men struntar i att radera/rätta kommentarerna. Då bli det svårläst!

[hummel]

Pepparkakor är ju gott. Speciellt så här års.

Vad sägs om det här

} // End if

} // End While

osv.
Enkelt och obyråkratiskt

Det är felindenterat, vilket gör det svårläst. Kan nog vara ditt problem att du inte får till indenteringen bra och riktigt förstår dess funktion.

Kod: Markera allt

	}  // End if

}  // End While 

[bjornj]

Det var inte tänkt som indentering. bara ett exempel.
Jag tror nog jag förstår indentering efter många års
programerande

[mankan]

Låter som OP ska prova Python där indentering är definierat av språket. Visual Basic har jag inte rört sedan sent 90-tal, redan då med dess ca tre olika null/nil/0 kunde man lätt tröttna.

[baron3d]

Och jag skriver:
} // end if koll
} // end for i
} // end while x

[AndLi]

Du kan ju predefinera i en H fil så får du en bättre överblick

#define IIF {
#define ENDIF }
#define CASE {
#define ENDCASE }
#define WHILE {
#define ENDWHILE }
#define FOR {
#define ENDFOR }
#define EQ ==
#define OR ||
#define NOT !
#define AND &&

Det där är ju ett extremt effektivt sätt att förvirra vilken rutinerad programmerare som helst när de ska försöka hjälpa en nybörjare....
Och sannolikt även förvirra de flesta editorer också som försöker hjälpa en..

Den lösningen är från 1990 när jag gick från Pascal till C och då var det utmärkt för mig. Och då körde jag med en texteditor som inte stödde olika programspråk. Sen vet jag inte om man måste skriva kod som kan läsas av vemsom? Det är ju inte det som är problemet idag utan idag handlar det mest om att få till de olika miljöerna och syntaxfiler som skapar projekten. Detta är klart svårare för en nybörjare att förstå.
Men nu frågade ju TS efter ett sätt att få översiktligare kod inte portabel kod.

Portabel kommer väl koden vara då #define har varit en del av C standarden rätt länge.
Visst kan man skriva kod som man själv bara förstår, men det verkar väl troligt att TS kommer ställa fler frågor om programmering på forum framöver, och då posta exempel på sin kod.
Då kommer många fler läsa och sätta sig in i koden om den håller ett standardmässigt utseende.
Så jag tror det kan vara en vinst att skriva kod som kan läsas av vem som...

[papabear]

Och jag undviker kommentarer så mycket som möjligt.
Att kommentera slutklamrar för block skulle aldrig falla mig in.
Bara mer att underhålla, och som dessutom inte kontrolleras av kompilatorn vilket gör det lätt att missa att uppdatera.

Om vi nu tar exemplet med att kommentera slut av block.
Säg att man börjar med

Kod: Markera allt

for(...)
{
   ...
} //end for

Sen kanske det ändras till

Kod: Markera allt

while(...)
{
   ...
} //end for

Ojsan hoppsan, nu ljuger kommentaren.

Men det händer att jag använder kommentarer om det tex är svårt att utrycka sig tydlig med koden, men i de flesta fall går det att refaktorera och bryta ner kod i mindre namngivna delar (metoder, funktioner, och vettiga variabelnamn).

Av den anledningen har jag också sett till att byta färg på alla kommentarer. Så istället för en mysig, lugn mossgrön som verkar vara standard i så gott som varje editor har jag satt den till mangenta. Vilket i kombination med att jag kör mörka teman på mina program får kommentarerna att hoppa ut och hugga en i ögonen. Om det finns en kommentar så är det för att den är viktig och ska inte bara kunna ignoreras.

"Men kommentarer hjälper när man kommer in i ett nytt projekt eller tar upp ett gammalt"
Nja, visst, ibland. Just för att det är så lätt att missa att uppdatera kommentarer när kod ändras. Ibland ändras koden, eller så kryper det in andra rader mellan kommentaren och den kod den gäller. I många fall där jag kommit in i ett okänt projekt som måste sätta mig in i så har kommentarerna varit missvisande eller helt fel. Säkert inte när de skrevs, men affärsregler kan ha ändrat eller hur något implementerats. Hellre läsbar kod än kommentarer.

Ett exempel där kommentarer kan vara behövliga när man behöver optimera kod, vilket kan leda till komplex och ovanlig kod, men det knyter samtidigt tillbaka till regeln om att bara ha kommentarer där det behövs.

Det finns så många bra gratis editorer/IDE:er för alla plattformar med stöd för formatering och färgläggning som gör skrivande och läsande av kod lättare. Använd nån av dem.

edit:
Ska tillägga att jag inte sitter och skriver i c/c++ hela dagarna, och när man skriver för µC:er så tenderar det att kunna bli en hel del bitmanipulering och annat som mycket väl kan behöva kommenteras.

[AndLi]

Som en gammal kollega sa till mig när jag fick ett antal rader tusen rader C-kod i knäet utan en enda kommentar.
"C-kod är självkommenterande"

Och visst kommer man från Assemblervärlden så är det väl så
Men gör man som de gjort i den koden och kallat variablerna k1,k2,k3 och k4 och ändå lyckats skapa +120 tecken långa if satser så vet jag inte om jag håller med längre.
Variablerna återanvändes också till olika saker, säkert för att "spara" minne...

Men bra döpta funktioner med bra variabelnamn och tydlig kod så blir det enklare för alla och man kan slippa kommentarer som behöver uppdateras (som aldrig verkar ske..)

[kodar-holger]

Den som tycker att C-kod, eller kod i vilket språk som helst för den delen, är självkommenterande har inte förstått varför man skriver kommentarer. Man skall inte kommentera vad man gör utan varför man gör det man gör. Så den personen borde skiljas från all hantering av programkod.

Och jag håller med om att C(++) har fler problem än det löser och det är tragiskt att det (och git och unix) blivit den standard så många av världens programmerare håller högt. Job security?

I veckan hittade jag en bugg som funnits i vår kod sen 2002, och kan inte riktigt förlika mig med att ingen version av alla de kompilatorer vi gått igenom på 18 år ens bemödat sig en varning för detta.

Kod: Markera allt

Klass* pekare = annanPekare->getPointerToSomething();
bool resultat = pekare-getStatus();

där getStatus är en funktion definierad som en bool i både aktuell klass och den klass man pekar på.
Jag stegade mig genom koden gång på gång och kunde inte förstå varför jag hamnade i fel getStatus hela tiden. Började nästan tro på troll och gröna män i koden. Tills jag såg felet.
Hur kan det över huvud taget vara tillåtet att subtrahera en bool från en pekare. En total gåta! Men grunden ligger väl i att C(++) i princip är ett helt otypat språk. Allt är bara heltal överallt som det är upp till användaren att tolka om till något annat. Kompilatorn vill inte ha något som helst med det att göra. Kan tilläggas att vi kör Visual Studio 2019 med W4. Wall går inte pga Qt, men vet inte om det skulle hjälpa.

[Jan Almqvist]

"Hur kan det över huvud taget vara tillåtet att subtrahera en bool från en pekare. En total gåta!"

Eftersom din bool förmodligen bara är en förklädd int?

Kod: Markera allt

#define bool int

[hummel]

Hur kan det över huvud taget vara tillåtet att subtrahera en bool från en pekare. En total gåta! Men grunden ligger väl i att C(++) i princip är ett helt otypat språk. Allt är bara heltal överallt som det är upp till användaren att tolka om till något annat. Kompilatorn vill inte ha något som helst med det att göra. Kan tilläggas att vi kör Visual Studio 2019 med W4. Wall går inte pga Qt, men vet inte om det skulle hjälpa.

Gimpel PC-Lint plockar nog den.

[Frossa]

Hur kan det över huvud taget vara tillåtet att subtrahera en bool från en pekare. En total gåta! Men grunden ligger väl i att C(++) i princip är ett helt otypat språk.

I de flesta språk kan du enkelt kolla om en pekare faktiskt pekar på ett minne eller null

Kod: Markera allt

if(ptr)

Och därför behöver kompilatorn kunna omvandla från pekare till bool utan att klaga, annars hade man fått varningar eller fel varenda gång. Finns med i standarden för både C och C++ har jag för mig.
Du kan kolla det här blogginlägget som jag satt och läste igår(https://vector-of-bool.github.io/2020/1 ... -bool.html), vilket tar upp lite angående strong/weak typing av språk osv.

Jag håller inte med om att modern C++ är otypat, det är faktiskt ganska så strikt och slår du på -Wall på moderna kompilatorer får du rejält med varningar om du inte använder rätt static_cast osv.