Czy musiałeś kiedyś analizować kod napisany przez kogoś innego? Czy było to łatwe zadanie? Domyślam się, że nie. Prawdopodobnie był tam bałagan i ciężko Ci było zrozumieć zamysł autora. A ile czasu zajmuje Ci analiza własnego kodu programu, który napisałeś jakiś czas temu? Czyli wiesz, ile problemów sprawia kod napisany w sposób niedbały. W takim razie pytanie brzmi: jak napisać ten poprawny czyli krótko mówiąc czysty kod. Czym on powinien się charakteryzować? Poniższy wpis zawiera odpowiedź na te pytania.

Czysty kod

Programowanie nazywane jest sztuką, ponieważ dane zadanie może być inaczej napisane przez każdego z nas. Programowanie to też ciągła nauka, jak pisać czytelniejszy i efektywniej działający kod. Te temat nie są praktycznie poruszane w książkach, gdzie opisywane są podstawy programowania. Po pewnym czasie pojawią się pewne nawyki, które już jest bardzo ciężko zmienić. Najlepszym sposobem jest od samego początku tworzenie kodu programu trzymając się kilku dobrych zasad. To właśnie dobry programista trzyma się zasad, które sobie przyjął. Wszystkie jego programy wyglądają tak samo. Po tym rozpoznasz dobrego programistę. Ale jakie są te zasady? Już wymieniam.

Praktyki dobrego programowania

Projektowanie programu

To zagadnienie było poruszane w poprzednich wpisach, czyli w skrócie inżynieria oprogramowania

Moduły

W poprzednim wpisie pojawiły się bloki funkcjonalne. Te bloki można też nazwać modułami. Jak wiesz, jest to zbiór zadań powiązanych w pewien sposób ze sobą. Aby projekt w TIA Portal był przejrzysty, należy stworzyć takie moduły klikając prawym przyciskiem myszy w drzewie projektu na Program block i wybraniu Add group. Pojawi się nowy folder, gdzie należy umieszczać funkcje oraz zmienne wykorzystywane w tym module. Moduł powinien być tak zorganizowany, aby jak najmniej funkcji (funkcję opiszę dokładnie w jednym z kolejnych wpisów) i danych było używane przez inne moduły.

Warstwy

Tworząc programy dla sterowników przemysłowych zawsze będziemy mieć styczność ze sprzętem. Większości przypadków będziemy w jakiś sposób pokazywać przetworzone przez nasz program dane. Dlatego warto cały projekt podzielić na warstwy. Przykładowy podział to:

• Wizualizacja – prezentowanie danych użytkownikom,
• Zarządzająca – kontrola nad wykonywaniem odpowiednich zadań w zależności od sygnałów wejściowych dla niższych warstw,
• Logiczna – główna logika nad wykonywaniem zadań,
• Wykonawcza – wykonywanie zadań już z przetworzonych danych,
• Sprzętowa – połączenie wyższych warstw z fizycznym sprzętem.

Przykładem może być sterowanie silnikiem. Warstwa zarządzająca otrzymuje sygnały o włączeniu i zatrzymaniu. Także informacja o błędach trafia do tej warstwy. Jeżeli wszystko jest w porządku, to następuje zezwolenia dla warstwy logicznej na realizację głównego algorytmu. Wyliczony stan pracy trafia do warstwy wykonawczej, która odpowiada za uruchomienie silnika. Tutaj można również umieścić kod związany ze zmianami prędkości. Warstwa sprzętowa przypisuje określone dane pod konkretne adresy. Czyli warstwa wykonawcza może komunikować się tylko z warstwą logiczną, lub warstwą sprzętową.

Warto dodać jeszcze jedną warstwę związaną z błędami, która może komunikować się ze wszystkimi innymi warstwami.

Liczba warstw zależy od złożoności projektu, lub od założeń projektowych. Moduły, które zostały przygotowane wcześniej powinny być umieszczone w odpowiednich warstwach w zależności od tego, co realizują

Nazewnictwo

Nazwy zmiennych i funkcji nie mogą zawierać słów kluczowych, które są wykorzystywane przez język S7-SCL. Ważne jest, aby nazwy jednoznacznie kojarzyły się z ich zastosowaniem. Można użyć nazwy zmiennej ps lub PredkoscSilnika. Która nazwa jest lepsza? Podobnie postępuj z nazwami funkcji. Nie bądź leniwy. Zamiast nazywać funkcję Get napisz GetRegisteredUsers. Którą nazwę chciałbyś zobaczyć w kodzie?

Najważniejszą częścią nazewnictwa jest przyjęta konwencja. Można nazwać zmienną PredkoscSilnika lub Predkosc_Silnika. Każdy musi sobie przyjąć wygodniejszy sposób i już trzymać się go zawsze. Polecam pierwszy sposób bez podkreślików.

Warto podczas nadawania nazw funkcjom umieścić prefiks modułu lub warstwy, w którym się ona znajduje. Mamy nazwę warstwy Error , więc funkcje możemy nazwać ERR_ResetButton(). Podkreślnikiem oddzielamu nazwę warstwy od nazwy funkcji. Taki sposób nazewnictwa jest bardzo wygodny z intelisence wbudowanym w TIA Portal. Wpisujemy tylko nazwę warstwy (czyli pierwsze trzy literki i wciskamy CTRL+SPACJA) i pojawia nam się cała lista dostępnych funkcji bloków danych dostępnych w tej warstwie lub module. Prefiks pozwala ograniczyć liczbę wyświetlanych funkcji, czyli skraca czas pisania kodu. Należy pamiętać, że w TIA Portal każda funkcja jest dostępna wszędzie (w każdej z naszych warstw czy modułów). Jednak my nie powinniśmy z tego korzystać.

Staraj się, aby nazwy modułów były rzeczownikiem, który jest specyficzny. Dokładnie określa zadanie modułu. Jeżeli dobrze podzieliłeś problem na moduły, to każdy z modułów odpowiada tylko za JEDNO zadanie. Wówczas nie będziesz miał dylematu z nazewnictwem. Jeżeli jest inaczej, przeanalizuj co robi dany moduł jeszcze raz.

Nazwy zmiennych typu Bool powinny w większości sytuacji brzmieć jak pytanie. Czyli zmienną o nazwie Open należy nazwać isOpen. Dzięki temu łatwiej określić stan zmiennej podczas analizy kodu, czy zmienna jest prawdziwa (TRUE) czy fałszywa (FALSE). Zmienne powinny być nazywane w pozytywnej formie. Każdy z nas lubi pozytywne rzeczy, nasz mózg spotykając zaprzeczenie reaguje niekorzystnie.

Dobrym zwyczajem jest pisanie nazw zmiennych i funkcji bez skrótów. Zmienną RegUsr należy zmienić na RegisterUser. Pozwala to jednoznacznie określić przeznaczenie zmiennej.

Komentarze

Stosując zasady opisane powyżej komentarze są pewnego rodzaju dodatkiem. W większości przypadków są stosowane w błędny sposób, ponieważ dla większości programistów są zamiennikiem do zasad, które podałem wcześniej. Zazwyczaj komentarze zamiast pomagać, to mylą. Kod zostaje zmodyfikowany, a komentarz nie. Później pojawia się pytanie, czy błąd jest w kodzie, czy w komentarzu.

Dążymy ogólnie do tego, aby kod był samo komentujący się. Możesz jedynie komentować takie fragmenty kodu, gdzie został zastosowany wyjątkowy trik programistyczny.

– Język -Ostatnia rzecz to język, w jakim jest pisany kod programu. Co wybrać, język polski czy angielski ? Wcześniejsze fragmenty kodu programu (z poprzednich wpisów) były już pisane w języku angielskim. Chciałem Cię częściową oswoić z tą zmianą. Chcę, abyś wyrobił sobie pewien nawyk. Nawyk pisania kodu programu po angielsku. Dlaczego tak? Wcześniej czy później będziesz zmuszony skontaktować się z niemieckim wsparciem technicznym. Wtedy zazwyczaj będziesz proszony o wysłanie całego projektu lub jego fragmentu. Wówczas nie będziesz musiał tracić czasu na tłumaczenie kodu na język angielski. Prawdopodobne także, że będziesz pracował w międzynarodowym zespole programistów. Chyba nie będziesz wtedy pisał kodu w języku polskim?

Ogólna zasada jest taka, że cały kod programu piszemy w jednym języku. Ja piszę w języku angielskim.

Podsumowanie

To są najważniejsze zasady, które powinieneś stopniowo wprowadzać do programów pisanych przez Ciebie. Wiem, że trudno to zrobić od razu. Na pewno złapiesz się na tym, że nie trzymasz się swoich zasad. Wówczas popraw to. Zazwyczaj sprowadza się to niepoprawnego nazewnictwo. Zmień nazwę w miejscu, gdzie tworzyłeś zmienną, tag. Możesz zmienić też nazwę bloku organizacyjnego, bloku funkcyjnego lub bloku danych. TIA Portal pomoże Ci w tym. Nazwy zostaną zmienione wszędzie, gdzie zostały użyte. Nie musisz robić tego ręcznie.

Pamiętaj też, że pisanie czystego kodu to proces. Nie da się tego zrobić w jeden dzień. Małymi krokami udoskonalasz go.

Już po świętach wcielisz się w rolę programisty PLC, który pracuje na obiekcie i uruchamia linię technologiczną. Przygotuj się do pierwszej „delegacji”.

Kurs wideo

Więcej na temat programowania w języku SCL znajdziesz w kursie Sterownik PLC w praktyce: