La lisibilité est-elle une raison valable pour ne pas utiliser const dans les paramètres (de référence)?

Lors de l'écriture de certaines fonctions, j'ai trouvé un mot clé const dans des paramètres comme celui-ci:

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

provoque souvent le fractionnement d'une ligne en 2 lignes dans IDE ou vim, donc je veux supprimer tous les mots clés const dans les paramètres:

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

est-ce une raison valable pour ne pas utiliser const? Peut-on maintenir les objets paramètres inchangés manuellement?

La lisibilité est une raison valable pour apprendre à utiliser les espaces blancs:

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

Situés là-bas, les paramètres ne seront pas confondus avec le corps de la fonction. En les localisant sur une ligne différente, vous n'aurez pas à les repositionner lorsque vous changez le nom de myFunctionen quelque chose de plus descriptif. Ne pas modifier la position des paramètres lorsqu'ils n'ont pas changé est quelque chose que les utilisateurs de l'outil de contrôle de source apprécieront.

constsignifie quelque chose. Ne le jetez pas simplement parce que vous manquez d'espace et d'idées. La lisibilité est primordiale, mais casser des choses en son nom est simplement abandonner.

En fait, le problème de lisibilité va certainement dans l'autre sens. Tout d'abord, vous pouvez résoudre trivialement votre run-on line en utilisant des espaces . Mais la suppression constne fait pas que raccourcir la ligne, elle change complètement la signification du programme.

Herb Sutter fait référence à la constréférence constcomme étant la plus importanteconst car une référence à constpeut se lier à un temporaire et prolonger sa durée de vie. Une référence lvalue à non- constne peut pas, vous avez besoin d'une variable distincte.

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

Cela signifie pour la convivialité que vous devrez introduire toutes ces variables temporaires juste pour pouvoir appeler votre fonction. Ce n'est pas génial pour la lisibilité, car ces variables n'ont pas de sens et n'existent que parce que votre signature est incorrecte.

La réponse simple est "non".

La réponse longue est que le constmot-clé fait partie du contrat proposé par la fonction; il vous indique que l'argument ne sera pas modifié. Dès que vous retirez la constgarantie, celle-ci disparaît. Rappelez -vous que vous ne pouvez pas maintenir raisonnablement constness (ou toute autre propriété) de quelque chose grâce à une documentation, conventions ou directives - si le constness est pas appliquée par le compilateur, quelqu'un va penser qu'ils peuvent rendre leur travail plus facile si elles tripoter le paramètre "juste un peu". Considérer:

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

void fnb(const Foo& foo);

Outre le fait que cette dernière version est plus concise, elle fournit également un contrat plus solide et permet au compilateur de vous aider à maintenir vos intentions. Le premier ne fait rien pour empêcher la fna(Foo&)fonction de modifier le paramètre que vous lui passez.

Comme dans la réponse @CandiedOrange, vous pouvez utiliser des espaces pour disposer le code et améliorer la lisibilité.

La suppression du constmot clé supprime la lisibilité car constcommunique des informations au lecteur et au compilateur.
Réduire la longueur horizontale du code est bien (personne n'aime faire défiler latéralement) mais il y a plus constque du texte. Vous pouvez le réécrire:

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

Ce qui ne change pas le contrat mais répond au besoin de réduire la longueur de ligne. Vraiment, je considérerais l'extrait ci-dessus comme moins lisible et opterais pour l'utilisation de plus d'espace comme déjà mentionné dans la réponse de CandiedOrange.

constest une fonctionnalité du code lui-même. Vous ne feriez pas de la fonction un non-membre pour supprimer la MyClass::section de la déclaration, alors ne supprimez pas leconst

La lisibilité est-elle une raison valable pour ne pas utiliser const dans les paramètres?

Non. L'omission constpeut modifier les fonctionnalités, perdre les protections constet peut potentiellement créer du code moins efficace.

Peut-on maintenir les objets paramètres inchangés manuellement?

Plutôt que de passer du temps à formater manuellement le code

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

Utilisez des outils de formatage automatique . Écrivez la fonction selon ses exigences fonctionnelles et laissez la mise en forme automatique gérer la présentation. L'ajustement manuel de la mise en forme n'est pas aussi efficace que l'utilisation de la mise en forme automatique et l'utilisation du temps gagné pour améliorer d'autres aspects du code.

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

Aussi longtemps que possible, il est préférable de garder const visible. Cela améliore beaucoup la maintenance du code (pas de supposition pour voir si cette méthode modifie mes arguments).

Si je vois beaucoup d'arguments dans une méthode, cela m'oblige à envisager la création d'un jaron basé sur un projet (Matrice, Employé, Rectangle, Compte) qui serait beaucoup plus court, plus facile à comprendre (élimine la longue liste d'arguments des méthodes).