Programmering: C + Java indetering og parenteser

Jeg finder det komplet uacceptabelt at modtage kode hvor programmøren ikke engang har gidet at tab sin kode ind så den er nem at læse. Det kan godt være at det er læseligt det kodeeksempel du kommer med men så snart programmet bare bliver lidt længere og indeholder if-sætninger i 3 niveauer så bliver det håbløst at læse. Derfor giver jeg ret i at din måde at gøre tingene på er korrekt her.

Hvad angår kommentarer er det en omgang lort de fyrer af der. Compileren ignorer kommentarerne og det vil INGEN indflydelse have for det færdige program. På 4. semester på mit studie skal man lave sit eget programmeringssprog og en compiler og jeg kan garantere dig for at kommentarer på ingen måde har indflydelse for det færdige program. Man kan diskuttere om det ikke tager noget tid at ignorere kommentarer men med de computere vi har i dag er det ikke menneskeligt muligt at føle det tid det tager. Så her taber dine venner også.

Hvad angår nødvendigheden af { og } så behøver man kun at gøre det hvis der er mere end en linje det skal gælde. Dog er det normal praksis at man lige tabber den linje ind (i dit tilfælde printf("hvad sker der");) så det er nemt at se at den hører ind under din else.

Og så lige kort om min baggrund. Jeg er 22 år og går på Softwareingeniør studiet på AAU på 5. semester. Mine kommentarer bygger på de erfaringer jeg har derfra. :)

#0
Hvad niveau er i på og hvad erfaring har dine venner for at komme med den omgang sludder? Synes ikke de virker særligt troværdige. :)

Jeg har personlig inge erfaringer med C men med C++ og der har jeg bare taget {} som en selvfølge, de har ca. 2 års erfaring med C og jeg har ca. 1.5 med Java
Så vi er alle newbies :D Og tak for svaret

Jeg er også stoppet på Datalogi for at blive datamatiker i stedet, syntes det virker som om der er mere kodning på datamatikeren

#3
Jeg sætter også bare så mange { og } som muligt da jeg ved jeg alligevel på et tidspunkt nok skal få sat noget kode ind senere og så gider jeg ikke til at rode med at sætte dem der. :)

Efter at have arbejdet en del med javascript har jeg lært altid at bruge {} og altid at have { på samme linje som man afslutter (f.eks. if(..){) . Selvfølgelig også på one-liners if-else. Man brænder virkelig nallerne pga. at javascript er f*cked up på det punkt (*host*return?*host*). Og imho er det også god skik at gøre det i Java/C++/likewise. Og ja, brug da for pokker indent. Det gør koden meget lettere at læse, og som programmør bruger man (desværre) det meste af tiden på at læse og ikke skrive kode...

#3
Jeg er selv uddannet datamatiker for siden at være blevet kandidat på AAU. Ja, der kodes en del mere som datamatiker, men den teori man får på uni kan man ikke opnå som datamatiker.

@5 Jeg har også overvejt at starte igen efter datamatiker, men føler bare ikke lige nu at datalog er det helt rigtige endnu, måske når jeg er færdig med datamatiker

#6
Datamatiker giver også nogle andre muligheder - netværksadmin. etc (det kan man også som datalog, men giver måske mere mening som datamatiker). Jeg selv valgte uni netop for at få lov til at sidde med fingrene i koden :)

Mht indrykning osv. i kode, ville jeg starte her: http://en.wikipedia.org/wiki/Programming_style og begynde at kigge videre derfra. Hvis projektet er bare lidt stort og man skal dele kode, er det klart en fordel hvis i gør tingene ens, også mht. hvad i kalder variable: "showStart", "show_start" eller måske bare "ss". Det har absolut ingen betydning for koden, men gør det klart nemmere at arbejde sammen.

#8
De fleste sprog har jo en kode konvention. Her er Javas:
http://www.oracle.com/technetwork/java/codeconv-138413.html

Jeg sætter stor pris på at kunne se så meget kode som muligt på skærmen ad gangen. Det gør det meget nemmere at danne overblik hvis man har en stor blok med mange nestede statements.
Derfor afskyr jeg konventioner som f.eks. denne fra C# (eller er det blot visual studio der håndhæver det)

if(a)
{
do_something(b);
}


Til oneliners foretrækker jeg denne form

if(a) do_something(b);
// eller denne
if(a) { do_something(b); }


Jeg er også ganske glad for short-cirkuits, hvis de kan holdes simple som denne

max = (a > b) ? a : b;


Ellers benytter jeg denne form

if(a>b){
max = a;
relevant_function()
} else {
max = b;
relevant_function();
}


#9
Min pointe er netop at det ikke er så afgørende hvilken kode konvention man følger. Det afgørende er af man gør tingene ens. Hvis man bliver en del af et etableret projekt, er der måske/højst sandsynlig allerede en kode konvention man skal følge. Men starter man sit eget projekt, kan man undgå indrykning og kalde variablene for navne i ens familie, hvis man synes det er nemt. Derfor vil jeg også mene at det kunne være en fordel at kigge på flere forskellige kode konventioner og så finde det man synes der er nemmest.

Min egen smag er dog meget lig #10 bortset fra at mit hoved fungerer sådan at hvis jeg ser one liners uden {} så tænker jeg "Der er en fejl", lige med det samme, selvom der ikke er det. Så derfor foretrækker jeg at sætte {} og lade som om at der står flere linier.
Kode uden indrykning er meget nemt samme dag, som man har skrevet det, men bare et par uger senere meget svært at finde rundt i.

Lad os starte fra en ende af.. Du bruger selv one-true-brace style. Kig på wikipedia for andre eksempler.

Identering => smagssag. For sprog hvor whitespace ikke betyder noget (ulig Python og til tider F#) så er whitespace uden betydning. I kan gøre nøjagtigt hvad i vil. Når det er sagt vil de fleste konventioner sige at man efter en opening-brace indenterer koden 3-4 spaces.

Comments sløver kompiling af C kode ?
Meget muligt. Jeg sidder i et kursus hvor vi skriver en primitiv micro C compiler (subset af C proper) i F# og møder vi comments så slår vi simpelthen fortolkningen fra (dvs. vi genererer ikke tokens mv.) indtil vi møder en newline char (\n) for singleline comments eller en '*/' for multiline comments.

Comments sløver eksekvering af C kode ?
BULLSHIT! De ignoreres af compileren. Hvad der derimod kan sløve dit program er at compile det med debugging symbols (gcc -g prog.c -o prog) -- dette gemmer en del ekstra information så at du i en debugger kan sige hvad variablerne hedder, hvilken linje du er på i source-filen etc.

Det skulle være det. Generelt vil man altid blot blive enige om en kodekonvention fra starten af. Det omhandler brace-style, indentering samt navngivning af funktioner og variabler.