ในการขีดเส้นใต้หรือเพื่อไม่ให้ขีดเส้นใต้นั่นคือคำถาม

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

นี้จะมีการใด ๆ ที่มีผลในภาษากรณีตายเช่น VB.NET จะมีโดยใด ๆ CLS ปฏิบัติ (หรืออื่น ๆ ) ปัญหาถ้าชื่อมีความแตกต่างโดยปลอกเท่านั้น?

มันจะไม่มีผลกระทบ

ส่วนหนึ่งของคำแนะนำสำหรับการเขียนไลบรารีที่สอดคล้องกับ CLS คือไม่มีเอนทิตีสาธารณะ / ที่ได้รับการป้องกันที่แตกต่างกันในแต่ละกรณีเช่นคุณไม่ควรมี

public void foo() {...}

และ

public void Foo() {...}

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

การอัปเดตที่สำคัญ (12 เมษายน 2559):

เราทราบดีว่ามาตรฐานภายในของทีม. NET CoreFX ยืนยันที่จะใช้เครื่องหมายขีดล่างโดยไม่ต้องให้ข้อมูลเชิงลึกเกี่ยวกับสาเหตุใด ๆ แต่ถ้าเรามองอย่างใกล้ชิดที่กฎ # 3 มันจะกลายเป็นที่เห็นได้ชัดว่ามีความเป็นระบบของ_, t_, s_คำนำหน้าที่แสดงให้เห็นว่าทำไม_ได้รับการคัดเลือกในครั้งแรก

3. เราใช้_camelCaseสำหรับเขตข้อมูลภายในและส่วนตัวและใช้แบบอ่านอย่างเดียวเท่าที่จะทำได้ เขตคำนำหน้าเช่นกับ_เขตข้อมูลคงที่พร้อมและสาขาด้ายคงที่พร้อมs_ t_เมื่อใช้กับฟิลด์คงที่readonlyควรมาหลังจากstatic(เช่นstatic readonlyไม่readonly static)
4. เราหลีกเลี่ยงthis.เว้นแต่จำเป็นจริงๆ

ดังนั้นหากคุณเป็นเหมือนทีมงาน. NET CoreFX ที่ทำงานเกี่ยวกับประสิทธิภาพที่สำคัญรหัส multithreaded ระดับระบบแสดงว่าคุณได้รับข้อเสนอแนะอย่างมากจาก:

• ปฏิบัติตามมาตรฐานการเข้ารหัสและ
• ใช้เครื่องหมายขีดล่างและ
• อย่าอ่านคำตอบนี้อีก

มิฉะนั้นโปรดอ่านต่อ ...

คำตอบเดิม:

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

ขีดสัญกรณ์

• แนะนำให้คุณใช้คำนำหน้า "_" ในชื่อของฟิลด์ส่วนตัว
• มันยังบอกด้วยว่าคุณไม่ควรใช้ "สิ่งนี้" เว้นแต่จะจำเป็นจริงๆ

นี้สัญกรณ์

• แนะนำให้คุณใช้ "สิ่งนี้" เสมอ เพื่อเข้าถึงสมาชิกอินสแตนซ์ใด ๆ

ทำไมเครื่องหมายนี้ถึงมีอยู่?

เพราะนี่คือสิ่งที่คุณเป็น

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

ตัวอย่าง

public class Demo
{
   private String name;
   public Demo(String name) {
       this.name = name;
   }
}

ทำไมไม่มีเครื่องหมายขีดล่างอยู่?

บางคนไม่ชอบพิมพ์ "นี่" แต่พวกเขายังต้องการวิธีแยกความแตกต่างของเขตข้อมูลและพารามิเตอร์ดังนั้นพวกเขาจึงตกลงที่จะใช้ "_" ที่ด้านหน้าของเขตข้อมูล

ตัวอย่าง

public class Demo
{
   private String _name;
   public Demo(String name) {
      _name = name;
   }
}

บางคนอาจคิดว่ามันเป็นแค่เรื่องของรสนิยมส่วนตัวและทั้งสองวิธีนั้นดี / ไม่ดีเท่ากัน อย่างไรก็ตามมีบางแง่มุมที่สัญกรณ์นี้เป็นเครื่องหมายขีดล่าง:

ความชัดเจน

• ขีดล่างของชื่อ clutters
• สัญกรณ์นี้ทำให้ชื่อเหมือนเดิม

โหลดทางปัญญา

• เครื่องหมายขีดล่างไม่สอดคล้องกันทำให้คุณจัดการฟิลด์ด้วยวิธีพิเศษ แต่คุณไม่สามารถใช้กับสมาชิกคนอื่น ๆ ทุกครั้งที่คุณต้องถามตัวเองว่าคุณต้องการทรัพย์สินหรือฟิลด์

• สัญกรณ์นี้สอดคล้องกันคุณไม่ต้องคิดคุณแค่ใช้ "สิ่งนี้" เพื่ออ้างอิงถึงสมาชิกใด ๆ

UPDATE: ตามที่ชี้ให้เห็นต่อไปนี้ไม่ใช่จุดได้เปรียบ

ซ่อมบำรุง

• เครื่องหมายขีดล่างคุณต้องจับตาดู_ขณะทำการเปลี่ยนโครงสร้างใหม่กล่าวว่าการเปลี่ยนเขตข้อมูลเป็นคุณสมบัติ (ลบ_) หรือตรงกันข้าม (เพิ่ม_)

• สัญกรณ์นี้ไม่มีปัญหาดังกล่าว

เติมข้อความอัตโนมัติ

เมื่อคุณต้องการดูรายการสมาชิกอินสแตนซ์:

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

ความคลุมเครือ

บางครั้งคุณต้องจัดการกับโค้ดโดยไม่ต้องใช้ Intellisense ตัวอย่างเช่นเมื่อคุณทำการตรวจสอบโค้ดหรือเรียกดูซอร์สโค้ดออนไลน์

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

• สัญลักษณ์นี้มีความชัดเจน: เมื่อคุณเห็นบางสิ่งบางอย่างบางสิ่งบางอย่างมันสามารถหมายถึงคลาสที่มีคุณสมบัติคงที่เท่านั้นและเมื่อคุณเห็นสิ่งนี้บางสิ่งบางอย่างบางสิ่งบางอย่างคุณรู้ว่าบางสิ่งเป็นสมาชิกและ SomethingElse เป็นคุณสมบัติของมัน

วิธีการขยาย

คุณไม่สามารถใช้วิธีการส่วนขยายกับอินสแตนซ์ของตัวเองโดยไม่ใช้ "สิ่งนี้"

• เครื่องหมายขีดล่างกำหนดว่าคุณไม่ต้องใช้ "สิ่งนี้" อย่างไรก็ตามด้วยวิธีการขยายที่คุณต้องทำ
• สัญกรณ์นี้ช่วยให้คุณประหยัดจากความลังเลคุณมักจะใช้ "นี่" ระยะเวลา

การสนับสนุน Visual Studio

• เครื่องหมายขีดล่างไม่มีการสนับสนุนในตัวใน Visual Studio

• Visual Studio นี้รองรับสัญกรณ์อย่างเป็นธรรมชาติ:

  1. "นี้." คุณสมบัติ : ชอบฟิลด์ที่ไม่คงที่ทั้งหมดที่ใช้ในวิธีการคงที่ที่จะนำมาใช้กับthis.ใน C #

คำแนะนำอย่างเป็นทางการ

มีแนวทางอย่างเป็นทางการมากมายที่พูดอย่างชัดเจนว่า "อย่าใช้ขีดเส้นใต้" โดยเฉพาะใน C #

• เครื่องหมายขีดล่างมาจาก C ++ ซึ่งเป็นวิธีปฏิบัติทั่วไปที่ช่วยในการหลีกเลี่ยงความขัดแย้งในการตั้งชื่อขอแนะนำให้ใช้ VisualBasic.Net ในการเอาชนะปัญหาที่เขตข้อมูล "ค่า" และคุณสมบัติ "ค่า" มีชื่อเดียวกันเพราะ VisualBasic ไม่คำนึงถึงขนาดตัวพิมพ์

  1. ประกาศชื่อองค์ประกอบใน Visual Basic
  2. สำรองช่องใน VisualBasic.NET

• แนะนำให้ใช้สัญลักษณ์นี้สำหรับ C # ในขณะที่ "_" ถูกห้ามอย่างชัดเจน:

  1. คำหลักนี้ใน C #
  2. แนวทางการใช้ฟิลด์ : อย่าใช้ส่วนนำหน้ากับชื่อฟิลด์หรือชื่อฟิลด์แบบสแตติก
  3. แนวทางสำหรับชื่อ: ชื่อประเภทสมาชิก : อย่าใช้ส่วนนำหน้าสำหรับชื่อฟิลด์
  4. แบบแผนการตั้งชื่อทั่วไป : X ห้ามใช้เครื่องหมายขีดล่างขีดกลางหรืออักขระที่ไม่ใช่ตัวอักษรและตัวเลขอื่น ๆ
  5. กฎการยืนยันคุณภาพ CA1707 : ตัวระบุไม่ควรมีขีดล่าง
  6. การใช้เครื่องหมายขีดล่างไม่สอดคล้องกับ CLS (สำหรับตัวระบุสาธารณะและตัวป้องกัน)
  7. หลักการตั้งชื่อภายในของผู้พัฒนา. NET Framework : อย่าใช้ส่วนนำหน้าสำหรับตัวแปรสมาชิก หากคุณต้องการแยกแยะความแตกต่างระหว่างตัวแปรโลคอลและสมาชิกคุณควรใช้ "this" ใน C # และ "ฉัน" ใน VB.NET

นำมาจากไฟล์ Microsoft StyleCop Help:

TypeName: FieldNamesMustNotBeginWithUnderscore

ตรวจสอบ: SA1309

สาเหตุ: ชื่อฟิลด์ใน C # เริ่มต้นด้วยเครื่องหมายขีดล่าง

คำอธิบายกฎ:

การละเมิดกฎนี้เกิดขึ้นเมื่อชื่อฟิลด์เริ่มต้นด้วยเครื่องหมายขีดล่าง

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

ถ้าเขตข้อมูลหรือชื่อตัวแปรมีจุดมุ่งหมายเพื่อให้ตรงกับชื่อของรายการที่เกี่ยวข้องกับ Win32 หรือ COM และดังนั้นจึงต้องเริ่มต้นด้วยการขีดล่างวางเขตข้อมูลหรือตัวแปรภายในคลาส NativeMethods พิเศษ คลาส NativeMethods เป็นคลาสใด ๆ ที่มีชื่อลงท้ายด้วย NativeMethods และมีจุดประสงค์เป็นตัวยึดตำแหน่งสำหรับ Win32 หรือ COM wrappers StyleCop จะเพิกเฉยต่อการละเมิดนี้หากวางไอเท็มไว้ในคลาส NativeMethods

คำอธิบายกฎที่แตกต่างกันบ่งชี้ว่าการปฏิบัติที่ต้องการนอกเหนือจากด้านบนคือการเริ่มต้นฟิลด์ส่วนตัวด้วยตัวอักษรตัวเล็กและตัวอักษรสาธารณะที่มีตัวพิมพ์ใหญ่

แก้ไข: เป็นติดตามหน้าโครงการ StyleCop ตั้งอยู่ที่นี่: https://github.com/DotNetAnalyzers/StyleCopAnalyzers การอ่านไฟล์ช่วยเหลือจะช่วยให้เข้าใจอย่างถ่องแท้ว่าทำไมพวกเขาจึงแนะนำกฎโวหารหลากหลายรูปแบบ

เนื่องจากเรากำลังพูดถึงสนามส่วนตัวมันไม่ส่งผลกระทบต่อผู้ใช้ในชั้นเรียนของคุณ

แต่ฉันขอแนะนำให้ใช้ขีดเส้นใต้สำหรับเขตข้อมูลส่วนบุคคลเนื่องจากสามารถทำให้โค้ดเข้าใจได้ง่ายขึ้นเช่น:

private int foo;
public void SetFoo(int foo)
{
  // you have to prefix the private field with "this."
  this.foo = foo;

  // imagine there's lots of code here,
  // so you can't see the method signature



  // when reading the following code, you can't be sure what foo is
  // is it a private field, or a method-argument (or a local variable)??
  if (foo == x)
  {
    ..
  }
}

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

หลังจากทำงานในสภาพแวดล้อมที่มีกฎเกณฑ์ที่เฉพาะเจาะจงมากและไร้จุดหมายตั้งแต่นั้นฉันก็เริ่มสร้างสไตล์ของตัวเองขึ้นมา นี่คือประเภทหนึ่งที่ฉันพลิกไปมามาก ในที่สุดฉันก็ตัดสินใจว่าฟิลด์ส่วนตัวจะเป็น _field เสมอตัวแปรท้องถิ่นจะไม่มี _ และเป็นตัวพิมพ์เล็กชื่อตัวแปรสำหรับการควบคุมจะตามสัญกรณ์ฮังการีอย่างหลวม ๆ และพารามิเตอร์โดยทั่วไปจะเป็น camelCase

ฉันเกลียดthis.คำหลักมันเพิ่งเพิ่มรหัสเสียงมากเกินไปในความคิดของฉัน ฉันรัก Resharper ลบนี้ซ้ำซ้อน คำสำคัญ.

อัปเดต 6 ปี: ฉันกำลังวิเคราะห์ internals ของDictionary<TKey,T>สำหรับการใช้งานที่เฉพาะเจาะจงของการเข้าถึงพร้อมกันและ misread ฟิลด์ส่วนตัวที่จะเป็นตัวแปรท้องถิ่น ฟิลด์ส่วนตัวไม่ควรจะเป็นแบบแผนการตั้งชื่อเดียวกับตัวแปรท้องถิ่น หากมีการขีดเส้นใต้มันจะชัดเจนอย่างไม่น่าเชื่อ

ฉันชอบขีดล่างเพราะจากนั้นฉันสามารถใช้ชื่อตัวพิมพ์เล็กเป็นพารามิเตอร์วิธีดังนี้:

public class Person
{
    string _firstName;

    public MyClass(string firstName)
    {
        _firstName = firstName;
    }

    public string FirstName
    {
        get { return _firstName; }
    }
}

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

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

การแนะนำ Style Cop หรือไม่การขุดเข้าไปใน. NET Framework จะแสดงการใช้งาน "_" จำนวนมากสำหรับตัวแปรสมาชิก ไม่ว่าผู้สร้าง Style Cop จะแนะนำอะไรมันก็ไม่ใช่สิ่งที่พนักงาน MS ส่วนใหญ่ใช้ :) ดังนั้นฉันจะยึดติดกับขีดเส้นใต้ เนื่องจากฉันทำผิดพลาดน้อยกว่ามากโดยใช้เครื่องหมายขีดล่างแล้วสิ่งนี้ (ตัวอย่าง: using varName = varName แทน this.varName = varName มันติดอยู่ในตัวฉันจริงๆ)

ฉันคิดว่าโดยและสาขาวิชาขนาดใหญ่เป็นข้อผิดพลาดในการออกแบบภาษา ฉันจะชอบมันถ้าคุณสมบัติของ C # มีขอบเขตในตัวของมันเอง:

public int Foo
{
   private int foo;
   get
   {
      return foo;
   }
   set
   {
      foo = value;
   }
}

นั่นจะทำให้เป็นไปได้ที่จะหยุดใช้ฟิลด์ทั้งหมด

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

เครื่องหมาย _fieldName สำหรับเขตข้อมูลส่วนตัวแตกหักง่าย ใช้ "นี่" สัญกรณ์เป็นไปไม่ได้ที่จะทำลาย คุณจะแยกเครื่องหมาย _ อย่างไร? สังเกต:

private void MyMethod()
{
  int _myInt = 1; 
  return; 
}

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

ตัดกันด้วย Ruby ที่ชื่อของตัวแปร @my_numberผูกชื่อไว้ในขอบเขตและไม่สามารถแตกได้

แก้ไข: คำตอบนี้เป็นลบ ฉันไม่สนใจมันอยู่

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

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

(แต่ฉันยังนำหน้าสมาชิกส่วนตัวของฉันด้วยการขีดเส้นใต้เสมอมันยังช่วยให้ฉันชัดเจนเมื่อฉันอ่านรหัสของฉันว่าตัวแปรบางตัวเป็นเขตข้อมูลสมาชิก)

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

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