Podstawy: Zmienne lokalne cz. 1

Dobrym nawykiem, jaki sobie przysposobiłem przez lata kodowania, jest używanie pragmy use strict. Pewnie, że można dla prostych skryptów jej nie włączać, ale nawet wtedy unika się głupich literówek i prostych błędów.

Lubię pomagać znajomym, gdy szukają błędu w swoim programie. Mam jednak dwie żelazne zasady: nie ruszam kodu, który nie ma wcięć i takiego, który nie ma deklaracji zmiennych. Z tym pierwszym może poradzić sobie w Perlu perltidy, a drugiego pilnuje właśnie use strict.

Zmienne lokalne są ograniczone do bloku { ... }. Co ciekawe, częścią bloku są także instrukcje sterujące, czyli foreach albo while:

Od wersji Perla 5.9.1 lokalną zmienną może być także zmienna specjalna $_. Mamy wtedy gwarancję, że nic nam jej przypadkowo spoza lokalnego bloku nie nadpisze:

Najlepszą cechą zmiennych lokalnych jest to, że ich użycia pilnuje kompilator. To jeszcze na etapie kompilacji i to jako błąd fatalny zostanie zakomunikowany nam przypadek użycia zmiennej, której wcześniej nie zadeklarowaliśmy:

Z deklaracją zmiennych lokalnych trzeba uważać, bo operator my nie jest zachłanny i łyka wyłącznie jeden parametr. To oznacza, że można go użyć bez nawiasów, np. jako parametr funkcji open:

Ten kij ma dwa końce i trzeba uważać na subtelny błąd, który można popełnić przy deklarowaniu więcej niż jednej zmiennej na raz:

Takie coś powinno zostać na szczęście wykryte za pomocą pragmy use warnings, które nam podpowiada, że my powinno być użyte z nawiasami. Wymuszony wtedy będzie kontekst tablicowy:

Z dokładnie takiego samego powodu trzeba użyć nawiasów przy odbieraniu argumentów funkcji ze zmiennej @_:

Ze zmiennymi lokalnymi w Perlu trzeba uważać, aby nie pojawiły się dwie takie same w jednym bloku. Druga deklaracja nie niszczy poprzedniej instancji, a jedynie ją przesłania:

Tutaj też use warnings poradzi nam, że "my" variable $fh masks earlier declaration in same scope at -e line 1., więc lepiej tego nie robić.

Co innego, gdyby użyć dedykowanych bloków:

No dobrze, ale właściwie po co ta cała zabawa w zmienne lokalne? Cóż, znam kilka programów, i to na parę tysięcy kodu, gdzie wszystko jest oparte o zmienne globalne. Niestety, są już kompletnie niemodyfikowalne, właśnie z tego powodu. Pół biedy, jeśli to Perl, ale w takim PHP zmienne potrafią pojawić się w środku pliku, a co gorsza mogą zawierać jakieś wartości nie wiadomo skąd. Zapewne z jakiegoś ciasteczka, a może formularza, a może cholera wie co jeszcze...

Start

Dlaczego nowy blog? Tyle razy już zaczynałem i kończyło się góra po trzeciej notce... Cóż, okazuje się, że Perl to jest moje najważniejsze hobby i zasłużyło na specjalne potraktowanie. Tym razem jako osobny blog, a nie jakaś tam kategoria na blogu prywatnym. 

Dlaczego Perl?

Każdy człowiek musi się jakoś realizować artystycznie. Zbieranie znaczków, robienie modeli samolotów, brzdąkanie na gitarze, klejenie bitów w Abletonie albo pikseli w Paincie: różne są sposoby na wyrażenie siebie i tworzenie piękna. Nie wiem dlaczego, ale akurat mi najwięcej frajdy sprawia dzierganie skryptów w Perlu.

To raczej egzotyczny czy też ezoteryczny sposób ekspresji artystycznej. W finale "Mam Talent" na pewno się nie pojawię. Nawet żonie nie byłbym w stanie wytłumaczyć, co w tym jest takiego fascynującego. A jednak jest w tym wszystkim takie subtelne piękno. Gdyby nie to, dawno bym się zajął czymś ciekawszym.

Może uda mi się tu wyjaśnić, co takiego ma ten akurat język, co sprawia, że nawet w 2012 roku jest on wciąż atrakcyjny. Języki ewoluują: powstają wciąż nowe, stare umierają. Są jak memy, które walczą między sobą o uwagę umysłu programisty. Czy mem Perla jest na tyle silny, aby przetrwać w dzisiejszym nieprzyjaznym środowisku?

Po 12-tu latach nie do końca sam wiem, czy to hobby czy praca, bo granice się zacierają. Warto to jednak rozgraniczać, bo swoją pracę kiedyś trzeba skończyć i oddać komuś, kto potrzebuje czegoś gotowego i działającego, a hobby to nieustający proces tworzenia, poprawiania i eksperymentowania. Perl umożliwia jedno i drugie, stąd po pracy nadal mam chęć robić niby to samo co w pracy, ale przecież zupełnie inaczej.

Dwanaście lat to kupa czasu. Wracam czasem do starych programów. Github? Kiedyś go nie było. Prawdziwą rewolucją był SourceForge. Gdzieś tam w jego archiwach czają się moje skrypty. Czy aż tak bardzo różnią się od tego w jaki sposób teraz koduje?

Jak każdy zapoznający się z dowolnym językiem programowania, przeszedłem przez ileś-tam etapów:

1. Poznawanie języka: tworzenie programów na zasadzie kopiowania cudzych fragmentów, metodą prób i błędów, oraz nieporadnego kalkowania kodu z innego języka.
2. Nauka idiomów i wzorców charakterystycznych dla danego języka: na tym etapie nabieramy indywidualnego charakteru programowania, a wciąż popełniamy błędy, wynikające z niewiedzy lub lenistwa.
3. Zachłyśnięcie się możliwościami: nadużywanie atrakcyjnych cech języka, przekładanie formy nad treścią, golf, JAPH i inne potworne zabawy z językiem.
4. Dopracowywanie swojego warsztatu: znane są już pułapki języka, powstają porządne i użyteczne programy, do których można wrócić nawet po latach, znamy swoje możliwości jako programisty.
5. Eksperymentowanie: szukanie nowych możliwości, narzędzi języka, wypróbowywanie nowych paradygmatów programowania, poszerzanie swojej wiedzy.

Czy trzeba przejść je wszystkie? Wydaje mi się, że wiele osób zatrzymuje się w połowie drogi i nie potrzebuje dalszych etapów, aby np. dobrze wykonywać swoją pracę. Chyba, że to już nie jest tylko praca, tudzież krótki epizod do zaspokojenia swojej ciekawości.

Nie lubię określenia "guru". Niesie ze sobą jakieś złe skojarzenia: człowieka oderwanego od rzeczywistości, przekonanego o swojej nieomylności. Jest wielu takich ludzi w branży IT, którzy zatracili się w swojej arogancji: dobrzy koderzy, ale fatalne osobowości. Mam nadzieję, że nie czeka mnie taki los. Chyba wolałbym się kiedyś określić słowem "sensei". Składa się na to słowo zarówno czas poświęcony na poznanie jakiejś dziedziny jak i chęć przekazywania swojej wiedzy innym.

Po to właśnie ten blog: chciałbym w nim pokazywać różne ciekawe rzeczy związane z Perlem, ale nie po to aby narzucić swój właśny sposób myślenia, a raczej po to aby przekonać, że Perl jest warty głębszego poznania. Niniejszym zapraszam :)