Inputy pod optymalizację: enum zamiast listy w stringu

W skrócie: w oknie ustawień Testera zaznaczam do optymalizacji tylko to, co ma typ liczbowy, logiczny albo enum. Tekst się nie optymalizuje. Dlatego każdy nowy input projektuję od razu z pytaniem “czy to będzie w siatce?”. Jeśli tak, zamiast listy wpisanej w tekst robię enum, a wartość “wyłączone” musi być jedną z jego pozycji.

Jak to wyszło u mnie

Dodałem do biblioteki filtr oparty o świecę impulsową. Chciałem, żeby mógł sprawdzać dodatkowe interwały, więc zrobiłem jeden input tekstowy, w którym wpisuje się interwały po przecinku. W kodzie wyglądało to rozsądnie, a w Testerze okazało się, że tego pola nie da się wstawić do siatki. Żeby sprawdzić, który interwał pomaga, musiałbym ręcznie przepisywać tekst przed każdym przebiegiem.

Przerobiłem to na dwa osobne inputy typu enum interwału. Wartość “bieżący interwał wykresu” znaczy tyle co “wyłączone”. Teraz Tester sam przechodzi po liście interwałów, a ja dostaję jeden wynik na każdy.

Które typy Tester przejdzie sam

Liczby całkowite i rzeczywiste: start, krok, stop. Najprostszy przypadek.
Typ logiczny: dwie wartości, prawda i fałsz. Dobry do włączania całej funkcji.
Enum: lista wartości z deklaracji. Tester pokazuje je w oknie ustawień i potrafi po nich iterować.
Tekst: nie ma zakresu, więc nie ma czego optymalizować.

Z tego wynika prosta zasada projektowa. Gdy chcę mieć wybór “jedno z kilku”, robię enum. Gdy chcę mieć wybór “dowolny podzbiór”, robię kilka osobnych inputów logicznych, każdy z własną flagą. Podzbiory przez tekst to zawsze ślepy zaułek.

Wartość “wyłączone” musi być w zakresie

Optymalizacja ma sens tylko wtedy, gdy porównuję funkcję włączoną z wyłączoną na tych samych danych. Dlatego przy inputach opcjonalnych dbam o to, żeby stan “nie używam” był dostępny w siatce. Przy interwale to wartość bieżącego wykresu. Przy liczbie, np. odległości w ATR, zero znaczy “bez filtra”. Bez tego nie wiem, czy filtr w ogóle coś daje, bo nie mam punktu odniesienia, tylko same warianty z włączonym filtrem.

Obok tego mam stałą zasadę, że funkcje opcjonalne są domyślnie wyłączone i mają jawną flagę włączającą. Wtedy domyślny zestaw ustawień zawsze odpowiada botowi bez dodatków.

Enum czytam po opisie, nie po cyfrze

Pod spodem enum to liczba, i w pliku z ustawieniami zobaczę właśnie ją. W oknie Testera widzę natomiast opis z komentarza przy wartości. Dlatego każdej wartości dopisuję komentarz po polsku, który mówi, co się dzieje, np. “stan trzymany do świecy przeciwnej” zamiast samego numeru trybu. Po miesiącu nikt, łącznie ze mną, nie pamięta, że “tryb 1” to coś konkretnego. W notatkach i rozmowach też podaję opis, a cyfrę tylko wtedy, gdy mówię wprost o zawartości pliku ustawień, i wtedy z opisem obok.

Ten sam zabieg stosuję w botach, które mają kilka sposobów liczenia stop lossa. Sposób wyboru jest jednym enumem, a parametry każdego sposobu osobnymi liczbami. Siatka przechodzi wtedy po trybach, a potem po ich parametrach.

Zakres ustawiam przy oddaniu zmiany

Przy każdej zmianie, która dodaje input, zapisuję od razu, jak go wstawić do siatki: od czego do czego, jaki krok, które wartości enum porównać. To oszczędza wracanie do kodu po tygodniu. Zakres w stylu start-krok-stop dla liczb powinien dawać mało przebiegów, bo każdy dodatkowy parametr mnoży ich liczbę.

Checklista

Czy input da się wstawić do siatki: logiczny, liczba albo enum?
Czy nie wpisuję listy wartości w tekst?
Czy “wyłączone” jest jedną z wartości w zakresie?
Czy każda wartość enum ma czytelny komentarz, widoczny w Testerze?
Czy funkcja opcjonalna jest domyślnie wyłączona?
Czy zapisałem, jaki zakres ustawić w Testerze?

[DO UZUPEŁNIENIA: konkretny przykład siatki po enumie interwału i jej wynik]

Powiązane

Źródła

Brak źródeł zewnętrznych - własna praca nad filtrem w bibliotece (październik 2026).

Ostrzeżenie: artykuł ma charakter edukacyjny i nie jest poradą inwestycyjną. Wyniki z przeszłości nie gwarantują przyszłych. Handel na rynkach finansowych wiąże się z ryzykiem utraty kapitału.