A legibilidade é uma razão válida para não usar const nos parâmetros (referência)?

Ao escrever algumas funções, encontrei uma palavra-chave const em parâmetros como este:

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

geralmente causa a divisão de uma linha em 2 linhas no IDE ou no vim, então eu quero remover todas as palavras-chave const nos parâmetros:

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

esse é um motivo válido para não usar const? É possível manter os objetos de parâmetro inalterados manualmente?

A legibilidade é um motivo válido para aprender a usar o espaço em branco:

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

Localizados ali, os parâmetros não serão confundidos com o corpo da função. Ao localizá-los em uma linha diferente, você não precisará reposicioná-los quando alterar o nome myFunctionpara algo mais descritivo. Não alterar a posição dos parâmetros quando eles não foram alterados é algo que os usuários da ferramenta de controle de origem apreciarão.

constsignifica alguma coisa. Não jogue fora só porque você está sem espaço e idéias. A legibilidade é rei, mas quebrar as coisas em seu nome é apenas desistir.

Na verdade, a questão da legibilidade definitivamente vai na outra direção. Primeiro, você pode resolver trivialmente sua linha de execução usando o espaço em branco . Mas remover constnão apenas torna a linha mais curta, mas altera completamente o significado do programa.

Herb Sutter refere-se à constreferência constcomo a mais importanteconst porque uma referência a constpode se ligar a um temporário e prolongar sua vida útil. Uma referência lvalue para non- constcan, você precisa de uma variável separada.

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

O que isso significa para a usabilidade é que você precisará introduzir todas essas variáveis ​​temporárias apenas para poder chamar sua função. Isso não é ótimo para facilitar a leitura, pois essas variáveis ​​não têm sentido e existem apenas porque sua assinatura está errada.

Resposta simples é "não".

A resposta longa é que a constpalavra-chave faz parte do contrato que a função oferece; informa que o argumento não será modificado. No momento em que você remove a constgarantia, sai pela janela. Lembre-se que você não pode razoavelmente manter o constness (ou qualquer outra propriedade) de algo usando documentação, convenções ou diretrizes - se o constness não é forçado pelo compilador, alguém vai pensar que eles podem fazer o seu trabalho mais fácil se eles mexer com o parâmetro "só um pouquinho". Considerar:

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

void fnb(const Foo& foo);

Além do fato de que a última versão é mais concisa, ela também fornece um contrato mais forte e permite que o compilador o ajude a manter suas intenções. O primeiro não faz nada para impedir que a fna(Foo&)função modifique o parâmetro que você passa para ele.

Como na resposta @CandiedOrange, você pode usar espaços em branco para organizar o código e melhorar a legibilidade.

A remoção da constpalavra - chave remove a legibilidade porque constcomunica informações ao leitor e ao compilador.
Reduzir o comprimento horizontal do código é bom (ninguém gosta de rolar para o lado), mas há mais do constque texto. Você pode reescrevê-lo:

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

O que não altera o contrato, mas atende à necessidade de reduzir o comprimento da linha. Na verdade, eu consideraria o trecho acima menos legível e optaria por usar mais espaços em branco, como já mencionado na resposta de CandiedOrange.

consté uma funcionalidade do próprio código. Você não tornaria a função um não-membro para remover a MyClass::seção da declaração; portanto, não remova oconst

A legibilidade é uma razão válida para não usar const nos parâmetros?

Não. Omitir constpode alterar a funcionalidade, perder proteções constfornece e pode potencialmente criar código menos eficiente.

É possível manter os objetos de parâmetro inalterados manualmente?

Em vez de gastar tempo formatando manualmente o código

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

Use ferramentas de formatação automática . Escreva a função de acordo com seus requisitos funcionais e permita que a formatação automática lide com a apresentação. O ajuste manual da formatação não é tão eficiente quanto o uso da formatação automática e o tempo economizado para melhorar outros aspectos do código.

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

Contanto que possível, é melhor manter a const visível. Isso melhora bastante a manutenção do código (sem adivinhações para ver se esse método altera meus argumentos).

Se eu vejo muitos argumentos em um método, isso me obriga a considerar a criação de jaron baseado em projeto (Matriz, Empregado, Retângulo, Conta) que seria muito mais curto, mais fácil de entender (elimina uma longa lista de argumentos para métodos).