Jan Schreuder on .Net

.Net code samples, experiences, observations

View my professional profile on LinkedIn

Recent Posts

Tags

News

  • Inappropriate comments will be deleted at my discretion.

    The information and code samples in this weblog is provided "AS IS" without warranty of any kind, either expressed or implied, including but not limited to the merchantability and/or fitness for a particular purpose.

Community

Email Notifications

Tool suppliers

Tools

General

Microsoft

Favorite blogs

Archives

Commentaar in je code

Toen ik de applicatie van de NS aan het controleren was met Numega DevPartner begon deze applicatie te klagen over ontbrekend commentaar in de code. Dit verbaasde me nogal, tot dat ik het volgende constateerde.

Volgens Numega is het volgende niet voorzien van commentaar:

private string testje()
{
   /* Dit is commentaar */
   return “Dit slaat nergens op“;
}

En dit wel:

private string testje()
{
   // Dit is commentaar
   return “Dit slaat nergens op“;
}

Op zich zijn beide opties natuurlijk voorzien van commentaar. Numega vindt echter dat je dus de // moet gebruiken voor in-source commentaar. De /* */ commentaar markers stammen nog uit de oude C wereld. Ze zitten er alleen in om die oude C hackers een plezier te doen.

Ik pas het dus nu aan waar ik het tegenkom. Benieuwd naar jullie reacties.

Comments

Jan Schreuder said:

is numega niet uitbreidbaar met custom rules ?
# October 28, 2003 8:38 AM

Jan Schreuder said:

Ja, numega is uitbreidbaar met custom rules. Je kunt een compleet eigen database bouwen met code review regels. Zo zitten er bijvoorbeeld heel veel checks in die je uit kunt schakelen. Maar je kan ook zelf expressies bouwen waarmee je jouw eigen rules kunt toevoegen.

Of je dat voor deze check moet doen zodat ook commentaar tussen /* */ als correct wordt gezien is de vraag. Je krijgt dan namelijk zo'n wirwar aan commentaar in je code.

Als je Numega hebt geïnstalleerd heb je in het menu de optie "Mange Code Review Rules". Kijk daar maar eens naar.
# October 28, 2003 8:51 AM

Jan Schreuder said:

Zo had ik eens met Ernst de discussie of je alles na bijvoorbeeld een "if" statement tussen 'curly-brackts' { en } moest zetten. Als je namelijk maar één regel hebt, kun je gemakkelijk zo doen:

if (a == 1)
b = 1;
else
b = 2;

Dat is voor mij makkelijk en volgens mij ook gemakkelijk leesbaar. Maar volgens heel veel coding standards mag dat absoluut niet.

En Numega wil bijvoorbeeld ook dat je je connectie altijd 'conn' noemt. Tenminste, die zag ik snel ff voorbijkomen.

Ik zou die /* */ toevoegen in de rules.
# October 28, 2003 11:36 AM

Jan Schreuder said:

Ik ben het op zich wel met je eens over die if statement, maar Ernst heeft wel een punt. Ik heb het vroeger in C projecten helemaal fout zien gaan omdat mensen vooral in grote procedures niet meer doorhadden wat nou wel en wat nou niet bij de "if" hoorde. Zelfde geldt natuurlijk voor "while...", "for ...", etc. Zodoende ben ik een voorstander van curly brackets bij al die statements. Safety first...

Niet iedereen is zo oplettend als jij en ik :-)

Vind wel dat er toch wel een minimale set van code standaards moeten gaan komen. Die hoeven dan niet al te dwingend voorgeschreven te worden, maar kunnen dan wel als basis dienen voor een eventuele review van je eigen of andermans werk.
# October 28, 2003 11:45 AM

Jan Schreuder said:

Gaan we doen voor de SIG!
Ik heb ooit al eens een geweldig document gezien, wat ik nooit meer kan vinden, maar ik ga het toch proberen.

Daarnaast gaat óf DevParter óf FXCop gewoon de waarheid vertellen over je code! ;)
# October 29, 2003 2:54 PM
Leave a Comment

(required) 

(required) 

(optional)

(required) 


Please add 5 and 5 and type the answer here: