ความสามารถในการอ่านเป็นเหตุผลที่ถูกต้องหรือไม่ที่จะไม่ใช้พารามิเตอร์ const in (การอ้างอิง)

เมื่อเขียนฟังก์ชั่นบางอย่างฉันพบคำสำคัญ const ในพารามิเตอร์ดังนี้:

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

มักทำให้เกิดการแบ่งบรรทัดออกเป็น 2 บรรทัดใน IDE หรือ vim ดังนั้นฉันต้องการลบคำหลัก const ทั้งหมดในพารามิเตอร์:

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

นั่นเป็นเหตุผลที่ถูกต้องหรือไม่ที่จะไม่ใช้ const? มันสามารถบำรุงรักษาเพื่อให้วัตถุพารามิเตอร์ไม่เปลี่ยนแปลงด้วยตนเอง?

ความสามารถในการอ่านเป็นเหตุผลที่ถูกต้องในการเรียนรู้ที่จะใช้ช่องว่าง:

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

ตั้งอยู่ที่นั่นพารามิเตอร์จะไม่สับสนกับเนื้อหาของฟังก์ชัน คุณจะไม่ต้องเปลี่ยนตำแหน่งเมื่อคุณเปลี่ยนชื่อของmyFunctionเป็นคำอธิบายเพิ่มเติม การไม่เปลี่ยนตำแหน่งพารามิเตอร์เมื่อพวกเขาไม่ได้เปลี่ยนเป็นสิ่งที่ผู้ใช้เครื่องมือต่างควบคุมจะประทับใจ

constหมายถึงบางสิ่ง อย่าโยนทิ้งเพราะคุณไม่มีที่ว่างและความคิด การอ่านเป็นเรื่องสำคัญ แต่สิ่งที่แตกต่างในชื่อนี้คือการยอมแพ้

ที่จริงแล้วปัญหาการอ่านได้ไปในทิศทางอื่นอย่างแน่นอน ก่อนอื่นคุณสามารถแก้ปัญหาเรื่อง run-on ของคุณได้เล็กน้อยโดยใช้ช่องว่าง แต่การลบconstไม่เพียงทำให้บรรทัดสั้นลง แต่เป็นการเปลี่ยนความหมายของโปรแกรมอย่างสมบูรณ์

Herb Sutter หมายถึงการconstอ้างอิงถึงconstเป็นสิ่งที่สำคัญที่สุดconstเพราะการอ้างอิงถึงconstสามารถผูกกับชั่วคราวและยืดอายุของมัน การอ้างอิง lvalue กับที่ไม่ใช่constคุณต้องการตัวแปรแยกต่างหาก

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

สิ่งนี้มีความหมายต่อการใช้งานคือคุณจะต้องแนะนำตัวแปรชั่วคราวเหล่านี้ทั้งหมดเพื่อให้สามารถเรียกใช้ฟังก์ชันของคุณได้ ไม่ดีสำหรับการอ่านเนื่องจากตัวแปรเหล่านี้ไม่มีความหมายและมีอยู่เพียงเพราะลายเซ็นของคุณผิด

คำตอบง่ายๆคือ "ไม่"

คำตอบยาว ๆ คือconstคำหลักนั้นเป็นส่วนหนึ่งของสัญญาที่ฟังก์ชั่นให้บริการ มันบอกคุณว่าข้อโต้แย้งจะไม่ถูกแก้ไข ช่วงเวลาที่คุณลบการconstรับประกันนั้นออกไปนอกหน้าต่าง โปรดจำไว้ว่าคุณไม่สามารถรักษาความมั่นคง (หรือคุณสมบัติอื่นใด) ของสิ่งที่ใช้เอกสารการประชุมหรือแนวทาง - ถ้าความไม่ถูกบังคับใช้โดยคอมไพเลอร์บางคนจะคิดว่าพวกเขาสามารถทำให้งานของพวกเขาง่ายขึ้น พารามิเตอร์ "เพียงเล็กน้อย" พิจารณา:

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

void fnb(const Foo& foo);

นอกเหนือจากความจริงที่ว่ารุ่นหลังมีความกระชับมากกว่านี้มันยังให้สัญญาที่แข็งแกร่งกว่าและให้คอมไพเลอร์ช่วยคุณรักษาความตั้งใจของคุณ อดีตไม่มีอะไรที่จะป้องกันไม่ให้fna(Foo&)ฟังก์ชั่นจากการปรับเปลี่ยนพารามิเตอร์ที่คุณผ่านมัน

เช่นเดียวกับใน @CandiedOrange คำตอบคุณสามารถใช้ช่องว่างเพื่อวางโค้ดและเพิ่มความสามารถในการอ่าน

การลบconstคำหลักจะลบความสามารถในการอ่านได้เนื่องจากconstสื่อสารข้อมูลกับผู้อ่านและคอมไพเลอร์
การลดความยาวแนวนอนของโค้ดเป็นสิ่งที่ดี (ไม่มีใครชอบเลื่อนไปด้านข้าง) แต่มีconstมากกว่าข้อความ คุณสามารถเขียนซ้ำได้:

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

ซึ่งไม่เปลี่ยนสัญญา แต่ตอบสนองความต้องการลดความยาวของบรรทัด แท้จริงฉันจะพิจารณาตัวอย่างข้างต้นให้อ่านได้น้อยลงและเลือกใช้ช่องว่างเพิ่มเติมตามที่ระบุไว้ในคำตอบของ CandiedOrange

constเป็นฟังก์ชั่นของรหัสตัวเอง คุณจะไม่ทำให้ฟังก์ชั่นไม่ใช่สมาชิกเพื่อลบMyClass::ส่วนของการประกาศดังนั้นอย่าลบconst

ความสามารถในการอ่านเป็นเหตุผลที่ถูกต้องหรือไม่ที่จะไม่ใช้ const ในพารามิเตอร์?

ไม่การละเว้นconstสามารถเปลี่ยนแปลงฟังก์ชันการทำงานสูญเสียการป้องกันconstและอาจสร้างรหัสที่มีประสิทธิภาพน้อยลง

มันสามารถบำรุงรักษาเพื่อให้วัตถุพารามิเตอร์ไม่เปลี่ยนแปลงด้วยตนเอง?

แทนที่จะใช้เวลาในการจัดทำโค้ดด้วยตนเอง

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

ใช้เครื่องมือการจัดรูปแบบอัตโนมัติ เขียนฟังก์ชั่นตามข้อกำหนดการใช้งานและให้การจัดรูปแบบอัตโนมัติจัดการกับงานนำเสนอ การปรับการจัดรูปแบบด้วยตนเองไม่ได้มีประสิทธิภาพเท่ากับการใช้การจัดรูปแบบอัตโนมัติและการใช้เวลาที่บันทึกไว้เพื่อปรับปรุงด้านอื่น ๆ ของรหัส

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

ตราบเท่าที่เป็นไปได้มันจะดีกว่าเพื่อให้ const มองเห็นได้ มันปรับปรุงการบำรุงรักษารหัสจำนวนมาก (ไม่ต้องเดาเพื่อดูว่าวิธีนี้เปลี่ยนข้อโต้แย้งของฉัน)

หากฉันเห็นข้อโต้แย้งจำนวนมากในวิธีใดวิธีหนึ่งมันบังคับให้ฉันพิจารณาการสร้าง jaron แบบโครงการ (Matrix, Employee, Rectangle, Account) ที่จะสั้นกว่ามากเข้าใจง่ายกว่า