October 2003 - Posts
Niet doen:
private string Test(bool blnTest)
{
string strTest;
if (blnTest)
{
strTest = “True“;
}
else
{
strTest = “False“;
}
}
Wel doen:
private string Test(bool blnTest)
{
string strTest = string.Empty;
if (blnTest)
{
strTest = “True“;
}
else
{
strTest = “False“;
}
}
Want:
Wanneer je binnen een procedure variabelen declareert is de waarde ongedefinieerd, tenzij je deze expliciet toekent. In het bovenstaande voorbeeld is natuurlijk duidelijk dat de variabele altijd een waarde krijgt, dus hier zou je nog over kunnen discussieren.
Maar in grotere procedures is dat niet altijd duidelijk. Je voorkomt een hoop problemen als je zeker weet dat een variabele een correcte waarde heeft. Voor meer informatie hierover, kijk in de C# language specification, sectie 5.3 - Definite assignment.
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.
string compares:
Niet doen:
sTemp == "";
sTemp == "TEST";
sTemp = "Zaad";
if (sTemp > "Test")
{
return sTemp;
}
return "Test";
Wel doen:
sTemp.Length == 0;
sTemp.Equals("TEST");
sTemp = "Zaad";
if (sTemp.CompareTo("Test") > 0)
{
return sTemp;
}
return "Test";
Want:
De lengte van een string checken op 0 (of ongelijk 0) is sneller dan de string vergelijken met ““. Het vergelijken van 2 strings met .Equals is ook sneller dan een vergelijking met, zoals in dit voorbeeld, “TEST“.
De CompareTo method van het String object is 'culture aware'. Het resultaat van deze method is:
- negatief als sTemp kleiner is dan “Test”.
- 0 als sTemp gelijk is aan “Test“
- positief als sTemp groter is dan “Test“
Kijk vooral ook eens naar de documentatie van Microsoft betreffende het string object.
string concatenation:
Niet doen:
public string GetTekst()
{
string sTemp = "Dit is tekst";
sTemp += "Dit ook. ";
stemp += "En dit";
return sTemp;
}
Wel doen:
public string GetTekst()
{
StringBuilder sbTemp = new StringBuilder();
sbTemp.Append("Dit is tekst");
sbTemp.Append("Dit ook. ");
sbTemp.Append("En dit");
return sbTemp.ToString();
}
Want:
Wanneer je met += strings aan elkaar probeert te plakken moet de CLR steeds een nieuwe string alloceren. In bovenstaand voorbeeld dus 3 allocaties. Wanneer je StringBuilder gebruikt wordt er maar allocatie gedaan.
Performance winst dus, zowel qua geheugenallocatie als qua snelheid.
Pascal Naber pointed me to some Microsoft Documents that focus on memory links, which you can find below. The links also contain tips on improving the memory use of your applications.
Original dutch text:
Pascal Naber heeft mij een tijdje terug gewezen op enkele Microsoft documenten die dit onderwerp ook aansnijden. In de links hieronder kun je er alles over lezen. Microsoft geeft daarbij ook tips om geheugen gebruik te verbeteren:
Door alle spin die Microsoft aan het .Net Framework heeft gegeven denken veel developers dat geheugenallocatie geen probleem meer is. “De Garbage collector ruimt alles wel voor me op”. Dat is wel waar, maar alleen als de garbage collector dat kan. Memory leaks bestaan dus nog steeds en hebben nog steeds een negatieve invloed op de stabiliteit van jouw applicatie.
Compuware, de bouwers van Numega DevPartner hebben een heel verhelderend stuk hierover geschreven. Die kun je hier downloaden. Natuurlijk is dat document geschreven om reclame te maken voor hun eigen product. Ze maken echter wel duidelijk waar mogelijk problemen kunnen ontstaan en hoe hun tool je kan helpen om het te localiseren.
In het project bij NS, waar ik nu zit, heb ik in elk geval veel gehad aan dit document en de tool. Deze tool is niet beschikbaar op de vestiging. Maar mocht je interesse hebben in de evaluatie versie, neem dan vooral contact op met yours truly.
Zo, dankzij Dennis ook Jan is aan het bloggen. Ik zal hier mijn ervaringen uit .Net projecten met iedereen gaan delen, bijvoorbeeld met een aantal posts over geheugen problemen in .Net applicaties en hoe je die kan vermijden.
Verder zul je zeer binnenkort mijn ervaringen met Numega DevPartner voor .Net kunnen lezen.