Artykuł

freeimages.com freeimages.com
sty 23 2015
0

6 rzeczy których nie lubię w kodzie

Będąc programistą, bardzo często mam styczność z kodem innych. Jest to naturalne, bo nawet jeśli nie pracuję w danym momencie zespołowo, to i tak mogę wykorzystywać rozwiązania stworzone przez moich współpracowników, bądź też po prostu takie, które znalazłem w sieci. W wielu przypadkach są to dobre i przemyślane rozwiązania, ale czasem zdarzają się takie, które najchętniej od razu bym zrefaktoryzował.

Widziałem już w życiu tysiące linii kodu, który wyglądał lepiej, lub gorzej. Na tej podstawie postanowiłem wyłuskać 6 złych przykładów, których osobiście staram się unikać. Oczywiście tego typu rzeczy robiło wielu z nas, nie ma przy tym powodu do wstydu - każdy się przecież uczy. Ważne jest jednak by z tej nauki wyciągać racjonalne wnioski. Ułatwi to życie innym oraz Wam samym w momencie gdy przyjdzie Wam do tego kodu wrócić;-)

Oto mój TOP 6 rzeczy, których nie lubię w kodzie innych.

1. Bałagan w nazewnictwie

Przypadek bardzo popularny u początkujących programistów, a także w polskich tłumaczeniach książek... O co dokładnie chodzi? Przede wszystkim o niekonsekwencję w nazewnictwie zmiennych, funkcji i obiektów. Wielokrotnie już widziałem kod, w którym to niektóre funkcje nazywane są po polsku, a inne po angielsku. Czasem widziałem nawet kwiatki typu makeUmowa itp.

Osobiście jestem zwolennikiem angielskiego nazewnictwa zmiennych. Króluje ono w większości firm i co by tu rzec, angielski to uniwersalny język w IT. Pewien niepisany standard.

2. Bałagan w strukturze klasy

Tworząc klasy staram się logicznie rozkładać umieszczony w nich kod. Ostatnio bardzo lubię korzystać z regionów, który przydatne są np. przy implementacji interfejsów. Dużo uwagi poświęcam również należytemu porządkowi w klasach. Przede wszystkim dbam oto, by wszystkie pola klasy zawsze były na górze. W dalszej kolejności pojawia się konstruktor i metody. Pola oraz metody uporządkowane są według modyfikatorów dostępu w kolejności public - protected - private. Idealna klasa wygląda mniej więcej tak:

public class MyClass : MyInterface
{
	public const string constString = "example const string";
	private object myMagicObject = null;
	
	public MyClass()
	{
	}
	
	#region MyInterface implementation
	public ExampleMethodA()
	{
		this.DoSomeMagicA();
	}
	
	public ExampleMethodB()
	{
		this.DoSomeMagicB();
	}
	#endregion
	
	protected MyMagicObject
	{
		get
		{
			return this.myMagicObject;
		}
	}
	
	private void DoSomeMagicA()
	{
	}
	
	private void DoSomeMagicB()
	{
	}
}

3. Wiele odpowiedzialności jednej klasy

Jednym z poważniejszych problemów, który zdarza się nawet najbardziej doświadczonym deweloperom, to problem wyznaczenia odpowiedzialności klasy. Sam niejednokrotnie tworzyłem klasy, które zawierały setki linii kodu. Za każdym razem zadawałem sobie pytanie, czy na pewno to wszystko musi być w tym miejscu? Im dłużej będziemy programować, tym mniej takich klas napiszemy. Są jednak pewne sytuacje, w których taki błąd idzie popełnić stosunkowo łatwo. Chodzi mi tu przede wszystkim o aplikacje wykorzystujące interfejs graficzny.

Z pewnością wielu z Was korzystało kiedyś z Windows Forms. Formsy opierały się głównie na event handlerach podpinanych do poszczególnych kontrolek. Kiedyś MVVM nie był taki popularny i wiele prostych aplikacji zbudowanych w oparciu o tą technologię, zawierało niekończący się ciąg metod, reagujących na wszystkie zdarzenia użytkownika. Łatwo tutaj było przekroczyć magiczny tysiąc linii, oj łatwo... Na szczęście teraz mamy WPF, Silverlight, Universal Apps, MVC i inne fajne rozwiązania, który sprzyjają logicznemu podziałowi kodu.

4) Nadużywanie IFa

IF jest bardzo przydatną instrukcją warunkową, która niejednokrotnie może rozwiązać wiele problemów. Nieodpowiednio użyty może jednak obniżyć jakość oraz czytelność kodu. Dlatego bardzo często lepszym rozwiązaniem jest wykorzystanie konstrukcji switch, zastosowanie słownika, bądź też w bardziej rozbudowanych przypadkach - wykorzystanie wzorca strategii. Poniżej przykład z przekształceniem do konstrukcji switch:

public class TestClass
{
	public string BadMethod(int input)
	{
		string retString = string.Empty;
		if(input == 0)
		{
			retString = "A";
		}
		else if(input == 1)
		{
			retString = "B";
		}
		else if(input == 2)
		{
			retString = "C";
		}
		return retString;
	}
	
	public string BetterMethod(int input)
	{
		string retString = string.Empty;
		switch(input)
		{
			case 0:
				retString = "A";
				break;
			case 1:
				retString = "B";
				break;
			case 2:
				retString = "C";
				break;
		}
		return retString;
	}	
}

5) Nic nie mówiące nazwy

Bardzo trudno jest nazwać zmienną czy metodę w taki sposób, by jej nazwa była najlepszym opisem jej zastosowania. Oczywiście wszystko zależy od kontekstu i sytuacji. Przeznaczenie metody o nazwie Run w klasie BackgroundTask jest dość jasne. Co innego można powiedzieć za to o metodzie MakeString w klasie Person.

Jeśli zgodnie ze sztuką tworzymy krótkie klasy, o jasno wytyczonej odpowiedzialności (patrz pkt 3), to dużo łatwiej będzie nam stworzyć również odpowiednio nazwać metody, które będą krótkie, zwarte i będą realizowały proste, określone zadania.

Jeśli Wasza klasa musi mieć jedną główną metodę, to skorzystajcie z wzorca kompozycji i rozbijcie jej kod na wiele mniejszych metod, które będą wykonywać proste i krótkie zadania.

6) Brak stałych

Inną bolączką którą można znaleźć często w kodzie, są wartości nie przypisane do zmiennych/stałych w momencie gdy naprawdę powinny tam być. Najlepszym tego typu przykładem są wszelkie niezmienne kwoty, procenty, adresy, adresy sieciowe itd.

Jeśli jakiś element pojawia się w dwóch różnych miejscach, to naprawdę warto go przenieść do stałych.

Stałe najlepiej trzymać w jednym miejscu. Może to być statyczna klasa Constants, plik web.config, czy też specjalna tabela w bazie danych. Możliwości jest sporo;)

Data ostatniej modyfikacji: 24.01.2015, 11:14.

Podoba Ci się ten wpis? Powiedz o tym innym!

Send to Kindle

Komentarze

blog comments powered by Disqus