@Need absolutnie nie - kod ma się sam tłumaczyć, tyle komentarzy to śmietnik. Komentarze powinny być tylko w naprawdę tricki parts

@Need: Tylu komentarzy na bank. Nie potrzebujesz komentować każdej linijki, tym bardziej jeśli nazwy zmiennych same mówią do czego ona służy.

@pvpfleczu Oczywiście masz rację, ale czy przy aplikacjach desktopowych to rzeczywiście ma jakieś znaczenie? W dobie 16/32/64 GB ramu w co drugim kompie? Co innego przy pisaniu kody na mikroprocesory, oczywiście.

@Wolwgang: Czy ja wiem? Typ z poradnika z którego się uczyłem twierdził, że jest to bardziej przejrzyste bo patrzysz na komentarz i wiesz o co ci chodziło, nie musisz rozszyfrowywać kodu po przerwie, w sumie się z tym zgadzam, łatwiej jest wrócić do procesów myślowych, które mi towarzyszyły przy tworzeniu danego fragmentu.

@Need: Komentarz winien opisywać coś niejasnego. Kod powinieneś pisać tak aby nazwy zmiennych/metod/klas itd. rozumiały się same przez się, komentarze to jedynie dodatek. Może i kod jest w ten sposób jaśniejszy, ale pisanie komentarza do każdej linijki zajmie ci ruski rok, w tak małym programie się to sprawdzi, ale gdy będziesz miał coś na dajmy na to kilkaset linii kodu, to się zajebiesz samymi komentarzami.

@Wolwgang: @FoczanPingwianu: No ok, wezmę na to poprawkę.

@Need: A oprócz tego w sumie bardzo nie ma co poprawiać w tak małym programiku 1 metodowym, ewentualnie mogę się przyczepić do tego że raz używasz x += cośtam, a drugi raz x = x - cośtam. W sensie niejednostajny masz ten kod, raz lecisz samym operatorem, np. -=, a drugi raz używasz zwykłego równa się.

@Wolwgang: k, postaram się zapamiętać.

@Need: kod nie jest dla komputera tylko właśnie dla ludzi, więc komentarze raczej okazjonalnie jak to wyżej pisali

@Need: https://pastebin.com/6KYq6a2G

Przede wszystkim skup się na formatowaniu, ograniczaniu liczby zbędnych linii i ograniczeniu ifów - kod będzie czytelniejszy i łatwiej będzie się po nim poruszać. Dwa ostatnie ify możesz spokojnie zmienić w jeden.