Po wielu latach, próbach migracji do ociężałych Eclipse i Visual Studio. Po wkurzaniu się na powolną prędkość Android Studio i licencyjne ograniczenia Qt Creatora. W końcu znalazłem coś, co na osi wydajności leży nieopodal C::B i Notepada++, a jednocześnie można skonfigurować do wygodnego kompilowania i debugowania. I nie jest tym czymś shareware’owy Sublime Text tylko totalnie darmowe i otwarte rozwiązanie.
Visual Studio Code
Środowisko napisane w technologiach webowych w oparciu o framework Electron, a mimo to dość lekkie (150MB na dysku, 100MB w RAMie), szybkie i responsywne (nie mylić z responsywnością stron internetowych). Aplikacja jest rozwijana przez Microsoft, ale nie tylko – sam projekt jest open-source i rozwijany na GitHubie.
Po instalacji oferuje niewiele więcej ponad możliwość edycji tekstu – rozszerza się go wyspecjalizowanymi wtyczkami. Dzięki temu edytor pozostaje lekki i umie tylko to, co chcemy żeby umiał. Edytor nie wprowadza żadnych własnościowych formatów pliku projektu, tylko traktuje dany folder jako projekt. Zakłada sobie w nim katalog .vscode, gdzie grzecznie w JSONie trzyma konfigurację specyficzną dla projektu.
VSCode przetestowałem we współpracy z VBCC i działa świetnie, bo działa w oparciu o mój własny makefile. I tu jest cały szkopuł – nie zrobi on nic za Ciebie. Jest to dla niego na plus, bo każdy projekt, który przyszło mi budować, rządzi się swoimi prawami konfiguracji i budowania, więc nie wymaga jakichś dziwnych ujednoliceń pod jego widzi-mi-się i wewnętrzny sposób kompilacji, tylko wpisujesz, jakie polecenie ma wywołać przy komendzie “build” i już.
Są jednak rzeczy, które mnie trochę denerwują, ale idzie je wyeliminować:
- Brak przejrzystego, jasnego schematu kolorów dla składni, ale można zdefiniować własny;
- Można mieć jednocześnie otwarty tylko jeden projekt, ale to już wisi w issues od jakiegoś czasu, więc pewnie coś z tym zrobią.
Epitafium Code::Blocks
Sam C::B był bardzo fajnym IDE, które zajmowało niewiele miejsca na dysku, działającym z prędkością NPP-podobną. Niestety rozwój się ślimaczy, przez co używanie go jest nadal możliwe, choć już niewygodne. Konfiguracja do współpracy z innymi kompilatorami niż MinGW byłaby zapewne możliwa, ale jeśli nie znajduje się on na liście obsługiwanych kompilatorów, to konfiguracja staje się koszmarna.
C::B popełnił ten błąd, że robił za dużo za użytkownika jednocześnie zbyt wolno się rozwijając, przez co skazywał go na ograniczoną funkcjonalność albo ciągłą walkę z IDE.