Riluttanza a vedere il codice di caldaia come un problema importante? Perché? Contromisure?

Question

Quasi ovunque ho lavorato ho incontrato un sacco di persone a cui non importava che producessero enormi quantità di codice standard.

Per me questa è una delle cose peggiori di sempre, porta a errori, è noiosa e aumenta il rumore.

Il peggiore esempio potrebbe essere la riluttanza di Microsofts a darci una sintassi migliore per questa noiosa "INotifyPropertyChanged" - roba. Non è possibile utilizzare le proprietà generate automaticamente, è necessario creare una grande ridondanza (replicando il nome della proprietà nella chiamata a "OnPropertyChanged" o qualunque sia il metodo del raiser).

Alcune persone arrivano ad accettare che la maggior parte dei programmi in molti linguaggi di programmazione consistono principalmente nello stesso codice ripetuto (rumore), non roba interessante (segnale). Vedi MSDN - esempi per esempio, c'è così tanto codice non necessario, ripetuto dappertutto (l'orribile "INotifyPropertyChanged" - modello che rovina tutto il flusso essendo solo la punta dell'iceberg).

Tuttavia, quando sollevo questo problema e propongo soluzioni come AOP (PostSharp.NET) o l'utilizzo di delegati (per i non-C# - gente: funzioni anonime, spesso realizzate utilizzando un operatore lambda), tutto quello che ottengo è "noi non importa ".

Qualcun altro qui è turbato dalla folle quantità di rumore introdotto dal codice boilerplate e chi vuole pensare ai modi per spingere le soluzioni al boilerplate - problema?

Answer 1

Per quello che vale, sono completamente dalla vostra parte.

I tipi di piastre sostengono che il codice ridondante ripetitivo è "automatico" o "coerente" e quindi non contribuisce alla complessità del codice. Spesso quando un linguaggio costringe gli sviluppatori a creare lo standard, l'industria crea IDE e altre stampelle per automatizzare il processo. Quindi, quando il costo apparente della produzione di quel codice boilerplate si avvicina a zero, la gente pensa che non costa nulla.

Hanno torto: il codice della piastra metallica contribuisce al codice in massa, e chiunque abbia il codice di manutenzione deve scavare attraverso il codice irrilevante per ottenere le parti importanti. Inoltre, poiché il codice generato automaticamente può essere modificato e spesso può essere modificato, può nascondere i bug introdotti da errori di battitura, ridenominazione incompleta o altri incidenti. Il costo del codice boilerplate non è nella sua creazione ma nella sua manutenzione - che molti progetti cercano di ignorare completamente.

Negli anni '80, ho visto riviste commerciali intonacate con annunci di debugger di perdita di memoria per C++, ed è stato un segno evidente per me che la gestione della memoria in C++ è seriamente danneggiata. Ora, nelle vicinanze di Java e C#, vedo una proliferazione di assist generatori di codice, e questo mi indica che quelle lingue hanno problemi che potrebbero essere risolti meglio altrove.

Scala ha problemi particolari, ma mi piace quello che hanno fatto con le proprietà e con i costruttori di auto-inizializzazione.

Answer 2

Basta uccidere. No, davvero, se qualcuno scrive un codice standard e non si cura di migliorarlo, dubito che potremmo chiamarlo professionale. Capita spesso che il management desideri vedere le attività svolte in fretta e l'unica cosa che rimane è spingere un codice di solo codice di sola scrittura per renderle felici. Se la tua direzione incoraggia questo approccio, cambia il tuo lavoro.