Objective-C – jakość kodu i coding guidelines.

Komercyjne projekty programistyczne realizowane w 1 osobę nie są czymś częstym w dzisiejszym świecie. Sporo klientów chce czegoś na wczoraj, w jak najlepszej jakości. Żeby dostarczyć dobrej jakości oprogramowanie, tworzone przez zespół, należy stosować wiele środków. Projekt musi na samym początku mieć dobrze zdefiniowane wymagania, musi być dobrze i w miarę szczegółowo zdefiniowany i zaplanowany. Na końcową jakość wpływ ma też bardzo wiele czynników. Dziś chciałem poruszyć 1 z nich: coding guidelines.

Wytyczne co do tego jak pisać kod programu i przestrzeganie tych wytycznych jest niezmiernie ważne. I jeszcze ważniejsze staje się, gdy rośnie wielkość zespoły w projekcie. Przy 2 osobwach, mamy max 2 style pisanie kodu, przy 10 osobach: 10 różnych. Wykonywanie przeglądu kodu, poprawianie błędów, rozszerzanie funkcjonalności, utrzymywanie kodu napisanego przez kogoś innego nie jest proste, a staje się jeszcze trudniejsze, jeśli ktoś ma „dziwny” styl pisania kodu, który nie jest dla nas znajomy. Wdrożenie 1 stylu kodowania w zespole może mieć tylko pozytywne rezultaty. Te kilka zdań wstępu tyczy się nie tylko języka Objective-C, ale też wszystkich innych języków programowania.

Dla języka Objective-C i framework’a Cocoa takie reguły i konwencje zostały już spisane, zobacz tutaj: Cocoa Coding Guidelines. Na prawdę radzę, aby przeczytać i stosować reguły opisane w tym dokumencie. To może wyjść tylko na dobre.

Oprócz dokumentu od Apple, znam jeszcze jeden, też sensowny, choć niektóre elementy z niego mi nie pasują do końca, np wcięcia o szerokości tylko 2 spacji. Chodzi mi o coding guidelines dla raywenderlich.com opisane tutaj. Przeczytaj, wybierz coś dla siebie i stosuj na co dzień, Ty i Twój zespół.

Przedstawione dziś 2 dokumenty, to jedynie część istniejących zaleceń. Styli kodowania jest wiele i każdy ma swoje ulubione reguły oraz reguły, za którymi nie przepada. Ważne, aby wybrać zbiór reguł które przestrzegamy i zbiór elementów, które są antyprzykładami i których nie wolno stosować. Następnie, ważne jest to, aby zespół w którym pracujesz miał te same zbiory reguł.  Spójny kod, to łatwiejszy proces tworzenia i utrzymywania aplikacji. Skutkiem tego jest też lepsza jakość produktu końcowego.

Czy stać Cię, aby nie mieć i nie stosować coding guidelines?

 

Dodaj komentarz