Wygląda na to, że przez lata wywoływałem niepokój z powodu mojego kontrowersyjnego stanowiska, że Option Explicit nie jest przydatne w VBA. Przypomniało mi się to niedawno, kiedy przeprowadziłem sesję przez Skype podczas Excel Weekend of Brazil. Napisałem książkę o Excel VBA dla QUE. Ta książka została przetłumaczona na portugalski na rynek brazylijski. Najwyraźniej przez 15 lat uczyłem wspaniałych ludzi w Brazylii o Excel VBA. Teraz, gdy jestem 15 lat starszy i mądrzejszy, przyznam, że mogą istnieć dobre powody, aby użyć Option Explicit.
W Notre Dame brałem udział w kursach biznesowych z dużą koncentracją na programowaniu. W dziwnych okolicznościach wziąłem udział w każdym kursie programowania w ND, zarówno w szkole inżynierskiej, jak i biznesowej. Nauczyłem się języka Fortran, Pascal, Assembler i COBOL. Kochałem programowanie. Te kursy programowania uratowały mi GPA i uchroniły mnie przed wyrzuceniem. Kiedyś nasi profesorowie powiedzieli nam, że przed rozpoczęciem kodowania musimy zaplanować nasz program i ręcznie narysować schematy blokowe. Byłem buntownikiem. Najpierw napisałem program, a potem narysowałem schemat blokowy, gdy skończyłem.
Pierwsze 18 miesięcy mojej kariery spędziłem na pisaniu programów w języku COBOL. Ale potem przeniosłem się do finansów i spędziłem dziesięć lat w finansach i księgowości. Zajmowałem się głównie księgowością, ale kiedy musiałem napisać jakiś kod, wiedziałem wystarczająco dużo, aby napisać kod.
Zaprogramowałem makra w Lotusie 1-2-3, a następnie zacząłem pisać makra VBA po przejściu na Excela w 1995 roku. W tym momencie nadal byłem buntowniczy: deklarowanie moich zmiennych z wyprzedzeniem wydawało się zbyt podobne do rysowania schematu blokowego przed napisaniem kodu. Nigdy nie planuję z wyprzedzeniem. Zanurz się. Zacznij programować. Jeśli potrzebujesz nowej zmiennej gdzieś po drodze, po prostu ją utwórz.
Byłem buntownikiem, najpierw pisałem kod, a później rysowałem schemat blokowy Deklarowanie zmiennych, jak argumentowałem, jest dla programistów formalnych. Jeśli pracujesz w księgowości i po prostu usuwasz 20 linii kodu, nie ma powodu, aby deklarować zmienne z wyprzedzeniem.
Moje stanowisko w tej sprawie skłoniło mnie do przyjacielskich kłótni z innymi ekspertami Excela. Jordan Goldmeier. Bob Phillips. Cristiano Galvão.
Po pierwsze, zawsze zalecałem deklarowanie zmiennych obiektów. W poniższym kodzie WSD jest zadeklarowane jako arkusz i przypisane za pomocą polecenia Set. Jeśli deklarujesz zmienną obiektu, możesz przeglądać wszystkie właściwości i metody, wpisując zmienną, po której następuje kropka.
Nie używając Option Explicit, ryzykujesz błędy ortograficzne. W poniższym kodzie tworzona jest zmienna o nazwie FinalRow. W następnym wierszu prawdopodobnie zamierzałem wykonać pętlę od 2 do FinalRow, ale błędnie wpisałem zmienną jako Fina1Row.
Bez Option Explicit ktoś może nie zdawać sobie sprawy, że istnieje literówka. Zmienna FinalRow może zawierać 100. Ale kod wewnątrz pętli nie zostanie wykonany, ponieważ zmienna Fina1Row nigdy nie została zainicjowana i będzie zawierać zero.
Aby zapobiec frustracji związanej z debugowaniem kodu z potencjalnymi błędami pisania, możesz otworzyć Narzędzia, Opcje w menu VBA. Wybierz pole Wymagaj deklaracji zmiennej pokazane poniżej.
Wszystkie przyszłe moduły będą rozpoczynać się wierszem z napisem Option Explicit. Będziesz musiał dodać nowe wiersze u góry makra definiującego zmienne FinalRow i i. Program Excel nie powie Ci o błędach w pisowni, dopóki nie spróbujesz uruchomić makra. Następnie powiadomią Cię, że zmienna nie jest zdefiniowana.
Więc to jest twoja decyzja. Jeśli nie masz nic przeciwko planowaniu z wyprzedzeniem i deklarowaniu wszystkich zmiennych, będziesz mieć sieć bezpieczeństwa VBA, która poinformuje Cię, jeśli nieprawidłowo wpisałeś zmienną. Dla mnie wolę dreszczyk emocji związany z debugowaniem kodu po jednym wierszu na raz i samodzielnym znajdowaniem błędów. Ale jeśli nie masz ochoty żyć w niebezpieczeństwie, możesz włączyć opcję Option Explicit.
Nie jestem do końca pewien, czy moje działania obejmowały kroki 5, 8 czy 9 z 12 kroków. Ale jeśli ktoś spędził więcej czasu na debugowaniu swojego kodu z powodu błędu podczas pisania, przepraszam, że sprawiłem ci ten ból.
W każdą sobotę będę omawiał jeden z moich złych nawyków w programie Excel i dlaczego może powinieneś robić to, co mówię, zamiast robić to, co ja.
Myśl dnia Excela
Poprosiłem moich znajomych z programu Excel Master o radę dotyczącą programu Excel. Dzisiejsza myśl do rozważenia:
„Nie zmieniaj twórców arkuszy kalkulacyjnych w trakcie scrum”.
Jordan Goldmeier
