Chociaż pozbyłeś się komentarzy, ich zło się w kodzie wciąż może zdarzyć.

Komentarze z reguły są złe, zamiast nich należy pisać czytelny kod (czyli kod, który czytany wyjaśnia swoje działanie). Są złe bo się dewaluują, tj. po jakimś czasie nie korespondują z kodem, opisują go w nieprawdziwy sposób, bo kod się zmienił. Jest to prawda, której obecnie nie trzeba chyba już nikomu tłumaczyć, przynajmniej tym, którzy trzymają rękę na programistycznym pulsie.

Czy zatem rezygnując z komentarzy oraz pisząc czytelny kod pozbyliśmy się całego ich zła? Niekoniecznie, ono czeka cierpliwie na chwilę naszej niefrasobliwości, by pomimo czytelnego kodu rozpełznąć się po nim. Tak – kod również może zachowywać się jak komentarze. Tyle, że nie może wówczas rościć sobie prawa do nazywania się czytelnym.

Wyobraźmy sobie taki kod:

public void TransferUsers()
{
	ExportUsersInfoToVCard(workingFolder);
	device.ImportVCardsFrom(workingFolder);
	CleanFolder(workingFolder);
}

Kod jest czytelny. Czytając zawartość metody TransferUsers widzimy, że jej działanie polega na eksporcie informacji o użytkownikach do plików vCard (elektroniczne wizytówki), które umieszczane są w folderze workingFolder. Następnie obiekt urządzenia dokonuje importu elektronicznych wizytówek do reprezentowanego przez siebie urządzenia. Na koniec wygenerowane wizytówki są usuwane, ponieważ spełniły swoje zadanie.

Użyta w powyższy kodzie metoda CleanFolder wygląda następująco:

private void CleanFolder(string folder)
{
	DirectoryInfo directoryInfo = new DirectoryInfo(folder);
	foreach (FileInfo file in directoryInfo.GetFiles())
		file.Delete();
}

Ona też jest czytelna – widać, że każdy plik folderu jest usuwany – czyli robi to co opisuje jej nazwa.

Załóżmy, że w pewnych szczególnych warunkach na urządzenie nie trafiają dane o wszystkich użytkownikach. Lider zespołu decyduje, aby zatem opublikować poprawkę, która będzie zawierała zmieniony kod. Wizytówki nie będą usuwane, ale przechowywane dla celów diagnostycznych w dedykowanym folderze. Dzięki temu będzie można stwierdzić, czy problem leży po stronie metody ExportUsersInfoToVCard (będą braki w wizytówkach) czy po stronie metody ImportVCardsFrom (będą wszystkie wizytówki). Chętni do poprawki są wszyscy – to prościzna i będzie miłą odskocznią od innych zajęć. Wybrany szczęśliwiec z pasją zabiera się do pracy i już po chwili metoda wygląda następująco:

private void CleanFolder(string folder)
{
	DirectoryInfo directoryInfo = new DirectoryInfo(folder);
	foreach (FileInfo file in directoryInfo.GetFiles())
		file.MoveTo(diagnostics.BackupFolderForFolder(folder));
}

Właśnie wydarzyło się zło! 😉

Czy metoda CleanFolder nadal robi to, co nazywa? Nie! Owszem folder będzie wyczyszczony, ale gdzieś powstanie jego kopia. Jeśli dodatkowo każde wywołanie tej metody powoduje powstanie dedykowanej kopii, to może to zacząć zaśmiecać przestrzeń dyskową. Oczywiście może być to znikomy problem (to nie są jakieś przeraźliwie duże ilości danych), ale … to dane osobowe – niedobrze, jeśli będą dostępne gdzieś na dysku – zamierzeniem było ich czyszczenie, a kopia powstała jedynie do celów diagnostycznych.

No dobrze – ktoś powie – przecież za chwilę, jak już zostanie zakończona diagnostyka, wszystko wróci do pierwotnej postaci. Hmm, naprawdę? No to pójdźmy tą drogą. Ten sam programista dostał zadanie, aby przywrócić pierwotny kod, ponieważ diagnostyka spełniła swoje zadanie i nie jest on już potrzebny. Niestety z takich czy innych względów nie udaje mu się tego zrobić. Po jakimś czasie lider postanawia sprawdzić czy rzeczywiście zostało to wykonane, zagląda do treści metody TransferUsers i widzi tam wywołanie CleanFolder. Wnioskuje, że wszystko wróciło do normy.

Tak jednak nie jest. Co ciekawe są jeszcze inne możliwe scenariusze. Ktoś może zajrzeć do kodu metody TransferUsers, aby upewnić się, że zawiera on metodę robiącą kopię wizytówek. Ale nie znajduje tam takiego kodu. Zakłada, że nie został on wprowadzony i dodaje swój. Teraz będą się robić dwie kopie. Po otrzymaniu polecenia usunięcia kodu, usunięty zostanie tylko jeden z nich – czyli kopia nadal będzie wykonywana, itd., itp.

Ten przykład być może wydaje się zbyt wydumany, może się też wydawać, że przedstawione w nim zło wcale nie jest aż tak wielkie. No to proszę pomnożyć sobie takie zachowania przez liczbę programistów oraz liczbę metod w kodzie źródłowym. Kropla drąży skałę. Zresztą – niezależnie od własnych zapatrywań – skoro zdewaluowane komentarze to zło, to zdewaluowany kod także, zaczyna on bowiem być nie tyle kodem nieczytelnym, co fałszywym.

Jak zaś napisano „strzeżcie się fałszywych proroków„, na co ja powiadam „strzeżcie się fałszywego kodu” ;).