Darmowy fragment publikacji:
IDZ DO
IDZ DO
PRZYK£ADOWY ROZDZIA£
PRZYK£ADOWY ROZDZIA£
SPIS TREŒCI
SPIS TREŒCI
KATALOG KSI¥¯EK
KATALOG KSI¥¯EK
KATALOG ONLINE
KATALOG ONLINE
ZAMÓW DRUKOWANY KATALOG
ZAMÓW DRUKOWANY KATALOG
TWÓJ KOSZYK
TWÓJ KOSZYK
DODAJ DO KOSZYKA
DODAJ DO KOSZYKA
CENNIK I INFORMACJE
CENNIK I INFORMACJE
ZAMÓW INFORMACJE
ZAMÓW INFORMACJE
O NOWOŒCIACH
O NOWOŒCIACH
ZAMÓW CENNIK
ZAMÓW CENNIK
CZYTELNIA
CZYTELNIA
FRAGMENTY KSI¥¯EK ONLINE
FRAGMENTY KSI¥¯EK ONLINE
Wydawnictwo Helion
ul. Chopina 6
44-100 Gliwice
tel. (32)230-98-63
e-mail: helion@helion.pl
Excel. Programowanie
dla profesjonalistów
Autorzy: Stephen Bullen, Rob Bovey, John Green
T³umaczenie: Robert Górczyñski, Krzysztof Mas³owski
ISBN: 83-246-0079-5
Tytu³ orygina³u: Professional Excel Development:
The Definitive Guide to Developing Applications
Using Microsoft(R) Excel and VBA(R)
Format: B5, stron: 768
Wiêkszoœci u¿ytkowników Excel kojarzy siê wy³¹cznie z arkuszem kalkulacyjnym
u¿ywanym w biurach. Zdecydowanie mniej osób wie, ¿e Excel jest równie¿ potê¿nym
narzêdziem programistycznym, za pomoc¹ którego projektuje siê rozbudowane
aplikacje, wyposa¿one w graficzne interfejsy u¿ytkownika i korzystaj¹ce z danych
zewnêtrznych, jêzyka XML i us³ug sieciowych. Dziêki jêzykowi Visual Basic for
Applications (VBA) mo¿na tworzyæ na bazie Excela profesjonalne narzêdzia bardzo
dobrej jakoœci.
Ksi¹¿ka „Excel. Programowanie dla profesjonalistów” to podrêcznik poœwiêcony
projektowaniu aplikacji w œrodowisku Excela, adresowany do doœwiadczonych
u¿ytkowników tego narzêdzia oraz programistów. Autorzy krok po kroku wyjaœniaj¹,
jak tworzyæ dodatki, implementowaæ us³ugi sieciowe, projektowaæ formularze userform.
Ucz¹ konstruowania wykresów i obs³ugi b³êdów, pokazuj¹, w jaki sposób
zoptymalizowaæ wydajnoœæ aplikacji i jak je dystrybuowaæ.
(cid:129) Najlepsze praktyki programistyczne w Excelu i VBA
(cid:129) Projektowanie arkusza
(cid:129) Tworzenie dodatków
(cid:129) Sterowanie paskami narzêdzi
(cid:129) Korzystanie z funkcji Windows API
(cid:129) Budowanie interfejsów u¿ytkownika
(cid:129) Po³¹czenia z bazami danych
(cid:129) Usuwanie b³êdów z kodu Ÿród³owego
(cid:129) Sterowanie innymi aplikacjami MS Office
(cid:129) Korzystanie z funkcji Visual Basic 6 i VB.NET
(cid:129) Po³¹czenia z us³ugami sieciowymi
(cid:129) Tworzenie wersji dystrybucyjnej aplikacji
Poznaj zasady tworzenia aplikacji przy u¿yciu Excela —
z tych narzêdzi korzystaj¹ najwiêksze firmy œwiata
Spis treści
O autorach ....................................................................................... 9
Rozdział 1. Wstęp ............................................................................................ 11
O książce ........................................................................................................................ 11
Twórca programowania excelowego .............................................................................. 12
Excel jako platforma do tworzenia aplikacji .................................................................. 14
Struktura ......................................................................................................................... 17
Przykłady ....................................................................................................................... 18
Wersje obsługiwane ....................................................................................................... 18
Rodzaje kroju pisma ....................................................................................................... 19
Na płycie CD .................................................................................................................. 20
Pomoc i wsparcie ........................................................................................................... 20
Rozdział 2. Architektura aplikacji ..................................................................... 23
Koncepcje ....................................................................................................................... 23
Wnioski .......................................................................................................................... 33
Rozdział 3. Najlepsze praktyki programowania w Excelu i VBA .......................... 35
Konwencje nazw ............................................................................................................ 35
Najlepsze praktyki organizacji i tworzenia struktury aplikacji ....................................... 46
Najlepsze praktyki określające ogólne zasady tworzenia oprogramowania ................... 50
Wnioski .......................................................................................................................... 66
Rozdział 4. Projektowanie arkusza .................................................................... 67
Zasady projektowania dobrego interfejsu użytkownika ................................................. 67
Wiersze i kolumny programu: podstawowe techniki
tworzenia interfejsu użytkownika ................................................................................ 68
Nazwy definiowane ........................................................................................................ 69
Style ............................................................................................................................... 75
Techniki kreślenia interfejsów użytkownika .................................................................. 79
Weryfikacja danych ........................................................................................................ 83
Formatowanie warunkowe ............................................................................................. 86
Używanie kontrolek w arkuszu ...................................................................................... 92
Przykład praktyczny ....................................................................................................... 94
Wnioski .......................................................................................................................... 99
4
Excel. Programowanie dla profesjonalistów
Rozdział 5. Dodatki funkcyjne, ogólne i specjalizowane dla aplikacji ................ 101
Cztery etapy rozwoju i działania aplikacji .................................................................... 101
Dodatki będące bibliotekami funkcji ............................................................................ 104
Dodatki ogólne ............................................................................................................. 110
Dodatki specjalizowane dla aplikacji ........................................................................... 111
Przykład praktyczny ..................................................................................................... 117
Wnioski ........................................................................................................................ 128
Rozdział 6. Aplikacja dyktatorska ................................................................... 129
Struktura aplikacji dyktatorskiej ................................................................................... 129
Przykład praktyczny ..................................................................................................... 142
Wnioski ........................................................................................................................ 147
Rozdział 7. Używanie modułów klas do tworzenia obiektów ............................. 149
Tworzenie obiektów ..................................................................................................... 149
Tworzenie kolekcji ....................................................................................................... 153
Wychwytywanie zdarzeń ............................................................................................. 159
Generowanie zdarzeń ................................................................................................... 161
Przykład praktyczny ..................................................................................................... 167
Wnioski ........................................................................................................................ 172
Rozdział 8. Zaawansowane sterowanie paskami poleceń ................................. 175
Projektowanie paska poleceń ....................................................................................... 175
Tablicowe sterowanie paskami poleceń ....................................................................... 177
Zbieranie wszystkiego razem ....................................................................................... 194
Ładowanie niestandardowych ikon z plików ................................................................ 201
Podczepianie obsługi zdarzeń do kontrolek paska poleceń .......................................... 205
Przykład praktyczny ..................................................................................................... 213
Wnioski ........................................................................................................................ 218
Rozdział 9. Zrozumienie i używanie wywołań Windows API .............................. 221
Ogólny opis .................................................................................................................. 222
Praca z ekranem ........................................................................................................... 226
Praca z oknami ............................................................................................................. 229
Praca z klawiaturą ........................................................................................................ 236
Praca z systemem plików i siecią ................................................................................. 241
Przykład praktyczny ..................................................................................................... 252
Wnioski ........................................................................................................................ 255
Rozdział 10. Projektowanie formularzy UserForm i najlepsze praktyki ................. 257
Zasady .......................................................................................................................... 257
Podstawy kontrolek ...................................................................................................... 265
Efekty wizualne ............................................................................................................ 271
Pozycjonowanie i rozmiary formularzy UserForm ....................................................... 278
Kreatory ....................................................................................................................... 283
Dynamiczne formularze UserForm .............................................................................. 287
Niemodalne formularze UserForm ............................................................................... 294
Wyszczególnienie kontrolek ........................................................................................ 298
Przykład praktyczny ..................................................................................................... 303
Wnioski ........................................................................................................................ 304
Rozdział 11. Interfejsy ...................................................................................... 305
Co to jest interfejs? ....................................................................................................... 305
Ponowne użycie kodu ................................................................................................... 306
Definiowanie własnych interfejsów ............................................................................. 308
Spis treści
5
Wdrażanie własnego interfejsu ..................................................................................... 309
Używanie własnych interfejsów ................................................................................... 311
Klasy polimorficzne ..................................................................................................... 312
Polepszanie solidności .................................................................................................. 316
Upraszczanie rozwoju .................................................................................................. 317
Architektura modułów rozszerzających ....................................................................... 326
Przykład praktyczny ..................................................................................................... 327
Wnioski ........................................................................................................................ 329
Rozdział 12. Obsługa błędów VBA ..................................................................... 331
Pojęcia obsługi błędów ................................................................................................. 331
Zasada pojedynczego punktu wyjścia .......................................................................... 339
Prosta obsługa błędów .................................................................................................. 340
Złożone projekty obsługi błędów ................................................................................. 340
Centralna obsługa błędów ............................................................................................ 344
Obsługa błędów w klasach i formularzach UserForm .................................................. 350
Zbieranie wszystkiego razem ....................................................................................... 351
Przykład praktyczny ..................................................................................................... 356
Wnioski ........................................................................................................................ 364
Rozdział 13. Programowanie i bazy danych ....................................................... 365
Wprowadzenie do baz danych ...................................................................................... 365
Projektowanie warstwy dostępu do danych .................................................................. 380
Dostęp do danych za pomocą SQL i ADO ................................................................... 381
Dalsze pozycje do czytania .......................................................................................... 397
Przykład praktyczny ..................................................................................................... 398
Wnioski ........................................................................................................................ 408
Rozdział 14. Techniki przetwarzania danych ...................................................... 409
Struktury danych Excela .............................................................................................. 409
Funkcje przetwarzania danych ..................................................................................... 415
Zaawansowane funkcje ................................................................................................ 425
Wnioski ........................................................................................................................ 432
Rozdział 15. Zaawansowane techniki tworzenia wykresów ................................ 433
Podstawowe techniki .................................................................................................... 433
Techniki VBA .............................................................................................................. 447
Wnioski ........................................................................................................................ 452
Rozdział 16. Debugowanie kodów VBA ............................................................. 453
Podstawowe techniki debugowania kodów VBA ......................................................... 453
Okno Immediate (Ctrl+G) ............................................................................................ 462
Call Stack — stos wywołań (Ctrl+L) ........................................................................... 465
Okno Watch ................................................................................................................. 466
Okno Locals ................................................................................................................. 475
Object Browser — przeglądarka obiektowa (F2) ......................................................... 476
Tworzenie działającego otoczenia testowego ............................................................... 479
Stosowanie asercji ........................................................................................................ 481
Debugerskie skróty klawiaturowe, które powinien znać każdy programista ................ 483
Wnioski ........................................................................................................................ 485
Rozdział 17. Optymalizacja wydajności VBA ...................................................... 487
Mierzenie wydajności ................................................................................................... 487
Program narzędziowy PerfMon .................................................................................... 488
Myślenie kreatywne ..................................................................................................... 491
6
Excel. Programowanie dla profesjonalistów
Makrooptymalizacja ..................................................................................................... 496
Mikrooptymalizacja ..................................................................................................... 505
Wnioski ........................................................................................................................ 511
Rozdział 18. Sterowanie innymi aplikacjami Office ............................................ 513
Podstawy ...................................................................................................................... 513
Modele obiektowe głównych aplikacji Office .............................................................. 526
Przykład praktyczny ..................................................................................................... 537
Wnioski ........................................................................................................................ 537
Rozdział 19. XLL i API C ................................................................................... 539
Dlaczego warto tworzyć funkcje arkusza na bazie XLL? ............................................. 539
Tworzenie projektu XLL w Visual Studio ................................................................... 540
Struktura XLL .............................................................................................................. 545
Typy danych XLOPER i OPER ................................................................................... 552
Funkcja Excel4 ............................................................................................................. 556
Powszechnie używane funkcje API C .......................................................................... 558
XLOPER i zarządzanie pamięcią ................................................................................. 559
Rejestrowanie i wyrejestrowywanie własnych funkcji arkusza .................................... 560
Przykładowa funkcja aplikacji ..................................................................................... 562
Debugowanie funkcji arkusza ...................................................................................... 564
Różne tematy ................................................................................................................ 565
Dodatkowe źródła informacji ....................................................................................... 566
Wnioski ........................................................................................................................ 568
Rozdział 20. Połączenie Excela i Visual Basica 6 .............................................. 569
Witaj świecie ActiveX DLL ......................................................................................... 570
Dlaczego używać VB6 ActiveX DLL w projektach Excel VBA? ................................ 583
In-process kontra out-of-process .................................................................................. 596
Automatyzacja Excela z VB6 EXE .............................................................................. 597
Przykłady praktyczne ................................................................................................... 603
Wnioski ........................................................................................................................ 615
Rozdział 21. Pisanie dodatków w Visual Basic 6 ............................................... 617
Dodatek Witaj świecie .................................................................................................. 617
Projektant dodatków (Add-in Designer) ....................................................................... 621
Instalacja ...................................................................................................................... 624
Zdarzenia AddinInstance .............................................................................................. 625
Obsługa paska poleceń ................................................................................................. 628
Dlaczego warto używać dodatku COM? ...................................................................... 633
Automatyzacja dodatków ............................................................................................. 634
Przykład praktyczny ..................................................................................................... 637
Wnioski ........................................................................................................................ 637
Rozdział 22. Używanie VB.NET i Visual Studio Tools for Office ........................... 639
Ogólny opis .................................................................................................................. 639
Jak wpływać na strukturę .NET? .................................................................................. 641
Zarządzane skoroszyty ................................................................................................. 643
Zarządzane dodatki Excela ........................................................................................... 658
Hybrydowe rozwiązania VBA/VSTO .......................................................................... 659
Model bezpieczeństwa VSTO ...................................................................................... 661
Duże zagadnienia ......................................................................................................... 666
Dalsze źródła informacji .............................................................................................. 672
Przykład praktyczny ..................................................................................................... 672
Wnioski ........................................................................................................................ 675
Spis treści
7
Rozdział 23. Excel, XML i usługi sieciowe ......................................................... 677
XML ............................................................................................................................. 677
Usługi sieciowe ............................................................................................................ 697
Przykład praktyczny ..................................................................................................... 702
Wnioski ........................................................................................................................ 711
Rozdział 24. Zapewnianie pomocy, bezpieczeństwa,
pakowanie i rozpowszechnianie ..................................................... 713
Zapewnianie pomocy ................................................................................................... 713
Bezpieczeństwo ............................................................................................................ 721
Pakowanie .................................................................................................................... 725
Rozpowszechnianie ...................................................................................................... 729
Wnioski ........................................................................................................................ 730
Skorowidz ..................................................................................... 731
Rozdział 3.
Najlepsze praktyki
programowania
w Excelu i VBA
Ten rozdział umieściliśmy niedaleko początku książki, aby zawczasu wyjaśnić, dlacze-
go w dalszych rozdziałach pewne rzeczy będziemy robili tak, a nie inaczej. Niestety,
oznacza to również konieczność poruszenia tutaj pewnych tematów, które w pełni zo-
staną wyjaśnione dopiero później. Dla osiągnięcia najlepszych rezultatów warto przejrzeć
ten rozdział ponownie po przeczytaniu reszty książki.
Czytając ten rozdział, nie zapominaj, że choć opisane w nim praktyki są ogólnie uznane
za najlepsze, zawsze będą istniały przypadki, w których najlepszym rozwiązaniem
będzie postępowanie niezgodne z najlepszymi praktykami. Najczęstsze przykłady takich
sytuacji staraliśmy się wskazać w tym rozdziale i dyskusjach dotyczących najlep-
szych praktyk omawianych w następnych rozdziałach.
Konwencje nazw
Czym jest konwencja nazw i dlaczego jest istotna?
Termin konwencja nazw określa system, jakiego używasz, nazywając różne części two-
rzonej aplikacji. Zawsze gdy deklarujesz zmienną lub tworzysz formularz, nadajesz
im nazwy. Niejawnie nazywasz obiekty nawet wtedy, gdy nie nadajesz im nazw
wprost, akceptując jedynie nazwy domyślne, czego przykładem może być tworzenie
formularza. Jednym ze znaków firmowych dobrej praktyki programowania jest sto-
sowanie dla wszystkich części aplikacji VBA nazw spójnych i zgodnych z jasno okre-
śloną konwencją.
36
Excel. Programowanie dla profesjonalistów
Przyjrzyjmy się przykładowi, który pozwoli pokazać, czym jest konwencja nazw. Co
możesz wywnioskować o x z podanej niżej linii kodu?
x = wksDataSheet.Range( A1 ).Value
Ze sposobu użycia możesz rozsądnie wnioskować, że jest zmienną. Ale jaki typ wartości
ma przechowywać? Czy jest to zmienna publiczna, czy o zasięgu na poziomie modułu,
czy może zmienna prywatna? Do czego służy w programie? W podanej sytuacji nie
jesteś w stanie odpowiedzieć na żadne z tych pytań, bez poświęcenia nieco czasu na
przeszukanie kodu. Dobra konwencja nazw pozwala na odczytanie takich informa-
cji z samej nazwy zmiennej. Oto przykład poprawiony (szczegóły zostaną omówione
w następnym podrozdziale).
glListCount = wksDataSheet.Range( A1 ).Value
Teraz już znasz zakres zmiennej (g oznacza global — zmienną globalną, czyli inaczej
publiczną), wiesz, jaki typ danych ma przechowywać (l oznacza Long) i masz ogólne
pojęcie, do czego ta zmienna ma służyć (przechowuje liczbę elementów listy).
Konwencja nazw pomaga w szybkim rozpoznawaniu typu i celu użycia bloków, z których
jest budowana aplikacja. To pozwala Ci koncentrować się raczej na zadaniach kodu
niż na jego strukturze. Konwencje nazw służą także samodokumentacji kodu, zmniej-
szając liczbę komentarzy koniecznych do tego, aby był zrozumiały.
W następnym podrozdziale pokazujemy przykład konwencji nazw z przemyślaną
strukturą. Najważniejszą sprawą jest jednak wybranie jednej konwencji i jej konse-
kwentne przestrzeganie. Jeżeli wszyscy uczestniczący w projekcie rozumieją przyjętą
konwencję, nie ma właściwie znaczenia, jakie prefiksy są używane lub jak i kiedy są
stosowane litery wielkie i małe. Zasady przyjętej konwencji powinny być spójne i kon-
sekwentnie, bez zmian stosowane nie tylko w pojedynczym projekcie, lecz również
w dłuższym okresie czasu.
Przykładowa konwencja nazw
Dobra konwencja nazw obejmuje nie tylko zmienne, lecz wszystkie elementy aplikacji.
Przykładowa, pokazana przez nas konwencja obejmuje wszystkie elementy typowej apli-
kacji Excela. Rozpoczniemy od dyskusji o zmiennych, stałych i związanych z nimi ele-
mentach, gdyż to właśnie one najczęściej występują we wszelkich aplikacjach. W tabeli 3.1
pokazujemy ogólny format konwencji nazw. Określone elementy i ich cele są opisane dalej.
Tabela 3.1. Konwencja nazw zmiennych, stałych, typów definiowanych przez użytkownika i wyliczeń
Element
Zmienne
Stałe
Typy definiowane przez użytkownika
Konwencja nazw
zakres tablica typ danych NazwaOpisowa
zakres typ danych NAZWA_OPISOWA
Type NAZWA_OPISOWA
typ danych NazwaOpisowa
End Type
Enum prefiks projektu OpisOgolny
prefiks projektu OpisOgolnyNazwa1
prefiks projektu OpisOgolnyNazwa2
End Num
Typ wyliczeniowy
Rozdział 3. ♦ Najlepsze praktyki programowania w Excelu i VBA
37
Określnik zakresu ( zakres )
g — Public (publiczny)
m — Module (na poziomie modułu)
(nic) — na poziomie procedury
Określnik tablicy ( tablica )
a — Array (tablica)
(nic) — nietablica
Określnik typu danych ( typ danych )
Istnieje tak wiele typów danych, że trudno sporządzić zrozumiałą listę odpowiadają-
cych im prefiksów. Typy wbudowane są proste. Problem powstaje przy nazywaniu
zmiennych obiektowych odnoszących się do obiektów z różnych aplikacji. Niektórzy
programiści stosują prefiks obj dla wszystkich nazw obiektowych. Nie można na to
przystać. Jednakże obmyślenie zbioru spójnych, niepowtarzających się, racjonalnie
uzasadnionych i krótkich prefiksów, określających każdy typ obiektu, jakiego kiedy-
kolwiek będziesz używać, okazuje się być zadaniem nad siły. Staraj się tworzyć jedno-,
dwu- i trzyliterowe rozsądnie uzasadnione prefiksy dla najczęściej używanych zmiennych
obiektowych, a prefiks obj zarezerwuj dla obiektów rzadko pojawiających się w kodzie.
Pisz kod przejrzysty, a przede wszystkim spójny. Twórz prefiksy nie dłuższe niż trzylite-
rowe. Stosowanie dłuższych w kombinacji z określnikami zakresu i tablicy prowadzi
do tworzenia nazw nieporęcznie długich. W tabeli 3.2 zawarto listę sugerowanych
prefiksów dla najczęściej używanych typów danych.
Stosowanie nazw opisowych
Choć VBA pozwala na stosowanie nazw zmiennych o długości do 255 znaków, wy-
korzystuj jedynie niewielką część dozwolonej długości, ale nie leń się i nie skracaj
nazw zmiennych zaledwie do kilku znaków. Robiąc to, sprawisz, że Twój kod stanie
się trudny do zrozumienia zwłaszcza po upływie czasu i w przyszłości sprawi kłopot
sobie lub innej osobie, która będzie nad nim pracować.
Zintegrowane środowisko programistyczne Visual Basica (Visual Basic IDE — Inte-
grated Development Environment) posiada cechę autouzupełniania identyfikatorów
(wszystkich nazw używanych w aplikacji). Zwykle aby wstawić nazwę, musisz napisać
jedynie kilka pierwszych znaków. Gdy po napisaniu kilku znaków naciśniesz Ctrl+
spacja, ukaże się lista autouzupełniania, zawierająca wszystkie nazwy rozpoczynające
się od podanych znaków. W miarę wpisywania kolejnych znaków lista będzie się skracać.
Na rysunku 3.1 kombinacja Ctrl+spacja została użyta do wyświetlenia listy stałych
łańcuchów komunikatów, jakie można dodać do pola komunikatu.
38
Excel. Programowanie dla profesjonalistów
Tabela 3.2. Prefiksy proponowane do użycia w konwencji nazw
Prefiks
Typ danych
Prefiks
Typ danych
Prefiks
b
byt
cur
dte
dec
d
i
l
obj
sng
s
u
v
Boolean
Byte
Currency
Date
Decimal
Double
Integer
Long
Object
Single
String
User-defined
type – Typ
zdefiniowany
Variant
cm
cn
rs
cht
rng
wkb
wks
cbr
ctl
cls
frm
ADODB.Command
ADODB.Connection
ADODB.Recordset
Excel.Chart
Excel.Range
Excel.Workbook
Excel.Worksheet
Office.CommandBar
Office.CommandBar-
Control
cbo
chk
cmd
ddn
fra
lbl
lst
mpg
opt
spn
txt
Typ danych
MSForms.ComboBox*
MSForms.CheckBox
MSForms.CommandButton
MSForms.ComboBox**
MSForms.Frame
MSForms.Label
MSForms.ListBox
MSForms.MultiPage
MSForms.OptionButton
MSForms.SpinButton
MSForms.TextBox
User-defined
class variable –
odwołanie do klasy
UserForm
ref
col
Kontrolka RefEdit
kolekcja, zbiór
* Stosowane do kontrolek ComboBox typu DropDownCombo.
** Stosowane do kontrolek ComboBox typu DropDownList.
Rysunek 3.1.
Skrót klawiaturowy
Ctrl+spacja pozwala
na autouzupełnianie
długich nazw
Kilka słów o stałych typu wyliczeniowego
W Excelu 2000 i wersjach nowszych są dostępne stałe tzw. typu wyliczeniowego. Po-
zwalają one na tworzenie listy spokrewnionych wartości i udostępnienie ich przez lo-
gicznie uzasadnione, przyjazne dla użytkownika nazwy. VBA i model obiektowy Excela
szeroko korzystają z takich wyliczeń. Możesz to sprawdzić, korzystając z autouzupeł-
niania, na jakie pozwala VBA przy podawaniu wartości właściwości. Jeżeli np. w mo-
dule VBA napiszesz:
Arkusz1.PageSetup.PaperSize =
Rozdział 3. ♦ Najlepsze praktyki programowania w Excelu i VBA
39
zobaczysz długą listę składowych typu wyliczeniowego podającą różne wymiary pa-
pierów do drukowania (rysunek 3.2).
Rysunek 3.2.
Lista wyliczająca
dostępne
rozmiary papieru
Te nazwy w rzeczywistości reprezentują stałe liczbowe, których wartości możesz spraw-
dzić za pomocą przeglądarki obiektów (Object Browser), omówionej w rozdziale 16.
Zwróć uwagę na strukturę nazw stałych typu wyliczeniowego. Po pierwsze, wszystkie
rozpoczynają się od przedrostka identyfikującego aplikację — w tym przypadku xl
oznacza Excela. Po drugie, początkowa część nazwy jest opisowa, co wizualnie wiąże
ze sobą nazwy należące do tego samego typu wyliczeniowego — w tym przypadku
jest to Paper. Ostatnią częścią nazwy wyliczeniowej jest unikatowy łańcuch, opisują-
cy specyficzną wartość. Przykładowo xlPaper11x17 opisuje papier o formacie 11x7,
a xlPaperA4, odpowiednio papier o formacie A4. Taka konwencja nazw wyliczenio-
wych jest bardzo rozpowszechniona i zastosowano ją również w tej książce.
Przykłady stosowania konwencji nazw
Abstrakcyjne wyjaśnienie związku deskryptorów konwencji nazw z nazwami rze-
czywistymi jest trudne, więc w tym podrozdziale pokażemy kilka praktycznych przy-
kładów. Wszystkie pochodzą wprost z komercyjnych aplikacji napisanych przez autorów.
Zmienne
(cid:141) gsErrMsg — zmienna publiczna (public variable) typu String używana
do przechowywania komunikatu o błędzie1.
(cid:141) mauSettings() — tablica na poziomie modułu typu zadeklarowanego
przez użytkownika, używana do przechowywania parametrów (settings).
1 Jeżeli aplikacja ma być używana jedynie w Polsce, warto stosować opisowe nazwy polskie. Jeżeli
jednak nazwy odnoszą się do typów, narzędzi itp. środowiska VBA (które pozostaje angielskie),
trzeba wystrzegać się używania całkowicie niestrawnej mieszanki językowej, która może okazać się
zrozumiała jedynie dla autora. Warto wtedy stosować nazwy angielskie. Decyzja dotycząca części
opisowej bywa niekiedy trudna. Prościej jest z przedrostkami określającymi zakres i typ zmiennych
bądź stałych, które warto uzależniać od angielskich nazw obiektów i typów (np. zmienne musimy
deklarować jako Long i String, niezależnie od naszych upodobań językowych). To pomieszanie
języków utrudnia opracowanie logicznej i przejrzystej konwencji nazw — przyp. tłum.
Excel. Programowanie dla profesjonalistów
(cid:141) cbrMenu — lokalna zmienna typu CommandBar, przechowująca odwołanie
do paska menu.
40
Stałe
(cid:141) gbDEBUG_MODE — stała publiczna (public constant) typu boole’owskiego
wskazująca, czy projekt działa w trybie debugowania.
(cid:141) msCAPTION_FILE_OPEN — stała na poziomie modułu z wartością typu String,
przechowująca tytuł (caption) zdefiniowanego przez użytkownika okna
otwierania plików (w tym przykładzie Application.GetOpenFilename).
(cid:141) lOFFSET_START — stała lokalna z daną typu Long, przechowująca punkt,
od którego obliczamy przesunięcie względem jakiegoś obiektu typu Range.
Typy definiowane przez użytkownika
Niżej został podany przykład typu danych zdefiniowanych przez użytkownika, mają-
cych służyć do przechowywania wymiarów i położenia obiektu. Nowy typ danych
składa się z czterech zmiennych typu Double, przechowujących położenie góry i lewej
strony obiektu, jego szerokość i wysokość oraz zmienną typu Boolean, służącą do
wskazywania, czy dane zostały zapisane.
Public Type WYMIARY_USTAWIENIA
bUstawieniaZapisane As Boolean
dWartGora As Double
dWartLewa As Double
dWartWysokosc As Double
dWartSzerokosc As Double
End Type
Zmienne wewnątrz definicji typu użytkownika nazywamy zmiennymi składowymi
(member variables). Można je deklarować w dowolnej kolejności, jednakże w naszej
konwencji przyjmujemy kolejność alfabetyczną według typów danych, jeżeli tylko
nie występują ważne powody grupowania zmiennych w inny sposób.
Typ wyliczeniowy
Poniżej został zdefiniowany typ wyliczeniowy na poziomie modułu stosowany do opisu
różnego rodzaju dni. Prefiks sch określa nazwę aplikacji. W tym przypadku podane
wyliczenie pochodzi z aplikacji Scheduler. TypDnia jest częścią nazwy wskazującą cel
tego typu wyliczeniowego, zaś indywidualne przyrostki pokazują indywidualne znaczenie
każdej składowej typu wyliczeniowego.
Private Enum schTypDnia
schTypDniaPozaplanowy
schTypDniaProdukcyjny
schTypDniaPrzestojowy
schTypDniaWolny
End Enum
Rozdział 3. ♦ Najlepsze praktyki programowania w Excelu i VBA
41
Jeżeli nie określisz wartości składowych typu wyliczeniowego, VBA automatycznie
przypisuje pierwszej składowej wartość zero, a kolejnym składowym wartości zwięk-
szane o jeden. Możesz to łatwo zmienić, przypisując inną wartość startową, od której
VBA rozpocznie inkrementację. Aby nakazać VBA zwiększanie wartości od 1 zamiast
od zera, powinieneś napisać:
Private Enum schTypDnia
schTypDniaPozaplanowy = 1
schTypDniaProdukcyjny
schTypDniaPrzestojowy
schTypDniaWolny
End Enum
VBA rozpoczyna inkrementację o jeden, zaczynając od ostatniej określonej przez
Ciebie wartości. Możesz uniemożliwić automatyczne przypisywanie wartości przez
proste ich określenie dla wszystkich składowych.
Na rysunku 3.3. pokazujemy jedną z korzyści, jakie daje stosowanie typu wyliczeniowego.
VBA dostarcza listę potencjalnych wartości dla każdej zmiennej zadeklarowanej jako
należąca do danego typu wyliczeniowego.
Rysunek 3.3.
Nawet deklarowany
przez użytkownika
typ wyliczeniowy jest
obsługiwany przez
autouzupełnianie VBA
Procedury
Znamy dwa typy procedur — procedury typu Sub (podprogramy) i funkcje. Zawsze
nadawaj procedurom nazwy opisowe. Powtarzamy ponownie, że nazwy procedur mo-
gą mieć 255 znaków i również pojawiają się na listach autouzupełnień wyświetlanych za
pomocą skrótu klawiszowego Ctrl+spacja, zatem nie ma powodów, aby poświęcać
dłuższe nazwy opisujące cel procedury na rzecz innych, których jedyną zaletą jest to,
że są krótkie.
Choć nie jest to powszechną praktyką, uważamy, że poprzedzanie nazwy funkcji pre-
fiksem określającym typ zwracanej danej jest przydatne i ułatwia rozumienie kodu.
Wywołując funkcję, zawsze po nazwie dajemy parę okrągłych nawiasów dla odróż-
nienia od nazwy zmiennej lub procedury Sub i robimy to nawet wtedy, gdy funkcja nie
ma argumentów. W listingu 3.1 pokazujemy dobrze nazwaną funkcję boole’owską,
użytą jako test w instrukcji If...Then.
42
Excel. Programowanie dla profesjonalistów
Listing 3.1. Przykład funkcji nazwanej zgodnie z konwencją nazw
If bWeryfikacjaSciezki( C:Pliki ) Then
Jeżeli podana ścieżka istnieje
blok instrukcji If...Then jest wykonywany
End Sub
Podprogramy (procedury Sub) powinny otrzymywać nazwy opisujące zadania, jakie
wykonują. Przykładowo nazwa procedury ZamykanieAplikacji nie pozostawia wiele
wątpliwości dotyczących wykonywanego zadania. Nazwy funkcji powinny opisywać
zwracane wartości. Możemy oczekiwać, że funkcja sPodajNieuzywanaNazwePliku()
poda nazwę pliku.
Konwencja nazw stosowana do argumentów procedur jest taka sama, jak dla zmien-
nych na poziomie procedury, np. funkcja bWeryfikacjaSciezki pokazana w listingu
3.1 może być zadeklarowana w następujący sposób:
Function bWeryfikacjaSciezki(ByVal sSciezka As String) As Boolean
Moduły, klasy i formularze UserForm
W naszej przykładowej konwencji nazw nazwy standardowych modułów kodu po-
winny być poprzedzane przedrostkiem M, moduły klas przedrostkiem C, zaś formularze
UserForm przedrostkiem F. Daje to — po zrezygnowaniu z wyświetlania folderów —
dodatkowy, przyjemny efekt sortowania nazw w oknie Project edytora VBA, co zo-
stało pokazane na rysunku 3.4.
Rysunek 3.4.
Moduły klas,
formularze UserForm
i moduły standardowe
posortowane w oknie
Project edytora VBA
Ta konwencja ułatwia rozumienie kodu używającego modułów klas i formularzy
UserForm. Podany niżej przykład pokazuje, jak konwencja ułatwia rozpoznanie, że
deklarowana jest zmienna obiektowa klasy określonego typu, a potem tworzony nowy
egzemplarz tej klasy.
Rozdział 3. ♦ Najlepsze praktyki programowania w Excelu i VBA
43
Dim clsMojaKlasa As CMojaKlasa
Set clsMojaKlasa = New CMojaKlasa
Zawsze nazwa po lewej jest zmienną typu danej klasy, zaś obiekt po prawej jest klasą.
Arkusze zwykłe i arkusze wykresów
Ponieważ stosowane w kodzie nazwy (CodeNames) arkuszy zwykłych i arkuszy wykre-
sów użytych w aplikacji są przez VBA traktowane jako wewnętrzne zmienne obiek-
towe, powinny być nadawane zgodnie z przyjętą konwencją nazywania zmiennych.
Nazwy arkuszy są poprzedzane przedrostkiem wks (worksheet), który w kodzie będzie
identyfikował ich przynależność do obiektów arkuszy. Odpowiednio nazwy arkuszy
wykresów (chart sheets) są poprzedzane przedrostkiem cht, identyfikującym je jako
przynależne do obiektów typu wykres (chart).
W obu typach arkuszy po prefiksie powinna być umieszczona nazwa opisowa, okre-
ślająca cel arkusza w aplikacji. Przykładowo na rysunku 3.4 widać nazwę arkusza
wksCommandBars, zawierającego tablicę definiującą paski narzędziowe tworzone przez
aplikację. W przypadku arkuszy zawartych w dodatkach oraz arkuszy ukrytych nazwy
podane na zakładkach arkuszy powinny być identyczne z nazwami kodowymi. Nazwy
„zakładkowe” arkuszy widocznych dla użytkownika powinny być dla niego przyjazne
i zrozumiałe, a poza tym musisz być przygotowany, że mogą być przez użytkownika
zmienione. Później dokładnie wyjaśnimy, dlaczego wewnątrz kodu powinieneś zaw-
sze polegać na kodowych nazwach arkuszy, a nie na ich nazwach „zakładkowych”.
Projekt VBA (VBA Project)
Zauważ na rysunku 3.4, że projekt VBA otrzymał tę samą nazwę co skoroszyt z nim
powiązany. Zawsze powinieneś projektowi VBA nadawać nazwę pozwalającą na
jasne zidentyfikowanie aplikacji, do której należy. Nie ma nic gorszego jak grupa
otwartych skoroszytów, których wszystkie projekty mają w VBA domyślną nazwę
VBAProject. Jeżeli będziesz chciał tworzyć odwołania między projektami, będziesz
musiał nadać im unikatowe nazwy.
Konwencje nazw interfejsu użytkownika Excela
Elementy interfejsu użytkownika Excela używane podczas tworzenia aplikacji powinny
również otrzymywać nazwy zgodne z dobrze opracowaną i spójną wewnętrznie konwen-
cją. W poprzednim podrozdziale omówiliśmy arkusze zwykłe i arkusze wykresów. Trzy
następne główne elementy interfejsu użytkownika Excela, jakie musimy omówić, to
kształty (obiekty shape), obiekty osadzone (embedded objects) i nazwy definiowane.
Kształty — obiekty Shape
Termin kształty (Shapes) określa zbiór, który może zawierać wiele różnorodnych obiek-
tów, jakie możesz umieszczać nad arkuszem lub arkuszem wykresu. Kształty możemy
podzielić ogólnie na trzy główne kategorie: kontrolki, obiekty rysowane i obiekty
44
Excel. Programowanie dla profesjonalistów
osadzone. Kształty należy nazywać tak jak zmienne obiektowe, czyli zaczynać nazwę
od prefiksu definiującego typ obiektu, w dalszej części podając nazwę opisującą cel,
jakiemu obiekt służy w aplikacji.
Wiele kontrolek umieszczanych w formularzu UserForm można również sadowić w arku-
szach. W arkuszu mogą się także znaleźć stare kontrolki z paska narzędzi Formularze,
które choć podobne do kontrolek ActiveX MSForms, mają swe własne plusy i minusy,
co bardziej szczegółowo zostało omówione w rozdziale 4. Kontrolki umieszczane
w arkuszach powinny być nazywane zgodnie z konwencją stosowaną przy nazywaniu
kontrolek umieszczanych w formularzach.
Do arkuszy można także wprowadzać wiele obiektów rysowanych (znanych pod tech-
niczną nazwą kształtów), które — ściśle mówiąc — nie są kontrolkami, choć można
do nich przypisywać makra. Należą do tej samej kategorii konwencji nazw, co wiele
obiektów używanych w VBA. Byłoby bardzo trudno określić dla nich jednoznaczne
przedrostki nazw, więc używaj dobrze określonych przedrostków dla obiektów naj-
powszechniej używanych, a dla reszty stosuj przedrostki standardowe. Oto przykładowe
przedrostki dla trzech powszechnie używanych obiektów rysunkowych:
pic
rec
txt
Picture
Rectangle
TextBox (ale nie kontrolka ActiveX)
Obraz.
Prostokąt.
Pole tekstowe.
Obiekty osadzone (Embedded Objects)
Termin obiekty osadzone jest tu używany w odniesieniu do obiektów Excela, takich
jak tabele przestawne (PivotTables), tabele zapytań (QueryTables) i wykresy (Chart-
Objects), jak również obiekty kreowane przez aplikacje różne od Excela. Arkusze
mogą przechowywać wiele różnych osadzonych obiektów. Znanym przykładem obiektów
osadzonych w arkuszu, które nie powstały w Excelu, są równania tworzone przez
edytor równań (Equation Editor) oraz rysunki, które powstają za pomocą WordArt. Oto
przykładowe przedrostki dla nazw obiektów osadzonych:
cht
eqn
qry
pvt
art
ChartObject
Equation
QueryTable
PivotTable
WordArt
Nazwy definiowane
Wykres.
Równanie.
Tabela zapytania.
Tabela przestawna.
WordArt.
W naszej konwencji nazwy definiowane są traktowane nieco inaczej niż inne ele-
menty. W przypadku nazw definiowanych przedrostek powinien szeroko określać cel
definiowanej nazwy, a nie typ danych, jakie mają być przechowywane. W aplikacjach
Excela, poza najprostszymi, występuje wiele nazw definiowanych i ich grupowanie
Rozdział 3. ♦ Najlepsze praktyki programowania w Excelu i VBA
45
według celu w oknie dialogowym Definiowanie nazw (Definiuj nazwy — w wersjach
starszych niż Excel 2003) znacznie ułatwia pracę. Jeżeli arkusz zawiera dziesiątki lub
setki nazw definiowanych, takie pogrupowanie funkcjonalne przez zastosowanie odpo-
wiednich przedrostków przynosi widoczne korzyści.
Opisowa część nazwy zdefiniowanej dokładne określa, do czego ta nazwa służy w ramach
szerszej kategorii. Na podanej niżej liście widzimy kilka przedrostków celu nazw defi-
niowanych.
cht
con
err
for
inp
out
ptr
rgn
set
tbl
Chart data range
Named constant
Error check
Named formula
Input range
Output range
Specific cell location
Region
UI setting (User Interface) Ustawienie interfejsu użytkownika.
Table
Zakres danych wykresu.
Nazwana stała.
Znacznik błędu.
Nazwana formuła.
Zakres wejściowy.
Zakres wyjściowy.
Określony adres komórki.
Obszar (zakres).
Tabela.
Wyjątki — kiedy nie stosuje się konwencji nazw
W dwóch przypadkach zechcesz złamać ogólną konwencję nazw. Po pierwsze, gdy
masz do czynienia z elementami dotyczącymi wywołań Windows API. Elementy te
zostały nazwane przez Microsoft i są szeroko znane w społeczności programistów.
Stałe Windows API, typy deklarowane przez użytkownika, deklaracje i argumenty
procedur powinny pojawiać się w kodzie dokładnie w takiej postaci, w jakiej znajdu-
jemy je w SDK2 dla platformy Microsoftu (Microsoft Platform SDK), co możemy
sprawdzić w serwisie internetowym MSDN pod adresem:
http://msdn.microsoft.com/library/
en-us/winprog/winprog/windows_api_start.page.asp
Zauważ, że są to odwołania w formacie C/C++.
Drugim przypadkiem, gdy nie zechcesz użyć własnej konwencji nazw, jest stosowa-
nie kodu pochodzącego ze źródeł zewnętrznych, służącego do realizacji specjalnych
zadań. Jeżeli zmodyfikujesz nazwy w tej części kodu i będziesz się do nich odwoły-
wać w reszcie aplikacji, ewentualna aktualizacja wstawki, jeżeli pojawi się jej nowa
wersja, będzie bardzo trudna.
2 SDK (Software Development Kit) — zestaw narzędzi programistycznych przydatny przy tworzeniu
własnych aplikacji dla określonych platform sprzętowych i systemowych — przyp. tłum.
46
Excel. Programowanie dla profesjonalistów
Najlepsze praktyki organizacji
i tworzenia struktury aplikacji
Struktura aplikacji
Aplikacja jednoskoroszytowa, a aplikacja n-skoroszytowa
Liczba skoroszytów użytych w aplikacji Excela zależy przede wszystkim od dwóch
czynników: złożoności samej aplikacji i ograniczeń nałożonych przez warunki dystry-
bucji i aktualizacji wersji. Aplikacje proste i takie, dla których nie można wymusić
określonej kolejności działań instalacyjnych, wymagają możliwie najmniejszej liczby
skoroszytów. Aplikacje złożone i takie, których procesem instalacyjnym można w pełni
sterować, mogą być dzielone na wiele skoroszytów lub plików innego typu, np. DLL.
W rozdziale 2. zostały omówione różne typy aplikacji Excela i odpowiednie dla nich
struktury.
Jeżeli możesz swobodnie dzielić aplikację na pliki według własnego uznania, wiele
przemawia za tym, aby to czynić. Przyczyny, jakie warto brać pod uwagę, to: podział
aplikacji na warstwy logiczne, oddzielenie kodu od danych, oddzielenie elementów
interfejsu użytkownika od kodu, hermetyzacja funkcjonalnych elementów aplikacji i nad-
zór nad konfliktami wynikającymi ze zmian przy pracy zespołowej.
Rozdzielenie warstw logicznych
Niemal każda nietrywialna aplikacja Excela ma trzy wyraźne logiczne warstwy czy
sekcje. Są to:
(cid:141) Warstwa interfejsu użytkownika. Warstwa ta składa się z kodu i widocznych
elementów potrzebnych aplikacji do interakcji z użytkownikiem. W aplikacji
Excela warstwa interfejsu ma część widoczną, do której należą elementy, takie
jak arkusze, wykresy, paski narzędziowe, formularze użytkownika oraz
niewidoczną, którą stanowi kod potrzebny do sterowania elementami widocznymi.
Warstwa interfejsu użytkownika jest jedyną warstwą logiczną zawierającą
elementy widoczne dla użytkownika.
(cid:141) Warstwa logiki biznesowej (warstwa aplikacji). Warstwa logiki biznesowej
to w całości kod, który wykonuje zadania zasadnicze, dla których cała aplikacja
została zaprojektowana i napisana. Warstwa logiki biznesowej akceptuje dane
wejściowe, pochodzące z warstwy interfejsu użytkownika i tamże zwraca
wyniki. W przypadku operacji długo trwających warstwa logiki biznesowej
przekazuje do warstwy interfejsu użytkownika okresowe informacje w postaci
komunikatów statusu lub paska wskazującego stopień wykonania zadania.
(cid:141) Warstwa dostępu i przechowywania danych. Warstwa dostępu i przechowywania
danych jest odpowiedzialna za przechowywanie i dostarczanie na żądanie
danych potrzebnych aplikacji. Może to być tak proste, jak odczytywanie
Rozdział 3. ♦ Najlepsze praktyki programowania w Excelu i VBA
47
danych z komórek i ich zapisywanie w komórkach lokalnego lub ukrytego
arkusza czy tak skomplikowane, jak egzekucja przez sieć procedur na serwerze
bazodanowym (SQL Server). Warstwa dostępu i przechowywania danych
komunikuje się bezpośrednio jedynie z warstwą logiki biznesowej.
Na rysunku 3.5 możesz zobaczyć, że wszystkie trzy warstwy są konieczne do stwo-
rzenia kompletnej aplikacji, ale nie muszą być ze sobą nierozerwalnie powiązane.
Trzy warstwy są luźno łączone i istotna zmiana w jednej nie musi wymagać istotnej
zmiany w innej. Silne wiązanie warstw aplikacji w sposób nieunikniony komplikuje
jej konserwację i uaktualnianie.
Rysunek 3.5.
Relacje między
trzema warstwami
logicznymi
aplikacji Excela
Jeżeli np. warstwa dostępu i przechowywania danych wymaga zmiany dotychczaso-
wej bazy accessowej na bazę danych na SQL Servera, wszelkie zmiany dotyczą je-
dynie tej warstwy. W dobrze zaprojektowanej aplikacji żadna z dwóch pozostałych
warstw nie powinna być tknięta podczas wprowadzania potrzebnych zmian. W sytu-
acji idealnej dane między warstwą dostępu i przechowywania danych a warstwą logiki
biznesowej powinny być przekazywane w postaci zmiennych o typie zdefiniowanym
przez użytkownika. To pozwala na najlepsze zrównoważenie efektywności i swobody
powiązania. Alternatywnie można stosować obiekty ADO Recordset, ale to wprowa-
dza subtelne problemy powiązań, takie jak kolejność pól zwracanych z bazy danych,
od czego lepiej nie uzależniać warstwy logiki biznesowej.
I podobnie, jeżeli aplikacja ma zawierać alternatywny internetowy interfejs prezenta-
cyjny, swobodne powiązanie warstwy interfejsu użytkownika z warstwą logiki biznesowej
ułatwi Ci wykonanie tego zadania. Będzie ono łatwiejsze z powodu braku niejawnych
założeń wbudowanych w warstwę logiki biznesowej oraz założeń dotyczących kon-
strukcji interfejsu użytkownika. Elementy akceptujące dane wprowadzane przez użyt-
kownika powinny być w pełni niezależne i samowystarczalne. Warstwa logiki bizne-
sowej musi przekazywać interfejsowi użytkownika potrzebne dane inicjalizacyjne
jako dane o prostych właściwościach. Interfejs użytkownika powinien zbierać dane wpro-
wadzane przez użytkownika i przekazywać je wstecz do warstwy logiki biznesowej
również jako dane o prostych właściwościach lub, w przypadkach bardziej złożonych,
jako dane o typie zdefiniowanym przez użytkownika (UDT User [defined] Data Type).
Ponieważ warstwa logiki biznesowej nie powinna zawierać żadnych wewnętrznych
informacji o konstrukcji interfejsu użytkownika, bezpośrednie odwołania z warstwy
logiki biznesowej do kontrolek formularza użytkownika są zakazane.
Oddzielenie danych i interfejsu użytkownika od kodu
W wielu aplikacjach użytkownika wewnątrz warstwy interfejsu użytkownika bywają
stosowane dwie podwarstwy. Stanowią je skoroszyt i elementy arkusza używane do
budowania interfejsu oraz kod obsługujący te elementy. Podział na podwarstwy musi
48
Excel. Programowanie dla profesjonalistów
być tu rygorystycznie przestrzegany. Interfejs użytkownika korzystający z arkusza nie
powinien zawierać żadnego kodu, zaś kod kontrolujący ten interfejs należy umieścić
w całkowicie oddzielonym dodatku.
Powód tej separacji jest dokładnie taki sam, jak opisany poprzednio dla separacji głów-
nych warstw logicznych aplikacji — jest to izolacja efektów wprowadzanych zmian.
Ze wszystkich warstw aplikacji najczęściej zmieniana jest warstwa interfejsu użyt-
kownika. Dlatego nie jest wystarczające oddzielenie jej w całości i należy odseparować
także zmiany widocznych elementów interfejsu użytkownika od kodu te elementy
kontrolującego.
W następnych rozdziałach podamy wzięte z życia przykłady oddzielenia warstw apli-
kacji, więc nie przejmuj się, jeżeli teraz jakiś element dyskusji nie jest dla Ciebie w pełni
zrozumiały.
Organizacja aplikacji
w programowaniu proceduralnym
Programowaniem proceduralnym nazywamy metodologię programowania znaną
większości twórców oprogramowania. Polega ona na dzieleniu aplikacji na wiele pro-
cedur, z których każda wykonuje oddzielne zadanie. Cała aplikacja może zostać napi-
sana w ten sposób, a elementy proceduralne mogą być kombinowane z elementami
zorientowanymi obiektowo lub cała aplikacja może zostać napisana metodą zorientowaną
obiektowo. W tym podrozdziale skupiamy uwagę na najlepszych praktykach progra-
mowania proceduralnego. Techniki programowania obiektowo zorientowanego omó-
wimy w rozdziale 7.
Organizowanie kodu w moduły za pomocą funkcji (kategorii)
Głównym powodem dzielenia kodu na moduły jest zwiększenie jego przejrzystości
i ułatwienie późniejszego utrzymania aplikacji. W aplikacji proceduralnej procedury
powinny być umieszczane w oddzielnych modułach, zgodnie z logiką działania. W mo-
dułach najlepiej grupować procedury pełniące podobne funkcje.
VBA ma nieudokumentowane „miękkie ograniczenie” maksymalnego rozmiaru
standardowego modułu, którego wielkość nie powinna przekraczać 64 kB, przy
czym wielkość ta dotyczy pliku tekstowego eksportowanego z projektu (narzędzia
VBE, zapisane na płycie CD, automatycznie podają wielkość modułu). Twój projekt
nie załamie się natychmiast, gdy pojedynczy moduł przekroczy wielkość 64 kB,
lecz ciągłe przekraczanie tej granicy niemal na pewno doprowadzi do niestabilności
aplikacji.
Funkcjonalna dekompozycja
Funkcjonalna dekompozycja to proces dzielenia aplikacji na oddzielne procedury w taki
sposób, aby każda odpowiadała za wykonanie pojedynczego zadania. Teoretycznie wiele
aplikacji mógłbyś pisać w postaci wielkich, pojedynczych, monolitycznych procedur.
Rozdział 3. ♦ Najlepsze praktyki programowania w Excelu i VBA
49
Jednak takie postępowanie znacznie utrudniałoby proces debugowania i późniejszego
utrzymania aplikacji. Stosując funkcjonalną dekompozycję, planujesz aplikację tak,
by składała się z wielu procedur, z których każda będzie odpowiedzialna za ściśle
określone zadanie, łatwe do zrozumienia, weryfikacji, udokumentowania i utrzymania.
Najlepsze praktyki tworzenia procedur
Zrozumiały zestaw wskazówek opisujących właściwy sposób tworzenia procedur z ła-
twością wypełniłby cały rozdział. Niżej podamy jedynie listę najważniejszych.
(cid:141) Hermetyzowanie (enkapsulacja). Jeżeli tylko jest to możliwe, procedura
powinna być zaprojektowana tak, aby zapewnić pełną hermetyzację
wykonywanej operacji. Oznacza to np., że odpowiednio hermetyzowana
procedura może zostać skopiowana do kompletnie różnego projektu, gdzie
będzie działać równie dobrze, jak w projekcie, w którym powstała. Hermetyzacja
pomaga w wielokrotnym stosowaniu kodu, a dzięki logicznemu odizolowaniu
operacji upraszcza debugowanie.
(cid:141) Eliminowanie duplikowaniu kodu. Pisząc nietrywialną aplikację Excela,
często będziesz odkrywał, że już w wielu miejscach pisałeś kod wykonujący
tę samą operację. Jeżeli to odkryjesz, powinieneś wydzielić powtarzający się
kod, tworząc oddzielną procedurę. Czyniąc to, zmniejszysz liczbę miejsc,
gdzie ta szczególna operacja musi być weryfikowana lub modyfikowana.
Wspólna procedura może być modyfikowana tylko w jednym miejscu aplikacji.
Wszystko to prowadzi do znacznego podniesienia jakości kodu. Służy to
również drugiemu ważnemu celowi — wielokrotnej stosowalności kodu.
Jeżeli powszechnie stosowane operacje wydzielisz w oddzielnych procedurach,
przekonasz się, że będziesz mógł te procedury wykorzystać w wielu innych
aplikacjach. Taki kod tworzy rodzaj biblioteki, której możesz używać w celu
podniesienia własnej produktywności przy pisaniu następnych aplikacji.
Im więcej logicznie oddzielonych operacji zapiszesz w postaci kompletnych,
w pełni przetestowanych procedur bibliotecznych, tym mniej czasu będzie Ci
zajmować tworzenie kolejnych aplikacji.
(cid:141) Izolowanie złożonych operacji. W wielu rzeczywistych aplikacjach
znajdziesz sekcje logiki biznesowej bardzo złożone i bardzo specyficzne
dla danej aplikacji, dla której zostały zaprojektowane, co oznacza także
niemożliwość powtórnego ich użycia w innych projektach. Takie sekcje
należy izolować w oddzielnych procedurach w celu ułatwienia debugowania
i dalszego utrzymania.
(cid:141) Redukcja rozmiarów procedury. Zbyt długie procedury są trudne do
zrozumienia, debugowania i utrzymania nawet dla programistów, którzy je
napisali. Jeżeli odkryjesz procedurę licząca ponad 150 lub 200 linii kodu,
przekonasz się, że zwykle wykonuje ona kilka zadań, a więc powinna być
podzielona na kilka jednocelowych procedur.
(cid:141) Ograniczanie liczby argumentów procedury. Im więcej argumentów
procedura akceptuje, tym trudniej ją zrozumieć i mniej efektywnie będzie
używana. W zasadzie powinieneś ograniczać liczbę argumentów do pięciu
50
Excel. Programowanie dla profesjonalistów
lub mniej. I nie stosuj prostego zastępowania argumentów procedur przez
zmienne publiczne lub dostępne na poziomie modułu. Jeżeli okaże się, że
procedura wymaga więcej niż pięciu argumentów, będzie to znak, że sama
procedura lub logika aplikacji powinny zostać ponownie zaprojektowane.
Najlepsze praktyki określające ogólne
zasady tworzenia oprogramowania
W tym podrozdziale są omawiane najlepsze praktyki działania wspólne dla wszystkich
obszarów i etapów tworzenia aplikacji. Większość dalszych rozdziałów zaleca stoso-
wanie najlepszych praktyk odnoszących się do tematów poruszonych w tym rozdziale.
Komentowanie kodu
Dobre komentowanie kodu to najważniejsza z dobrych praktyk tworzenia aplikacji
Excela. Komentarze powinny w sposób prosty i kompletny objaśniać, jak kod jest
zorganizowany, w jaki sposób każdy obiekt i procedura powinny być używane oraz
jaki był cel napisania danego kodu. Komentarze służą także do zaznaczania zmian
dokonywanych wraz z upływem czasu, ale tym tematem zajmiemy się w dalszej części
tego rozdziału.
Komentarze kodu są ważne zarówno dla Ciebie, jak i dla innych programistów, którzy
— być może — będą nad Twoim kodem pracowali. Przydatność komentarzy dla in-
nych zdaje się być oczywista. To, czego możesz sobie nie uświadamiać do czasu
otrzymania pierwszej okrutnej lekcji, to przydatność komentarzy dla Ciebie. Często się
zdarza, że po napisaniu pierwszej wersji kodu, po upływie jakiegoś czasu jego twórcy
są proszeni o dokonanie istotnych zmian. Możesz być wtedy zaskoczony, jak obcy
wyda Ci się własny kod, nieoglądany od dłuższego czasu. Komentarze pomagają radzić
sobie z tym problemem.
Komentarze powinny być stosowane we wszystkich trzech głównych poziomach kodu
aplikacji: na poziomie modułu, procedury i pojedynczych sekcji lub linii kodu. Omówimy
dalej typy komentarzy odpowiednie dla tych wszystkich poziomów.
Komentarze na poziomie modułu
Jeżeli użyłeś, opisanej wcześniej w tym rozdziale, konwencji nazywania modułów,
każdy sprawdzający kod będzie miał z grubsza pojęcie o celu kodu zawartego w module.
Powinieneś to wesprzeć krótkim komentarzem na początku każdego modułu, gdzie
zawrzesz dokładniejszy opis celu kodu zapisanego w module.
Gdy mówiąc o komentarzach, używamy terminu moduł, określamy nim moduły
standardowe, moduły klas i moduły kodu związanego z formularzami użytkownika.
Rozdział 3. ♦ Najlepsze praktyki programowania w Excelu i VBA
51
Dobry komentarz na poziomie modułu powinien być umieszczony na samym początku
i wyglądać tak, jak przykład pokazany w listingu 3.2.
Listing 3.2. Przykładowy komentarz na poziomie modułu
Opis: Krótki opis celu kodu
zapisanego w tym module.
Option Explicit
Komentarze na poziomie procedury
Zwykle komentarze na poziomie procedury są najdokładniejszymi koment
Pobierz darmowy fragment (pdf)
