La leggibilità è un motivo valido per non utilizzare const nei parametri (di riferimento)?

Quando ho scritto alcune funzioni, ho trovato una parola chiave const in parametri come questo:

void MyClass::myFunction(const MyObject& obj,const string& s1,const string& s2,const string& s3){
}

spesso causa la divisione di una riga in 2 righe in IDE o vim, quindi desidero rimuovere tutte le parole chiave const nei parametri:

void MyClass::myFunction(MyObject& obj,string& s1,string& s2,string& s3){
} 

è un motivo valido per non usare const? È possibile mantenere gli oggetti parametro invariati manualmente?

La leggibilità è un motivo valido per imparare a usare gli spazi bianchi:

void MyClass::myFunction(
        const MyObject& obj,
        const string& s1,
        const string& s2,
        const string& s3
) {
    return;
}

Posizionati laggiù i parametri non verranno confusi con il corpo della funzione. Individuandoli su una riga diversa non dovrai riposizionarli quando cambi il nome myFunctionin qualcosa di più descrittivo. Non cambiare la posizione dei parametri quando non sono cambiati è qualcosa che apprezzeranno gli utenti dello strumento diff di controllo del codice sorgente.

constsignifica qualcosa. Non buttarlo via solo perché sei a corto di spazio e idee. La leggibilità è re ma spezzare le cose nel suo nome è semplicemente rinunciare.

In realtà, il problema della leggibilità va decisamente nella direzione opposta. In primo luogo, è possibile risolvere banalmente la tua linea run-on utilizzando lo spazio bianco . Ma la rimozione constnon solo rende la linea più corta, ma modifica completamente il significato del programma.

Herb Sutter si riferisce al constriferimento a constcome il più importanteconst perché un riferimento a constpuò legarsi a un temporaneo e prolungarne la durata. Un riferimento al valore non- constimpossibile, è necessaria una variabile separata.

void foo_const(std::string const& );
void foo_nc(std::string& );

std::string some_getter();

foo_const(some_getter());      // OK
foo_const("Hello there"); // OK

foo_nc(some_getter()); // error
foo_nc("Nope");   // error

std::string x = some_getter(); // have to do this
foo_nc(x);                     // ok
std::string msg = "Really??";  // and this
foo_nc(msg);                   // ok

Ciò che ciò significa per usabilità è che dovrai introdurre tutte queste variabili temporanee solo per poter chiamare la tua funzione. Non è eccezionale per la leggibilità, poiché queste variabili sono prive di significato ed esistono solo perché la tua firma è sbagliata.

La risposta semplice è "no".

La risposta lunga è che la constparola chiave fa parte del contratto offerto dalla funzione; ti dice che l'argomento non verrà modificato. Nel momento in cui rimuovi la constgaranzia, la finestra si spegne. Ricordate che non si può ragionevolmente mantenere la costanza (o qualsiasi altra proprietà) di qualcosa utilizzando documentazione, convegni, o linee guida - se la costanza non viene applicata dal compilatore, qualcuno si pensa che possano fare il loro lavoro più facile se si giocherellare con il parametro "solo un po '". Ritenere:

// parameter "foo" is not modified
void fna(Foo& foo);

void fnb(const Foo& foo);

A parte il fatto che quest'ultima versione è più concisa, fornisce anche un contratto più forte e consente al compilatore di aiutarti a mantenere le tue intenzioni. Il primo non fa nulla per impedire alla fna(Foo&)funzione di modificare il parametro che le viene passato.

Come nella risposta @CandiedOrange, è possibile utilizzare gli spazi bianchi per disporre il codice e migliorare la leggibilità.

La rimozione della constparola chiave rimuove la leggibilità perché constcomunica informazioni al lettore e al compilatore.
Ridurre la lunghezza orizzontale del codice è buono (a nessuno piace scorrere lateralmente) ma c'è di più constdel testo. Puoi riscriverlo:

typedef string str;
typedef MyObject MObj;
void MyClass::myFunction(const MObj& o,const str& s1,const str& s2,const str& s3)

Ciò non modifica il contratto ma soddisfa la necessità di ridurre la lunghezza della linea. Veramente considererei lo snippet di cui sopra meno leggibile e opterei per utilizzare più spazi bianchi come già menzionato nella risposta di CandiedOrange.

constè una funzionalità del codice stesso. Non renderebbe la funzione un non membro per rimuovere la MyClass::sezione della dichiarazione, quindi non rimuovere ilconst

La leggibilità è un motivo valido per non utilizzare const nei parametri?

No. L'omissione constpuò modificare la funzionalità, perdere le protezioni conste potenzialmente creare codice meno efficiente.

È possibile mantenere gli oggetti parametro invariati manualmente?

Invece di dedicare tempo alla formulazione manuale del codice

void MyClass::myFunction(const MyObject& obj,const string& s1,const string& s2,const string& s3){
  //
}

Usa strumenti di formattazione automatica . Scrivi la funzione in base ai suoi requisiti funzionali e lascia che la formattazione automatica gestisca la presentazione. La regolazione manuale della formattazione non è efficiente come l'uso della formattazione automatica e l'utilizzo del tempo risparmiato per migliorare altri aspetti del codice.

void MyClass::myFunction(const MyObject& obj, const string& s1, const string& s2, 
    const string& s3) {
  // 
}

Il più a lungo possibile è meglio mantenere const visibile. Migliora molto la manutenzione del codice (nessuna ipotesi per vedere se questo metodo cambia i miei argomenti).

Se vedo molti argomenti in un metodo, mi costringe a considerare la creazione di jaron basato sul progetto (Matrix, Employee, Rectangle, Account) che sarebbe molto più breve, più facile da capire (elimina un lungo elenco di argomenti ai metodi).