C # - เหตุใดคำนำหน้าบนฟิลด์จึงหมดกำลังใจ?

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

สำหรับฉันถ้าฉันอ่านรหัสของคนอื่นและฉันเห็นสิ่งนี้:

count = 3;

ฉันคิดว่าcountมันเป็นตัวแปรท้องถิ่นของฟังก์ชั่นนั้นและฉันกำลังทำสิ่งที่จะใช้ที่อื่นในฟังก์ชั่น; ถ้าฉันเห็นสิ่งนี้:

m_count = 3;

ฉันรู้ทันทีว่าฉันกำลังอัพเดทสถานะของวัตถุ

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

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

ฉันยินดีที่จะเปลี่ยนเป็นสไตล์ Microsoft แต่ฉันอยากรู้ว่าทำไมสิ่งต่าง ๆ ถึงเป็นแบบนี้

ทำไมตอนนี้จึงถือว่าไม่ดีที่จะบอกได้ว่าตัวแปรเป็นฟังก์ชันโลคัลหรือสมาชิก?

ป.ล. นี้คล้ายกับแนวทางปฏิบัติที่ดีที่สุดในปัจจุบันที่ได้รับการยอมรับเกี่ยวกับคำสำคัญ“ นี้” ที่อยู่ด้านหน้าของฟิลด์และวิธีการใน c # คืออะไร แต่ฉันถามเกี่ยวกับการm_ไม่ได้this.

PPS ดูเพิ่มเติมที่เหตุใด Microsoft จึงสร้างพารามิเตอร์ตัวแปรโลคัลและฟิลด์ส่วนตัวจึงมีหลักการตั้งชื่อเหมือนกัน

เมื่อพวกเขาทำงานกับ API สำหรับ Windows Microsoft แนะนำให้ใช้สัญลักษณ์ฮังการีโดยใช้ 'm_' เช่นเดียวกับ 'i', 'sz' ฯลฯ ในขณะนี้สิ่งนี้มีประโยชน์เพราะ IDE ไม่แข็งแกร่ง เพียงพอที่จะแสดงข้อมูลนี้ให้คุณ

ในทางกลับกัน C # มี IDE ที่แข็งแกร่งมากตั้งแต่เริ่มแรก

ดังนั้นพวกเขาจึงให้คำแนะนำในแนวทางการตั้งชื่อของ Microsoft สำหรับ C #สำหรับฟิลด์คงที่หรือที่ป้องกันสาธารณะ:

✓ DO use PascalCasing in field names.
✓ DO name fields using a noun, noun phrase, or adjective.
X DO NOT use a prefix for field names.

ตอนนี้คุณสามารถวางเมาส์ไว้เหนือเมาส์หรือกด CTRL + K + W และรับข้อมูลทั้งหมดเกี่ยวกับสมาชิกแล้ว Microsoft ก็มาถึงการพิจารณาว่าคำนำหน้าเป็นรูปแบบที่ไม่ดี พวกเขาเป็นวิธีแก้ปัญหาด้วยตนเองเพื่อแก้ไขปัญหาแล้ว

เขตข้อมูลส่วนตัวถูกแยกออกจากแนวทางโดยเฉพาะ แต่ Microsoft ดูเหมือนจะสรุปได้ว่าเป็นกรณีนี้แม้สำหรับเขตข้อมูลส่วนตัวที่กำลังดำเนินการอยู่ภายในซึ่งคุณสามารถดูได้ว่าคุณชี้ Resharper ที่. NET 4.5 หรือ. NET Core

ใช้เครื่องมือของคุณอย่าทำด้วยตนเอง

C # ไม่มีตัวแปรทั่วโลกดังนั้นจึงเหลือเฉพาะตัวแปรในตัวเครื่องและคลาสฟิลด์

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

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

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

เหตุใดนักพัฒนาจึงหลีกเลี่ยงการเพิ่มเนมสเปซด้วยการใช้คำสั่งเนมสเปซ

System.DateTime()DateTime()มากขึ้นอย่างชัดเจนกว่า มันบอกฉันว่าฉันกำลังทำอะไรอยู่ มันเป็นเพราะพวกเราขี้เกียจ

ไม่เราเป็นคนขี้เกียจ แต่นั่นไม่ใช่เหตุผล

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

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

ลองขยายอีกหน่อย

มี 3 รูปแบบคำนำหน้าทั่วไปซึ่งทั้งหมดจะพบเป็นครั้งคราวในรหัส c #:

• m_
• _
• นี้.

คำนำหน้าดังกล่าวจะถูกนำมาใช้ในการดำเนินงานของภาคเอกชนชั้นเรียน คำแนะนำของ Microsoft นั้นเกี่ยวกับส่วนที่เปิดเผยของคลาสเป็นหลัก

ข้อได้เปรียบของการใช้m_เกิน_คือคำนำหน้าอาจเหมือนกันใน codebase ทั้งหมดของคุณหากคุณใช้ c # รวมถึงภาษาที่_ไม่อนุญาตให้ใช้คำนำหน้า * ข้อดีของm_over this.คือสั้นกว่าและคุณจะไม่ได้ตั้งใจ ลืมคำนำหน้า

ข้อได้เปรียบของ_over m_ก็คือว่ามันสั้นกว่าและสิ่งที่เริ่มต้นด้วยคำนำหน้าจะถูกจัดเรียงที่ด้านบนจะถูกจัดเรียงตามตัวอักษรโดยเครื่องมือ ข้อได้เปรียบของ_กว่าthis.ก็คือว่ามันสั้นและที่คุณจะไม่ได้ตั้งใจลืมเกี่ยวกับคำนำหน้า

ข้อได้เปรียบของthis.over m_and _คือคุณสามารถใช้มันใน codebase โดยที่_หรือm_ไม่ใช่แบบแผนที่ยอมรับและเป็นสากล นั่นก็หมายความว่าไม่มีใครจำเป็นต้องรู้เกี่ยวกับ_หรือm_การประชุมซึ่งสามารถเห็นได้ว่าทำให้สิ่งต่าง ๆ ง่ายขึ้น ในฐานะที่เป็นข้อเสียเนื่องจากคอมไพเลอร์ไม่สนใจเกี่ยวกับคำนำหน้านี้คำนำthis.หน้าบางครั้งจะหายไปและจึงไม่น่าเชื่อถือเท่ากับตัวบ่งชี้

* เมื่อคุณเริ่มเข้าถึงคลาส C # ที่ใช้_จาก C ++ / CLI (ซึ่งไม่ควรใช้จริงๆ_) คุณจะสังเกตเห็นว่าการยอมรับคำนำหน้าทั่วไปนั้นซับซ้อนกว่าที่ควรจะเป็น การตัดสินใจว่าไม่มีคำนำหน้าจะกำจัดเสียงดังกล่าว รวมสิ่งนี้เข้ากับคำตอบของ Deduplicator ซึ่งฉันจะถอดความเพราะ "ข้อดีของคำนำหน้าเกือบจะเล็กน้อย" และทำให้เรา: "มีปัญหาเล็ก ๆ เมื่อใช้คำนำหน้าและกลับหัวกลับหางเล็ก ๆ ดังนั้นจึงเป็นตัวเลือกที่ถูกต้อง ใช้มัน".

มีคำถามเก่า ๆ เกี่ยวกับ stackoverflowที่เกี่ยวข้องกับสิ่งนี้

ควรสังเกตว่า MS style guide พูดถึงสาธารณะและวิธีการป้องกันและตัวแปรเท่านั้น เช่น devs อื่น ๆ จะดูว่าพวกเขาใช้ห้องสมุดของคุณ

ความคิดที่ว่าห้องสมุด Microsoft ได้รับรูปลักษณ์และความรู้สึกมาตรฐานสำหรับนักพัฒนาที่บริโภคมัน

คุณมีอิสระที่จะใช้สไตล์ที่คุณชอบกับตัวแปรส่วนตัวหรือในท้องถิ่นของคุณ

ต้องบอกว่าคำนำหน้าตัวแปรเป็นกำลังใจโดยทั่วไปด้วยเหตุผลหลายประการ

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

สำหรับฉันถ้าฉันอ่านรหัสของคนอื่นและฉันเห็นสิ่งนี้:

count = 3;

ฉันคิดว่า 'count' เป็นตัวแปรภายในของฟังก์ชันนั้นและฉันกำลังทำบางสิ่งที่จะใช้ที่อื่นในฟังก์ชัน

และคุณจะถูกต้องอย่างแน่นอนหากคุณกำลังอ่านซอร์สโค้ดซึ่งเป็นไปตามข้อกำหนดของสไตล์ C # ในรหัสดังกล่าว:

this.count = 3;

กำหนดค่าให้กับเขตข้อมูล

count = 3;

กำหนดค่าให้กับตัวแปรโลคัล

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

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

public class Hello
{
    private string greetings;

    public Hello(string greetings)
    {
        greetings = greetings; // Wait, what is that?!
    }
}

C # ไม่มีคำหลักนี้ใช่ไหม คุณไม่สามารถอ้างถึงสมาชิกที่ใช้สิ่งนี้เช่น this.count?

ใช่ แต่ (1) มันพิมพ์ได้มากกว่าและ (2) ง่ายต่อการลืม หากฟิลด์ชื่อ m_count ฉันไม่ต้องจำให้พิมพ์ this.m_count

อย่างไรก็ตามที่นี่คุณผิด

มันพิมพ์ได้มากขึ้นเมื่อคุณเขียนโค้ดใน Notepad ด้วย IDE ที่มีการทำให้สมบูรณ์อัตโนมัติหรือดีกว่า IntelliSense การเปรียบเทียบระหว่างthis.countและm_countไม่ชัดเจน โปรดสังเกตเครื่องหมายShift+ ที่-จำเป็นในการพิมพ์ขีดล่าง

สำหรับ "ง่ายต่อการลืม" อีกครั้งสิ่งนี้เกี่ยวข้องกับผู้ใช้ Notepad เท่านั้น ไม่เพียง แต่ StyleCop และ Resharper จะไม่ให้คุณลืมการใส่this.เมื่อจำเป็น แต่หลังจากการเขียนโปรแกรมสองสามชั่วโมงการวางthis.เมื่อจำเป็นก็กลายเป็นนิสัย

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

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

ประเด็นของฉันคือการขยายคำตอบของ @CandiedOrange และ @Ewan

คำนำหน้าทำให้การปรับโครงสร้างทำได้ยากขึ้น

ในขณะที่รหัสของคุณวิวัฒนาการตัวแปรและวิธีการอาจเปลี่ยนขอบเขตของพวกเขา เช่น. คุณอาจสร้างวิธีการแบบส่วนตัวและต่อมาก็พบว่าควรมีคลาสอื่น (ใหม่) ด้วย ที่คล้ายกันอาจเกิดขึ้นกับพารามิเตอร์วิธีการและตัวแปรท้องถิ่น

สมมติว่าคุณสร้างเครื่องคิดเลขภาษี ตามหลักการของขอบเขตการมองเห็นการเช่าสำหรับตัวแปรที่คุณเริ่มต้นด้วยวิธีที่ใช้ทั้งอัตราภาษีและค่าฐานเป็นพารามิเตอร์:
^{(ตัวอย่างอาจดู Java-ish ... )}

class TaxCalculator{
   double Calculate(double p_TaxRateInpercent, double p_BaseValue){
     return (100+p_TaxRateInpercent)/100 * p_BaseValue;
   }
} 

ถัดไปคุณต้องใช้การดำเนินการย้อนกลับและตาม TDD คุณทำมันด้วยความพยายามน้อยที่สุด:

class TaxCalculator{
   double Calculate(double p_TaxRateInpercent, double p_BaseValue){
     return (100+p_TaxRateInpercent)/100 * p_BaseValue;
   }
   double CalculateBase(double p_TaxRateInpercent, double p_TaxedValue){
     return p_TaxedValue/((100+p_TaxRateInpercent)/100);
   }
} 

ถัดไป TDD ต้องการให้คุณ refactor รหัสให้สะอาดขึ้นซึ่งเป็นการลดรายการพารามิเตอร์ของทั้งสองวิธี
^{(ใช่คุณต้องแยกการคำนวณเป็นสองเท่าก่อน แต่ให้ฉันได้แต้ม ... )}
ทางออกที่ชัดเจนคือการเปลี่ยนอัตราภาษีเป็นตัวแปรสมาชิกโดยผ่านมันเป็นพารามิเตอร์คอนสตรัคเตอร์

class TaxCalculator{
   double m_TaxRateInpercent;
   TaxCalculator(double p_TaxRateInpercent){
     m_TaxRateInpercent = p_TaxRateInpercent;
   }
   double Calculate(double p_BaseValue){
     return (100+m_TaxRateInpercent)/100 * p_BaseValue;
   }
   double CalculateBase(double p_TaxedValue){
     return p_TaxedValue/((100+m_TaxRateInpercent)/100);
   }
} 

ดังที่คุณเห็นเราต้องเปลี่ยนทุกบรรทัดของวิธีการที่มีอยู่ของเรา (ทุกบรรทัดที่เราเคยใช้p_TaxRateInpercentแน่นอน

ปัญหาคือว่าคุณไม่ได้รับการสนับสนุนจาก IDE ของคุณเพื่อทำการเปลี่ยนชื่อตลอดทั้งชั้นเรียน เพียงความช่วยเหลือมันค้นหา / แทนที่p_TaxRateInpercentซึ่งจะเปลี่ยนคอนสตรัคหรือส่วนใดส่วนหนึ่งที่บังเอิญมีสตริง
^{คุณ IDE อาจเสนอการเปลี่ยนแปลง ... refactoring สำหรับชื่อตัวแปรที่ไม่ได้กำหนด แต่สิ่งนี้อาจถูก จำกัด ขอบเขตของวิธีการ}

หากไม่มีส่วนนำหน้าเฉพาะลายเซ็นเมธอดจะเปลี่ยนไป ไม่จำเป็นต้องเปลี่ยนชื่อเลย

คำนำหน้าถ่วงประวัติ SCM เมื่อมีการเปลี่ยนแปลง

SCMยังบันทึกการเปลี่ยนแปลงคำนำหน้าว่าเป็นการเปลี่ยนแปลงในตรรกะแม้ว่าตรรกะจะไม่เปลี่ยนแปลง! ประวัติของ SCM นั้นเต็มไปด้วยการเปลี่ยนแปลงทางเทคนิคนี้ซ่อนสิ่งที่สำคัญและเพิ่มความเสี่ยงสำหรับความขัดแย้งกับการเปลี่ยนแปลง (ตรรกะจริง) ของผู้อื่น

ฉันใช้คำนำหน้า _ สำหรับตัวแปรสมาชิกทั้งหมด ฉันเกลียดคำนำหน้า 'นี่' เพราะในขณะที่บางคนอ้างว่ามันเป็นวิธีที่ถูกต้องในการทำสิ่งต่าง ๆ - มันเพิ่มเสียงรบกวน / ความยุ่งเหยิงใน codebase ของคุณมาก ขีดเส้นใต้เดียวยังเป็นเรื่องธรรมดาในตัวอย่างของ Microsoft

ดังนั้นในตัวอย่างของคุณฉันมี:

int _count = 10;