"Lasciare più persone in grado di rivedere" un motivo per "scrivere c ++ come se fosse Java" in una certa misura?

L'intera affermazione "scrivi C ++ come Java" è un'assurdità totale. Non puoi scrivere C ++ come Java. Se hai provato, il tuo programma potrebbe perdere, o crash, o entrambi. C ++ non ha garbage collection. Il C ++ non ha eccezioni appropriate. Il C ++ ha un approccio molto diverso sul polimorfismo parametrico.

E dopo tutto ciò implica che tutti gli sviluppatori conoscono Java .

Inoltre, sembra che ti stia concentrando troppo sulla recensione. L'altro sviluppatore sarà in grado di trovare e correggere l'errore nel codice? Fondamentalmente, le recensioni sono solo lì per garantire che il revisore, e presumibilmente, gli altri in team, saranno ulteriormente in grado di operare il codice senza il suo autore.

Se si riformula la domanda come "si possono evitare alcune funzionalità del C ++ in modo che gli sviluppatori (a portata di mano) possano capire e modificare più facilmente", allora la risposta è definita "sì, ovviamente". La maggior parte dei progetti hanno nel loro codice guide di stile note "non usiamo ...". In realtà, ci sono molti sviluppatori C ++ esperti che pensano che alcune funzionalità non funzionino correttamente e dovrebbero essere evitate.

L'idea che i programmatori Java possano rivedere (cioè trovare errori in) o mantenere (cioè modificare) il codice C ++ se usi solo le caratteristiche che assomigliano a Java è malamente fuorviata.

Il modello di esecuzione sottostante di C ++ è abbastanza diverso da Java che qualsiasi tentativo di questo tipo porterà a bug, dolore e, in alcuni casi, costose azioni legali da parte dei clienti.

La principale difficoltà nel passaggio da Java a C ++ non è l'apprendimento di alcune funzionalità aggiuntive del linguaggio, è la comprensione del modello di esecuzione e degli idiomi. Perché new in Java è onnipresente, ma disapprovato nel moderno C ++? Come si impedisce la perdita di memoria? Come si prevengono gli iteratori use-after-free o invalidati? Cosa succede se si utilizza un indice non valido in un array e come ci si difende da questo? Queste sono le domande a cui un programmatore C ++ deve essere in grado di rispondere, e un programmatore Java non può proprio.

Non è affatto possibile scrivere C ++ come se fosse Java: perdite di memoria o semantica della proprietà, nessun uso esplicito di puntatori / riferimenti ecc. Inoltre, chiunque stia rivedendo il proprio codice, dovrebbe essere in grado di capire quale sia il codice sta facendo.

Significa che uno sviluppatore C ++ di apprendimento non può rivedere il tuo codice? Beh, certo, perché le recensioni di codice sono un ottimo strumento di apprendimento. Se usi una funzione di C ++ di cui il revisore non è a conoscenza, possono chiedere . Queste ulteriori domande possono anche aiutarti a cogliere errori.

Caratteristiche come l'ereditarietà multipla dovrebbero essere utilizzate con parsimonia, ma non con l'obiettivo di renderle più comprensibili per coloro che non sono a conoscenza delle caratteristiche / sintassi della lingua.

Un modo molto efficace per scrivere c ++ in modo che sia leggibile e potente è quello di nascondere la complessità degli esperti dietro interfacce semanticamente semplici.

Un grande esempio di questo è std::shared_ptr<T> . Ottenere l'implementazione di un std::shared_ptr corretto senza sacrificare le prestazioni o la correttezza nei programmi multi-thread non è banale.

Ma se il tuo revisore vede questo codice:

auto px = std::make_shared<X>();

È piuttosto ovvio per lui che px è un puntatore con proprietà condivisa, indipendentemente dalle complessità del conteggio dei riferimenti senza blocco o dalla cancellazione del tipo del deleter (per nominare ma 2).

Inoltre, se la proprietà di X è sempre condivisa, allora ha senso creare un wrapper di livello superiore che può essere trattato come un valore:

struct SharedX
{
    int some_x_method() { return px_->some_x_method(); }
private:
    std::shared_ptr<X> px_ = std::make_shared<X>();
}; 

Ora possiamo scrivere un codice come questo:

auto x = SharedX();
do_something_with(x);

e non possiamo creare accidentalmente un SharedX non valido.

Se vogliamo essere in grado di fornire handle nulli, possiamo farlo in sicurezza richiedendo che il programmatore ne richieda uno specifico:

struct SharedX
{
    SharedX()
    : px_(std::make_shared<X>())
    {}

    static SharedX invalidHandle() { return SharedX(nullptr); }

    int some_x_method() { 
        assert(px_);
        return px_->some_x_method(); 
    }

private:
    explicit SharedX(std::nullptr_t)
    : px_(nullptr)
    {}

private:
    std::shared_ptr<X> px_;
}; 

// create a new shared x
auto sx = SharedX();

// create an uninitialised shared x to act as a placeholder for
// some later value (eg if deserialised)
auto nsx = SharedX::invalidHandle();

Novizi, programmatori Java, esperti e puristi semantici di valore come me saranno tutti felici.