Czy czytelność jest ważnym powodem, aby nie używać const w parametrach (referencyjnych)?

Podczas pisania niektórych funkcji znalazłem słowo kluczowe const w parametrach takich jak to:

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

często powoduje podział linii na 2 linie w IDE lub vimie, więc chcę usunąć wszystkie słowa kluczowe const w parametrach:

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

czy to ważny powód, aby nie używać const? Czy utrzymywanie obiektów parametrów pozostaje niezmienione ręcznie?

Czytelność jest ważnym powodem, aby nauczyć się korzystać z białych znaków:

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

Umieszczone tam parametry nie będą mylone z treścią funkcji. Lokalizując je w innym wierszu, nie będziesz musiał zmieniać ich położenia, gdy zmienisz nazwę myFunctionna coś bardziej opisowego. Nie zmienianie pozycji parametrów, gdy nie uległy zmianie, jest czymś, co docenią użytkownicy narzędzia do kontroli źródła.

constcoś znaczy Nie wyrzucaj tego tylko dlatego, że brakuje Ci miejsca i pomysłów. Czytelność jest królem, ale łamanie rzeczy w imię jest po prostu rezygnacją.

W rzeczywistości kwestia czytelności zdecydowanie idzie w innym kierunku. Po pierwsze, możesz w prosty sposób rozwiązać swoją linię run-on, używając białych znaków . Ale usunięcie constnie tylko powoduje, że linia jest krótsza, ale całkowicie zmienia znaczenie programu.

Herb Sutter odnosi się constdo consttego, co najważniejsze,const ponieważ odniesienie do constmoże wiązać się z chwilowym i przedłużyć jego żywotność. Odwołanie do wartości nie constjest niemożliwe, potrzebujesz osobnej zmiennej.

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

Dla użyteczności oznacza to, że będziesz musiał wprowadzić wszystkie te zmienne tymczasowe, aby móc wywołać swoją funkcję. To nie jest świetne dla czytelności, ponieważ te zmienne są bez znaczenia i istnieją tylko dlatego, że twoja sygnatura jest błędna.

Prosta odpowiedź brzmi „nie”.

Długa odpowiedź brzmi: constsłowo kluczowe jest częścią umowy, którą oferuje funkcja; informuje, że argument nie zostanie zmodyfikowany. W momencie usunięcia constgwarancji ta znika z okna. Pamiętaj, że nie można zasadnie utrzymywać constness (lub innego mienia) coś za pomocą dokumentacji, zjazdy, lub wytyczne - jeśli constness nie jest wymuszana przez kompilator, ktoś będzie myśleć, że mogą uczynić swoją pracę łatwiej, jeśli bawić z parametr „tylko trochę”. Rozważać:

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

void fnb(const Foo& foo);

Oprócz tego, że ta ostatnia wersja jest bardziej zwięzła, zapewnia również silniejszą umowę i pozwala kompilatorowi pomóc w utrzymaniu twoich intencji. Ten pierwszy nie robi nic, aby uniemożliwić fna(Foo&)funkcji zmodyfikowanie przekazywanego parametru.

Podobnie jak w odpowiedzi @CandiedOrange, możesz użyć białych znaków, aby ułożyć kod i zwiększyć czytelność.

Usunięcie constsłowa kluczowego usuwa czytelność, ponieważ constprzekazuje informacje do czytnika i kompilatora.
Zmniejszenie długości kodu w poziomie jest dobre (nikt nie lubi przewijania w bok), ale jest coś więcej constniż tekst. Możesz to przepisać:

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

Co nie zmienia umowy, ale spełnia potrzebę zmniejszenia długości linii. Naprawdę uważałbym powyższy fragment za mniej czytelny i wybrałbym użycie większej ilości białych znaków, jak już wspomniano w odpowiedzi CandiedOrange.

constjest funkcją samego kodu. Nie spowodowałbyś, że funkcja nie byłaby członkiem w celu usunięcia MyClass::sekcji deklaracji, więc nie usuwajconst

Czy czytelność jest ważnym powodem, aby nie używać const w parametrach?

Nie. Pominięcie constmoże zmienić funkcjonalność, utracić zabezpieczenia consti może potencjalnie stworzyć mniej wydajny kod.

Czy utrzymywanie obiektów parametrów pozostaje niezmienione ręcznie?

Zamiast spędzać czas na ręcznym tworzeniu kodu

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

Użyj narzędzi do automatycznego formatowania . Napisz funkcję zgodnie z jej wymaganiami funkcjonalnymi i pozwól, aby automatyczne formatowanie obsłużyło prezentację. Ręczne dostosowywanie formatowania nie jest tak wydajne, jak użycie automatycznego formatowania i wykorzystanie zaoszczędzonego czasu do poprawy innych aspektów kodu.

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

Tak długo, jak to możliwe, lepiej zachować stałą widoczność. Znacznie poprawia to utrzymanie kodu (bez zgadywania, czy ta metoda zmienia moje argumenty).

Jeśli widzę wiele argumentów w metodzie, zmusza mnie to do rozważenia stworzenia jarona opartego na projekcie (Matrix, Pracownik, Prostokąt, Konto), który byłby znacznie krótszy, łatwiejszy do zrozumienia (eliminuje długą listę argumentów do metod).