[...] nobody clearly managed to explain to me WHY it's is so important
to restricting yourself with private scope to prevent others
programmers to break data organisation consistency of some kind.
In una squadra abbastanza piccola con una base di codice abbastanza piccola, che è davvero ben coordinata con buoni standard (potrebbe essere una sola persona), spesso è possibile trovare software affidabile che lascia tutti i dati alla luce per chiunque sia in contatto con tutti i campi di dati di struct esposti a tutto campo e con la definizione di struct a cielo aperto per chiunque abbia accesso a tale intestazione. La legge di Murphy non si applica sempre in questi casi.
Ma ho lavorato nello scenario opposto di un'enorme base di codice con molti milioni di LOC risalenti agli anni '80 con un grande team di sviluppatori di tutto il mondo in cui ci siamo incontrati faccia a faccia ogni pochi mesi, liberamente - coordinato, a volte a malapena la stessa lingua, senza standard di codifica tranne SDK che la gente spesso non seguiva comunque, nessun test di unità / integrazione, usando SVN senza diramazioni e a volte andando a 6 settimane senza verificare il codice, solo per bombardarci con bug, e non è stato fino ad allora che ho veramente capito il valore di nascondere le informazioni e mantenere gli invarianti .
Mi sono occupato di bug in cui non riuscivo nemmeno a riprodurre il problema in modo coerente sulla mia macchina, ea volte nessuno di noi poteva tra l'intero team. E quando finalmente potevo fortunatamente riprodurre il problema segnalato dall'utente o qualcosa che lo somigliava dopo tutti i tipi di tentativi ed errori (e le prove e gli errori spesso richiedevano ore perché l'inefficienza del nostro software si combinava con l'esecuzione nel debug contro la produzione dell'utente finale i dati richiedevano spesso più di 15 minuti solo per caricare i dati), lo tracciavo a qualcosa come struct per un tipo di stringa che aveva un len impostato su un numero negativo negativo, come una lunghezza di stringa di -921141282 .
Questo non dovrebbe mai accadere, ma chi lo ha fatto? Quindi ho dovuto impostare i punti di interruzione della memoria e scoprirlo, e quando finalmente l'ho fatto, era come un'interazione a cascata di variabili non inizializzate utilizzate aritmeticamente che alla fine si aggiungevano a un campo len di stringhe impostato su un numero di garbage negativo e che il codice non era stato modificato negli anni. Ha volato sotto il radar.
E tutto quel tempo dopo aver incontrato molti bug come questo, ho pensato a me stesso, quanto sarebbe più affidabile il nostro software se usasse solo getters e setters ? Getter e setter sono generalmente indicativi dei peggiori tipi di design di interfacce possibili, ma un setter potrebbe almeno innescare un errore di asserzione se qualcuno tentasse di impostare la lunghezza di una stringa su un valore negativo. Avremmo potuto intercettare quell'errore anni prima nel momento preciso in cui era stato introdotto in secondi, non il culmine di ore di sforzi investigativi. E questo è solo pensare egoisticamente come sviluppatore; non copre tutte le ore di dolore che avrebbe potuto salvare anche gli utenti e il team di QA. Sai che il tuo sistema si trova in un brutto posto quando stai sognando quanto potrebbe essere migliore se usasse setter e getter di fronte agli ultimi 35 bug che hai passato a risolvere tutti i nottambuli.
Abbiamo persino avuto casi in cui structs è stato documentato in un modo che afferma che nessun altro dovrebbe accedere a quei campi di dati, solo per trovare punti nel sistema che accede a quei campi di dati.
Quindi questi sono i tipi di cose che puoi davvero apprezzare al massimo affrontando quello scenario peggiore, ma spesso lo farai a meno che tu non abbia la fortuna di passare il resto della tua vita a lavorare su basi di codice più piccole con team coordinati e forti standard di codifica.
What is beautiful code in C++ [...]?
È difficile. Sto ancora cercando di capirlo. La maggior parte del codice che considero bello che ho scritto nel corso degli anni, o almeno affidabile e relativamente atemporale e stabile (non ho bisogno di / volere cambiamenti) è stata scritta in C e recentemente Lua. Faccio ancora fatica a scrivere codice C ++ che sembra passare la prova del tempo al punto in cui non rifletterò su di esso qualche anno dopo e almeno desidero potrei cambiarlo. Mi sembra che sia diventato più facile dal C ++ 11, ma ho bisogno di alcuni anni per scoprire quanto il mio codice riesce a sopravvivere senza bisogno di modifiche per dirlo con certezza. Per me l'ultima "bellezza" è la "stabilità", come nel codice che non ha bisogno e non tenta nemmeno ulteriori cambiamenti, ma rimane pertinente e utile per gli anni a venire, poiché questo è un codice che comporta costi di manutenzione zero. / p>