np. przewidywanie ruchów przeciwnika, kolizje] ale czy mnie wyśmieją to nie mam pojęcia -> https://hastebin.com/kogodegoki.cs
Cóż. Mieszasz w jednej klasie wszystko praktycznie, począwszy od ogólnych obliczeń matematycznych do bardzo specyficznej logiki gry. Nie ty jeden i nie ostatni (ja często jak zaczynam projekt piszę wszystko w jednym pliku, dopiero potem dzielę na kilka), ale jednak nie pokazywałbym tego potencjalnemu pracodawcy, bo ten kod to na oko jeden wielki śmietnik.
kryptyczne nazwy zmiennych:
static bool autoei, autoeo, autoq, readyaa;
no i literówka w nazwie zmiennej
lenght
różne magiczne liczby, które nie wiadomo co znaczą.
I dziwna tajemnicza logika, która powtarza się w wielu miejscach, ale z lekkimi modyfikacjami (syndrom programowania "copy paste"), np. tu jest jakaś logika "W":
static void WLogic()
{
if (Game.Time < laste + 0.75f || Game.Time < lastq + 0.5f || Player.CanUseSpell(SpellSlot.W) != SpellState.Ready)
return;
tu jest logika Q:
static void QLogic()
{
...
if (Game.Time > laste + 2f && Player.CanUseSpell(SpellSlot.E) == SpellState.Ready)
{
delay = 0.8f;
}
No i piramidki ifów z warunkami, które nie wiadomo skąd się wzięły.
I wszystko inne, co wygląda jakbyś przeczytał książkę "Czysty Kod" i robił na odwrót.
Czyli:
-
za mało uporządkowane to wszystko, zbyt dużo entropii w kodzie
-
piszesz tylko dla siebie (tajemnicze nazwy zmiennych, magiczne liczby, rzeczy typu QELogic
czy WLogic
które nie wiadomo w ogóle co znaczą (jeśli z jakichś powodów faktycznie w grze występuje "logika W" oraz "logika QE" - przecież są różne gry... - to wypadałoby to udokumentować jakoś).
Niestety nawet w przypadku jednoosobowego programowania to może być problem - bo siądziesz do swojego kodu po miesiącu i nie będziesz wiedział co robiłeś - a w przypadku pracy z innymi jeszcze bardziej jest potrzebne, żeby kod był uporządkowany, podzielony na logiczne części, nazwy zmiennych były opisowe, logika nie była bardziej skomplikowana niż to potrzeba (a u ciebie walają się ciągle jakieś ify nie wiadomo co sprawdzające), czasem też warto dać jakiś komentarz (ale czasem, oszczędnie, najlepiej jakby kod sam się komentował - ale jak wiadomo nie zawsze to jest możliwe).
Bo przyjdzie inny współpracownik i będzie chciał zrozumieć twój kod.