Niewidomi VS dobry, pachnący kod

Nienawidzę takich generalizacji, ale patrząc sobie na projekty niewidomych programistow (NVDA, TWBlue, SoundRTS, Magic Keys czy nawet jakies pluginy do Zhengdu) widze jak bardzo niechlujny jest to kod. Brak uzycia jakichkolwiek wzorcow projektowych, wpychanie miliona konceptów które wogóle ze sobą nie współgrają, niezgodność nazw, kompletne nie liczenie się ze stylami nazewnictwa w językach programowania, używanie przestarzałych frameworków i takdalej... Czy to ja przesadzam czy coś jest na żeczy? Jak tak to z czego waszym zdaniem to wynika i jak ztym walczyć? Ja sam długo miałem taki problem i umnie wynikało to z wrogości i arogancji niektórych osób przez co wolałem robić coś źle, niż zapytać i ogarnąć lepiej. Dopiero gdy zacząłem pracować z widzącymi programistami odblokowałem się i zacząłem pytać. Wielu niewidomych zaczęło pisać kod od audiogames.net gdzie taka atmosfera właśnie występuje.

Przestarzałe frameworki mogą wynikać czasem ze względów zgodnościowych.

Ja niestety nie potrafię Ci pomóc w tej kwestii i niczego powiedzieć, bo sam prowadzę kod tak, jak prowadzę i sam używam często przestażałych frameworków tylko p to, że zwyczajnie działają do tego, co potrzebuję zrobić.

Poruszyłeś kilka niezależnych kwestii.

1. Niechlujny kod, brak wzorców projektowych.
Pamiętaj, że niewiele osób niewidomych może się nazwać programistami. Jest duża różnica między kimś, kto napisał wtyczkę, a jest programistą.
Wielu niewidomych programistów nigdy nie pracowało w grupie nad dużym projektem, nie było ocenianych za kod. Wzorce projektowe są niezwykle użyteczne, ale z początku mogą być mało intuicyjne.
A śmietnik w kodzie po prostu działa, więc jak długo taka osoba sobie coś tam koduje, może nie odczuwać potrzeby rozwijania się dalej.

2. Niestosowanie nazewnictwa.
Tu się kompletnie nie zgodzę. Widziałem wiele dużych projektów, które nie stosowały nazewnictwa proponowanego dla języka.
Ważna jest konsekwencja w projekcie, ale można stworzyć własną, inną od proponowanej.
Nawet w C# co projekt, to inna konwencja nazywania prywatnych metod i zmiennych.

3. Przestarzałe frameworki.
To bardzo zależy. Czasem jak działa, to naprawdę nie ma sensu ruszać. Jednym razem po prostu stare jest jare, innym programista trzyma się technologii, którą zna, nie wiedząc, że świat poszedł do przodu.
Wśród niewidomych są popularne pewne biblioteki i to jest złe, bo trzymamy się rozwiązań przestarzałych i problematycznych. Ale nie oznacza to, że stosowanie starych rozwiązań co do zasady jest niewłaściwe.

1. To prawda. Dlatego mowię o jednak sporych i popularnych projektach pokroju NVDA.
2. Wiaomo, nigdy nie wiem czy prywatne pola to private readonly int _myField czy private readonly myField, ale tutaj mamyhhdo czynienia z brakiem konsekwencji bardzo często

Tak, NVDA bardzo na to cierpi. Ale NVDA ogólnie cierpi na jakiś dziwny chaos twórczy: zmiany w API co rok, odpowiadanie na PR po kilku miesiącach, brak sensownej dokumentacji i roadmapy...

Uważacie, że mvc w każdej możliwej aplikacji to ułatwienie? Klasa, która tylko pośredniczy między widokiem a tym, co się dzieje pod spodem, znaczy model, naprawdę wg was jest niezbędnie konieczny. Można się w widoku odwoływać bezpośredno do controllera, o ile dobrze rozumem mvc, czyli do tego, co się powinno dziać i wyciągać wszystko bezpośrednio... W większości językó programowania, które znam, a które są językami jak php czy Python, wywołanie modelu i pobraniu przy jego pomocy instajcni controllera i tak tworzy nową instancję, a nie operuje na poprzedniej. Jaki więc to ma sens w takim przypadku?

Z drugiej strony Elten też na to cierpi i dość łatwo wyjaśnić, dlaczego. Po prostu w roku 2014 nie miałem tej wiedzy, którą mam teraz, a przepisywanie całego Eltena na ładny MVC, albo chociaż rozróżnienie backendu od frontendu, to masa czasu i mało poprawy dla użytkowników.
Więc może podobnie się stało z NVDA.

@zywek
Nie, MVC nie jest zawsze dobrym pomysłem, dlatego nie jest jedynym wzorcem. Ale w wielu aplikacjach GUI jest bardzo dobry.
No i on zakłada, że ciągle pracuje się na jednej instancji. Przykładowo w mainie tworzony jest model, przekazywany do kontrolera i obydwa dla widoku. I to bardzo wygładza kod.
Ale często wystarczy oddzielenie warstwy widoku od logiki aplikacji i to już dużo pomaga.

Ogólnie są takie aplikacje, w których sztuczne rozdzielenie modelu i kontrolera jest bardzo trudne i niepotrzebne.
MVC najlepiej się sprawdza, gdy pracujemy z API, bazą danych lub czymś podobnym.

Mówiłęm o pythonie, gdzie importem i tak wywołujesz cały kod za każdym razem, więc w tym wypadku jest on bez sensu.

Nie, w Pythonie też ma sens. MVC to logistyka, nie wydajność.
Kiedyś napisałem taki programik do pokazywania jak to powinno działać, w Pythonie właśnie. Jak go znajdę, podrzucę.

MVC przestaje być dobrym pomysłem jak masz aplikację MDI. Wtedy w sumie nie wiem jak się zachować.

Zależy od rodzaju tego MDI. Jeśli bazujesz na różnych seriach danych, MVC lub MVVM są bardzo dobrymi wzorcami.