Is readability a valid reason to not use const in (reference) parameters?

Question

When writing some functions, I found a const keyword in parameters like this:

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

often causes splitting a line into 2 lines in IDE or vim, so I want to remove all const keywords in parameters:

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

is that a valid reason to not using const? Is it maintainable to keep the parameter objects unchanged manually?

• Pieter B: "Hey, I want to functionally change my program" to make it more readable is a bad bad reason.
• tofro: The program is not becoming any more readable anyhow - Once you see something being handed over as const you have a strong hint that you don't need to bother how it might be changed in the function.
• 5gon12eder: A better way to improve readability is to reduce the number of arguments.
• Charles: 'const' arguably improves the readability. This statement makes clear that obj may not change!
• sam hocevar: What would help readability is adding a space after each comma.

Answer 1

Readability is a valid reason to learn to use whitespace:

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

Located over there the parameters won't get confused with the body of the function. By locating them on a different line you won't have to reposition them when you change the name of myFunction to something more descriptive. Not changing the parameters position when they haven't changed is something source control diff tool users will appreciate.

const means something. Don't throw it out just because you're out of space and ideas. Readability is king but breaking things in it's name is just giving up.

• Steve Jessop: "you won't have to reposition them when you change the name of myFunction" -- although in this case it looks as if they have been positioned to approximately line up with the opening (, and if that's the case then you might have to reposition them if the length of the class+function name changes by more than about 4 characters. So if you want not to have to do that, add a fixed number of levels of indentation, not a number that depends on the length of the function name. I would recommend 1 level, this answer uses 6, but any fixed number achieves the stated goal :-)
• svidgen: @CandiedOrange I'm surprised you didn't use "form 6" in this answer ... it's clearly less ugly!
• Lightness Races in Orbit: Form 6 for the win. One tabspace for one level of indentation. Simple and effective. Problem solved :)
• candied_orange: Ok ok form 6 it is. This is the variant that JeffGrigg mentioned on c2.
• candied_orange: @random832 I think we're firmly in bike shed territory now. Here's the proper way to resolve that: search your code base for examples, consult your shops style guide, ask the developers in your shop, and if none of that yields an authoritative answer use this. Resolve disputes that could go either way with a quarter. Once the quarter has spoken be consistent!

Answer 2

Actually, the readability issue definitely goes the other direction. First, you can trivially solve your run-on line by the use of whitespace. But removing const doesn't just make the line shorter, it completely changes the meaning of the program.

Herb Sutter refers to the const in reference to const as the most important const because a reference to const can bind to a temporary and extend its lifetime. An lvalue reference to non-const cannot, you need a separate variable.

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

What this means for usability is that you'll have to introduce all these temporary variables just to be able to call your function. That's not great for readability, since these variables are meaningless and exist only because your signature is wrong.

• Mindwin Remember Monica: Your second paragraph gives me headaches trying to figure out if const is refering to const or to the other const and what const is indeed the most important const
• Barry: @Mindwin I think the irony is that my second paragraph is clear and unambiguous, and I have no idea what you're talking about.
• Cort Ammon: @Barry It is certainly unambiguous, but it took me a few reads of that paragraph to try to figure out what it meant. I think some of the trouble is that it can be parsed "Herb Sutter refers to the const (in reference to const) as the most important const..." or "Herb Sutter refers to const in (reference to const) as the most important const..." I believe the latter is the only valid grouping of the words, but it takes a bit to process it. Maybe there's a way to use quotation marks to remove the ambiguity?
• shawnt00: I think some hyphenated compounds would clear this up.
• Caleth: or specifically use const& rather than reference to const as a noun(-phrase) there

Answer 3

Simple answer is "no".

The long answer is that the const keyword is part of the contract the function offers; it tells you that the argument will not be modified. The moment you remove the const that guarantee goes out of the window. Remember that you can't reasonably maintain the constness (or any other property) of something using documentation, conventions, or guidelines - if the constness is not enforced by the compiler, someone will think that they can make their work easier if they fiddle with the parameter "just a little bit". Consider:

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

Apart from the fact that the latter version is more concise, it also provides stronger contract, and lets the compiler help you maintain your intentions. The former does nothing to prevent the fna(Foo&) function from modifying the parameter you pass to it.

As in @CandiedOrange answer, you can use whitespace to lay out the code and enhance readability.

Answer 4

Removing the const keyword removes readability because const communicates information to the reader and the compiler.
Reducing the horizontal length of code is good (nobody likes scrolling sideways) but there's more to const than text. You could rewrite it:

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

Which doesn't change the contract but fulfils the need to reduce line length. Truly I would consider the above snippet to be less readable and would opt for using more whitespace as already mentioned in CandiedOrange's answer.

const is a functionality of the code itself. You wouldn't make the function a non-member to remove the MyClass:: section of the declaration, so don't remove the const

• Jason C: I agree that the snippet you provide is less readable. It forces a reader to go find out what MObj and str are, and certainly raises eyebrows. It's especially weird for types whose names you already have control over: E.g. Why didn't you just name MyObject as MObj to begin with?

Answer 5

Is readability a valid reason to not use const in parameters?

No. Omitting const can change functionality, lose protections const provides and can potentially create less efficient code.

Is it maintainable to keep the parameter objects unchanged manually?

Rather than spend time manually formating code

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

Use auto formatting tools. Write the function per its functional requirements and let auto-formatting handle the presentation. Manually adjusting formatting is not as efficient as using auto formatting and using the saved time to improve other aspects of code.

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

Answer 6

As long as possible it is better to keep const visible. It improves code maintenance a lot (no guesswork to see if this method changes my arguments).

If I see lot of arguments in a method, it forces me to consider creation of project based jaron (Matrix, Employee, Rectangle, Account) that would be much shorter, easier to understand (eliminates long list of arguments to methods).

• blackpen: Agreed. I was hesitant to point it out. Thus, "extreme case".
• Jason C: @cmaster That said, sometimes in certain contexts, with certain programmers, it could stay readable. For example, in the very specific case of a program waist-deep in Windows API calls, with a reader who is used to that environment, stuff like e.g. typedef Point * LPPOINT and typedef const Point * LPCPOINT, while super obnoxious, still carries an implicit meaning, because it's consistent with immediate expectations in context. But never in the general case; it's just a weird exception I can think of.
• blackpen: Yes, when I saw the question, "const unsigned long long int" came to my mind, but, it is not a good candidate to derive benefit from being either "const" or "reference". The typedef solves the general problem of shortening names; but it doesn't feel like good design to hide the very purpose of language constructs (like "const") behind it.