Poprawnie – funkcja „Clean Project” w typowym IDE służy właśnie do usuwania wyników kompilacji, czyli wszystkich plików pośrednich i końcowych wygenerowanych podczas builda. Chodzi o katalogi typu bin, obj, target, build, różne *.class, *.o, *.exe tworzone automatycznie przez kompilator i linker. IDE po wywołaniu „Clean” nie rusza Twoich plików źródłowych, projektów, konfiguracji czy bibliotek w repozytorium – usuwa tylko artefakty budowania. Po co to się robi? Głównie po to, żeby wymusić tzw. „czystą kompilację” (clean build). Przydaje się to, gdy: zmieniłeś konfigurację projektu lub środowiska, dodałeś/zmieniłeś biblioteki, zmieniła się wersja kompilatora lub pluginów, a projekt zaczyna zachowywać się dziwnie, mimo że kod wygląda OK. Z mojego doświadczenia, w dużych projektach webowych (np. aplikacje w PHP z kompilowanym frontendem, czy Java/JavaScript z bundlerami) „Clean” pomaga pozbyć się starych, zcache’owanych plików, które potrafią powodować bardzo mylące błędy: IDE widzi jedno, a uruchamia się coś innego. Dobrą praktyką jest robienie pełnego „Clean & Build” przed wypuszczeniem wersji na produkcję albo przed puszczeniem testów integracyjnych, żeby mieć pewność, że wszystko zostało zbudowane od zera na podstawie aktualnego kodu. W wielu narzędziach CI/CD analogiczną rolę spełnia usuwanie katalogu build/ lub target/ przed kompilacją. W skrócie: Clean nie jest operacją destrukcyjną dla projektu, tylko porządkuje środowisko kompilacji i usuwa „śmieci” po poprzednich buildach, co wpisuje się w standardowe dobre praktyki pracy z kodem.
Funkcja „Clean Project” w środowisku IDE bywa mylona z kilkoma zupełnie innymi operacjami i stąd często biorą się błędne skojarzenia. Warto to sobie dobrze poukładać, bo w pracy z większymi projektami, szczególnie webowymi, znajomość tych różnic mocno ułatwia życie. Po pierwsze, Clean nie służy do usuwania całego projektu. IDE nie kasuje Twoich plików źródłowych, katalogów z kodem, konfiguracji, zasobów graficznych czy plików HTML, CSS, PHP, JS. Gdyby tak było, byłoby to po prostu niebezpieczne i kompletnie sprzeczne z dobrymi praktykami. Usuwanie projektu to zupełnie inna, osobna akcja, zwykle nazwana wprost „Delete project”, „Remove from workspace” itp. Clean ingeruje tylko w to, co zostało wygenerowane automatycznie podczas kompilacji lub procesu buildowania, czyli w artefakty, które w razie czego można bezpiecznie odtworzyć z kodu. Drugi częsty błąd to traktowanie funkcji Clean jako mechanizmu kompilowania projektu po zmianie plików źródłowych. W większości IDE kompilacją zajmują się polecenia typu „Build”, „Rebuild”, „Run”, ewentualnie system automatycznego builda po zapisaniu pliku. Clean sam z siebie nie kompiluje – on przygotowuje pole do ponownego, pełnego builda, usuwając stare binaria. Można to porównać do posprzątania warsztatu przed rozpoczęciem nowej pracy, a nie do samego naprawiania. Trzecie nieporozumienie to łączenie Clean z debugowaniem. Debugowanie polega na uruchamianiu skompilowanego programu z podpiętym debuggerem, stawianiu breakpointów, podglądaniu zmiennych, stosu wywołań itd. Funkcja Clean nie uruchamia aplikacji ani nie wchodzi w tryb debugowania, tylko czyści katalogi z wynikami wcześniejszych kompilacji. Typowy błąd myślowy polega na mieszaniu tych trzech etapów: porządkowania artefaktów (Clean), kompilacji/builda (Build/Run) i analizy działania programu (Debug). W praktyce, poprawna sekwencja przy dziwnych błędach to: Clean, potem pełny Build, a dopiero później ewentualne Debug. Takie rozdzielenie ról narzędzi jest standardem w większości popularnych IDE i systemów buildowania i dobrze jest się do niego przyzwyczaić, bo potem łatwiej przenosić się między różnymi technologiami i środowiskami.