Używanie napisów w aplikacji

Napisy?

Typ string jest jednym z najczęściej używanych typów danych w aplikacji. Gdy go potrzebujemy, to po prostu otwieramy cudzysłów, wpisujemy wartość i zamykamy cudzysłów. Bardzo często nawet nie zastanawiamy się, czy to dobre podejście.

Niestety w dłuższej perspektywie takie podejście oznacza problemy. A to podczas pobierania wartości ze słownika robimy w kluczu literówkę, o której dowiadujemy się dopiero podczas wykonywania kodu (o ile go przetestujemy). A to musimy w 20 miejscach poprawić komunikat wyświetlany użytkownikowi, a nie zawsze CTRL + H to dobre rozwiązanie.

Dlatego warto się na chwilę zatrzymać i zastanowić, czy nie można zrobić tego lepiej.

Rodzaje napisów w aplikacji

Na przestrzeni lat zauważyłem, że napisy w aplikacji możemy podzielić na dwa rodzaje:

  • wewnętrzne aplikacji – używane tylko w kodzie, na przykład nazwa ustawienia, klucz do słownika itp.
  • wyświetlane użytkownikowi w interfejsie aplikacji.

Znając już rodzaje napisów w aplikacji, możemy dla każdego z nich przygotować mechanizm, który ułatwi pracę z nimi.

Napisy wewnętrzne aplikacji

Do stringów tego rodzaju wykorzystuję klasy ze stałymi. Napisy grupuję według użycia i dodaję je do dedykowanych klas. Na przykład nazwy ustawień z pliku konfiguracyjnego będą znajdować się w klasie SettingsNames:

Później korzystam z tych stałych w aplikacji. Dzięki temu unikam wszelkiego rodzaju literówek, bo w każdym miejscu używam tej samej wartości. Dodatkowo intellisense podpowiada dostępne wartości, co również jest bardzo pomocne:

Na ogół używam stałych (słowo kluczowe const w C#), ale czasami to nie wystarcza. Przykładowo WPF nie umożliwia bindowania do stałej, dlatego czasami korzystam z klas z polami statycznymi typu readonly, ale to są pojedyncze przypadki i na ogół w WPF:

Darmowy kurs Visual Studio

Pracując z setkami programistów, zauważyłem, że większość osób nie pracuje efektywnie w Visual Studio. W skrajnych przypadkach korzystali z kopiowania z wykorzystaniem menu Edit. Wiem, że to dziwne, ale naprawdę niektórzy tak pracują. Dlatego postanowiłem stworzyć kurs Visual Studio – aby pomóc koleżankom i kolegom w efektywniejszej pracy.

Przygotowałem 20 lekcji e-mail, w których pokażę Ci, w jaki sposób pracować efektywniej i szybciej w Visual Studio. Poznasz dodatki, bez których nie wyobrażam sobie pracy w tym IDE.

Po więcej informacji zapraszam na dedykowaną stronę kursu: Darmowy Kurs Visual Studio.

Quiz C#

Ostatnio przygotowałem również quiz C#, w którym możesz sprawdzić swoją wiedzę. Podejmiesz wyzwanie?

Napisy wyświetlane użytkownikowi

Drugim rodzajem stringów używanych w aplikacji są napisy wyświetlane w interfejsie użytkownika (czy też innych miejscach, np. w wygenerowanym dokumencie). Do nich wykorzystuję pliki resource’ów. Dzięki temu również na poziomie kodu mam napisy pogrupowane w klasy, podpowiedzi intelisense oraz dodatkowo z czasem mogę zdecydować się na tłumaczenie aplikacji na inne języki.

A w jaki sposób organizować napisy w resource’ach? Widziałem różne sposoby. Niektórzy mają jeden duży plik, w którym znajdują się wszystkie napisy. Inni tworzą plik per moduły. Na przykład jeden dla użytkowników, drugi dla produktów i tak dalej. Myślę, że nie ma jednego idealnego sposobu i wszystko zależy od aplikacji, którą tworzymy.

Osobiście najczęściej tworzę pliki resource per plik widoku. Nie ma tutaj znaczenia, czy to jest cały widok, czy tylko jakaś kontrolka osadzana w innym widoku. Dodatkowo mam jeszcze pliki globalne, dla całej aplikacji oraz dla poszczególnych modułów, w których wrzucam często używane napisy.

U mnie takie podejście sprawdza się w aplikacjach, ale niestety musimy się nastawić, że z czasem, gdy będziemy tłumaczyć aplikacje, będziemy musieli nieco zmienić pliki resource’ów. Może się okazać, że w jednym z widoków, z racji braku miejsca, chcemy inaczej przetłumaczyć globalny napis. Przestajemy więc korzystać w tym miejscu z globalnego resource’a, a wpis dodajemy w dedykowanym dla danego widoku resource’u.

Dodatkowo mam jeszcze pliki resource’ów dla niektórych klas w aplikacji. Są to głównie klasy logiki biznesowej, w których znajdują się komunikaty, np. błędy walidacji czy inne informacje.

Osobiście do logów korzystam też z plików resource’ów. Są to dedykowane pliki, które później na ogół nie są tłumaczone i są tylko w języku angielskim lub polskim.

Przykład

Tym razem przykład (https://github.com/danielplawgo/WorkingWithStrings) jest bardzo prosty. Jest to prosta aplikacja konsolowa, która wyciąga wartość z app settings (tak, wiem, jest jeszcze drugi mechanizm, który generuje ładne silnie typowane klasy) i wyświetla komunikat użytkownikowi z pliku resource. Po pobraniu przykładu wystarczy go uruchomić. Nie jest potrzebna dodatkowa konfiguracja.

Podsumowanie

Jak pokazuje życie, warto zastanowić się nad tym, w jaki sposób organizujemy używanie napisów w aplikacji. Za każdym razem, gdy potrzebuję dodać nowego stringa, zastanawiam się, do jakiej kategorii należy. Następnie tworzę nową stałą lub nowy wpis w pliku resource. Narzut na tę dodatkową pracę nie jest zbyt duży, szczególnie że szukanie literówki w pobieraniu jakichś danych może zająć dużo więcej czasu.

A jak Ty organizujesz używanie napisów w aplikacji?

1 thought on “Używanie napisów w aplikacji

Dodaj komentarz

Twój adres email nie zostanie opublikowany. Pola, których wypełnienie jest wymagane, są oznaczone symbolem *