kommentarer - best practice

3)
void func()
{
  int s= 0; //assign s
}

Sådan gør jeg normalt. Så er man ikke i tvivl om det er den ovenstående eller nedenstående linie man har lavet en kommentar til.

Snowball

Det er absolut mest almindeligt at kommentere ovenover.

Man kommenterer aldrig nedenunder.

Nogle gange kommenterer man bagved som snowball foreslår.

Problemet ved at sætte det på samme linje, vil forekomme hvis man udskriver kildekoden. Det vil blive udskrevet:

...
    int s = 0; // Sindssyg lang kommentar som
bare bliver ved og ved
...

Så er det lige pludselig mere forvirrende, efter min mening...

angak: Det er selvfølgelig rigtigt nok. Der er fordele og ulemper ved alt ;)

conrad: Men skal jeg vælge mellem dine 2 forslag, så vil jeg også helt klart vælge nr. 1 da det virker mest logisk at kommentere den linie man skal til at udføre.

Snowball

jeg var godt klar over 3), problemet er at jeg altid har brugt 1) eller 3) til korte kommentarer, men nu arbejder videre med noget kode som benytter et mix af 1) og 2).

Da det er til skolearbejde ville jeg bare gerne kunne sige "at 1) er valgt da det er beskrevet bla bla microsoft, sun eller lignende" istedet for at sige "1 er valgt da jeg synes det er bedst"

#2 kan på det bestemteste frarådes da det vil forvirre alle der læser
koden.

Men jeg har ikke en referance til en halv-officielt "C/C?+ coding standard"
ligeosm man kender det fra Java.

ok, men mon ikke også det går at skrive at 1) er valgt da det synes at være det mest udbredte og virker mest logisk. Lægger i nogle svar?

http://www.magnux.org/doc/howto/en/C++Programming-HOWTO-16.php
Linksene i bunden ser fine ud.

Jeg kan på det varmeste anbefale doxygen, http://www.doxygen.org
Så har du

/**
  En enkelt linie der beskriver funktionen.
  En mere grundig beskrivelse, hvor du eksempelvis kan skrive at din kommentar
  har en hel del til fælles med klassikeren Krig og Fred. Eksempelvis bruger
  begge alfabetet.

  @return Hvad returnerer funktionen? Kan undlades ved void
  @param Hvad er den første parameter?
  @param Hvad er den anden parameter? Og så videre
  @throw ExceptionType Denne undtagelse kastes når der divideres med nul
*/
int func() {
  int s = 0;
  return s;
}

Altså, spar på kommentarerne inden i selve funktionen. Kommenter kun kodestumper der er besværlige at finde ud af, men lav til gengæld en rigtig god dokumentation af hvad pokker funktionen gør, hvad dens grænseflade er og den slags.

Så kan man med doxygen automatisk lave en hel del dokumentation, ud fra disse mærker (@param og så videre).

soreno>

Der er mange coding standards for C/C++ men problemet er at der ikke er en
officiel/halv-officiel.

Din er ligeså god som enhver andens.

olennart>

Der er vist ingen tvivl om hvor doxygen har fået deres inspiration fra !

:-)

Når det er til en skoleopgave synes jeg,

det ville være en god ide at kigge flere forskellige coding
standarder igennem, altså hvilke fordele/ulemper gruppen
synes der er ved de forskellige coding standarder.

Dernæst laver gruppen sin egen coding standard ved at
kombinere fordele fra flere coding standarder.

Uanset hvilken standard man vælger er det ihvertfald vigtigt at man
overholder den.

Men der er mange forskellige meninger om kommentarer, placering af {,
hvor meget man skal rykke ind, while(1) versus for(;;) etc..

og et svar

gruppen = mig  + 2 månder til aflevering -> - tid til den slags

hvis der er andre end arne der vil have point så læg et svar

Tja, nu du "tvinger" mig ;)

Snowball

arne_v>

Jeps. Javadoc er en udmærket ting, også i C++-verdenen.

Tak for hjælpen