เป็นการปฏิบัติที่ไม่ถูกต้องหรือไม่ที่จะใช้พารามิเตอร์วิธีการซ้ำ

มีบางครั้งที่ฉันจะต้องแก้ไขค่าที่ส่งผ่านไปยังเมธอดจากภายในเมธอดเอง ตัวอย่างจะทำให้บริสุทธิ์สตริงเช่นวิธีนี้ที่นี่:

void SanitizeName(string Name)
{
    Name = Name.ToUpper();

    //now do something here with name
}

สิ่งนี้ไม่เป็นอันตรายอย่างNameแท้จริงเนื่องจากอาร์กิวเมนต์ไม่ได้ถูกส่งผ่านโดยการอ้างอิง อย่างไรก็ตามถ้าด้วยเหตุผลบางอย่างผู้พัฒนาในอนาคตตัดสินใจที่จะให้ค่าทั้งหมดผ่านโดยอ้างอิงการฆ่าล้างของสตริงจะส่งผลกระทบต่อค่านอกวิธีการที่อาจมีผลเป็นอันตราย

ดังนั้นแทนที่จะกำหนดใหม่ให้กับข้อโต้แย้งตัวเองฉันมักจะสร้างสำเนาท้องถิ่นเช่น:

void SanitizeName(string Name)
{
    var SanitizedName = Name.ToUpper();

    //now do something here with name
}

สิ่งนี้ทำให้มั่นใจได้ว่าการเปลี่ยนแปลงค่าที่ส่งผ่านจะไม่ส่งผลกระทบต่อการดำเนินการด้านนอกวิธีการ แต่ฉันสงสัยว่าฉันกำลังหวาดระแวงเกี่ยวกับเรื่องนี้มากเกินไป

ฉันคิดว่ามันขึ้นอยู่กับอนุสัญญาการเข้ารหัสของคุณในโครงการของคุณ

ฉันให้ eclipse เป็นการส่วนตัวเพิ่มfinalคำสำคัญให้กับทุกตัวแปรและพารามิเตอร์โดยอัตโนมัติ วิธีนี้คุณจะเห็นได้อย่างรวดเร็วก่อนหากพารามิเตอร์ถูกนำมาใช้ซ้ำ

ในโครงการที่งานของฉันเราไม่แนะนำให้นำพารามิเตอร์มาใช้ซ้ำ แต่ถ้าคุณต้องการโทรเช่น.trim()หรือตั้งค่าเริ่มต้นในnullกรณีเราจะใช้พารามิเตอร์ส่วนใหญ่เนื่องจากการแนะนำตัวแปรใหม่ในกรณีเช่นนี้อ่านได้น้อยลง กว่าการใช้ซ้ำของพารามิเตอร์

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

ดังนั้นได้ร่วมกับทีมของคุณและกำหนดอนุสัญญาการเข้ารหัสที่ครอบคลุมเรื่องนี้

หากคุณใช้เครื่องวิเคราะห์รหัสแบบคงที่เพื่อความปลอดภัยอาจทำให้เกิดความสับสนและคิดว่าคุณยังไม่ได้ตรวจสอบหรือทำให้ตัวแปรพารามิเตอร์อินพุตถูกทำให้สะอาดก่อนใช้งาน ถ้าคุณใช้Nameในแบบสอบถาม SQL ตัวอย่างเช่นมันอาจอ้างสิทธิ์ในช่องโหว่การฉีด SQL ซึ่งจะทำให้คุณเสียเวลาในการอธิบาย นั่นเป็นสิ่งที่ไม่ดี ในทางกลับกันการใช้ตัวแปรที่ตั้งชื่อไว้อย่างชัดเจนสำหรับอินพุตที่ถูกทำให้สะอาดโดยที่ไม่ต้องฆ่าเชื้ออินพุตนั้นเป็นวิธีที่รวดเร็วในการวิเคราะห์โค้ดไร้เดียงสาที่เงียบสงบ

คำตอบนี้ขึ้นอยู่กับ 100% ว่าใครจะอ่านรหัสของคุณ รูปแบบใดที่พวกเขาพบว่ามีประโยชน์มากที่สุด

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

แบบจำลองจิตเปลี่ยนไป ในสภาพแวดล้อมการพัฒนาเฉพาะของคุณอาจเป็นที่ต้องการที่จะnameเป็น "การแสดงชื่อที่ดีที่สุด ณ เวลานี้" อาจเป็นที่พึงปรารถนาที่จะเชื่อมโยงตัวแปรที่คุณกำลังทำกับข้อโต้แย้งของพวกเขาอย่างชัดเจนยิ่งขึ้นแม้ว่าคุณจะทำการปรับเปลี่ยนค่าของพวกเขาไปพร้อมกัน อาจมีข้อได้เปรียบรันไทม์มากมายในการใช้ตัวแปรบางตัวซ้ำ ๆ แทนที่จะสร้างวัตถุขนาดใหญ่ขึ้น ท้ายที่สุดเมื่อคุณทำงานกับสาย 4GB มันเป็นการดีที่จะลดจำนวนสำเนาพิเศษที่คุณต้องทำ!

ฉันมีปัญหาที่แตกต่างอย่างสิ้นเชิงกับตัวอย่างรหัสของคุณ:

SanitizeNameชื่อวิธีของคุณคือ ในกรณีนี้ผมคาดว่ามันจะsanitize ชื่อ ; เพราะนั่นคือสิ่งที่คุณบอกให้ผู้อ่านฟังก์ชั่นของคุณ

เพียงสิ่งที่คุณทำงานควรทำคือการฆ่าเชื้อที่กำหนดชื่อ โดยไม่ต้องอ่านรหัสของคุณฉันคาดหวังสิ่งต่อไปนี้:

string SanitizeName(string Name)
{
    //somehow sanitize the name
    return Result;
}

แต่คุณบอกเป็นนัยว่าวิธีการของคุณทำมากกว่าแค่ sanitizng นั่นเป็นกลิ่นรหัสและควรหลีกเลี่ยง

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

คำตอบนั้นชัดเจน: ใช่!

สิ่งนี้ไม่เป็นอันตรายอย่างแท้จริงเนื่องจากอาร์กิวเมนต์ Name ไม่ได้ถูกส่งผ่านโดยการอ้างอิง อย่างไรก็ตามถ้าด้วยเหตุผลบางอย่างผู้พัฒนาในอนาคตตัดสินใจที่จะมีค่าทั้งหมดที่ผ่านเข้ามาโดยอ้างอิงการฆ่าล้างของสตริงจะส่งผลกระทบต่อค่านอกวิธีการที่อาจมีผลเป็นอันตราย

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

ปัญหาคือน้อยนำมาใช้ใหม่กว่าsideeffects เพื่อป้องกันไม่ให้sideeffectsไม่ได้นำมาใช้ตัวแปร หากคุณไม่มีผลข้างเคียงจะไม่มีปัญหา