ฉันผิดศีลธรรมหรือไม่ที่ใช้ชื่อตัวแปรที่แตกต่างจากประเภทของชื่อนั้น ๆ

ตัวอย่างเช่นใช้รหัสนี้:

var person = new Person();

หรือสำหรับคุณ Pythonistas:

person = Person()

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

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

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

fastPerson
slowPerson

อย่างอื่นก็แค่

person

สบายดีกับฉัน

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

จะผิดอะไรถ้าคุณมีบุคคล 2 ประเภทและบุคคลนั้นจะผิดมาก

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

Person person = new Person(); // okay

int Int = 42; // pure evil

หากมีคนบอกว่าสิ่งนั้นชั่วร้ายให้ถามพวกเขาว่าสิ่งนี้ดีกว่าไหม:

var abc = new Person();

ถ้าบุคคลนั้นเป็นบุคคลทั่วไปในบริบทนั้น "บุคคล" เป็นชื่อที่ดีจริงๆ แน่นอนว่าถ้าบุคคลนั้นมีบทบาทเฉพาะในโค้ดก็ควรตั้งชื่อเธอโดยใช้บทบาทนั้น

ฉันคิดว่าฉันจะถูกโหวตให้พูดอย่างนั้น แต่ ...

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

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

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

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

หากไม่มีใครโต้แย้งอย่างชัดเจนฉันจะทำเช่นนี้ต่อไป

เหตุผลที่ถือว่าไม่ดีคือถ้าคุณต้องการมี 2 คนในอนาคตคุณสามารถลงเอยด้วยรหัสที่ดูเหมือน

บุคคล = บุคคลใหม่ ();

บุคคล person2 = บุคคลใหม่ ();

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

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

ฉันพูดชื่อสำหรับสิ่งที่มันคือถ้าตัวแปรหมายถึงคนที่มี 2 personWith2Dogsสุนัขเรียกว่า ตัวแปรมีขอบเขตสั้น ๆ (เช่น loop var) แล้วคนก็สบายดี

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

ไม่ใช่เรื่องผิดศีลธรรม แต่การค้นหาทั่วโลกจะพบทั้งสองอย่างPersonและpersonหากคุณไม่เปิดใช้งานกรณี - เล็ก ฉันชอบคำนำหน้าเพื่อให้การค้นหา / แทนที่ทั่วโลกง่ายขึ้น แต่ไม่ใช่ภาษาฮังการีหรืออะไรที่ยาว / ซับซ้อน ดังนั้นฉันจึงใช้ ...

Personสำหรับคลาส / ประเภท aPersonสำหรับตัวแปรโลคัล thePersonสำหรับพารามิเตอร์วิธีการ myPersonสำหรับตัวแปรอินสแตนซ์ ourPersonสำหรับตัวแปรคลาส

ในบางครั้งฉันอาจใช้pในบริบทท้องถิ่นที่ฉันมีข้อมูลอ้างอิงมากมาย แต่โดยปกติจะใช้กับดัชนีลูปและสิ่งที่คล้ายกันเท่านั้น

มันขึ้นอยู่กับ.

หากคุณมีรูปแบบการใช้อักษรตัวพิมพ์ใหญ่ที่เข้มงวดดังนั้นตัวแปรจะเริ่มเป็นตัวพิมพ์เล็ก (และใช้ under_scores หรือ camelCase สำหรับการแบ่งคำ) และ Classes เริ่มต้นด้วย Capital Letters จะเห็นได้ชัดว่าบุคคลนั้นเป็นตัวแปรและ Person คือคลาสและเมื่อมีคนเข้าใจสิ่งนี้ ดูเหมือนว่าจะไม่อยู่ในเนมสเปซที่ทับซ้อนกัน (ในทำนองเดียวกันผู้คนแทบจะไม่สับสนระหว่างคำกริยาหรือคำนาม "polish" กับคำคุณศัพท์ "Polish")

หากคุณไม่มีสไตล์ดังกล่าวแสดงว่าคุณมีสองชื่อที่อาจสับสนได้ง่ายและแตกต่างกันในบางกรณีเท่านั้น เลวร้าย.

อะไรคือข้อโต้แย้งที่แน่นอนที่คนเหล่านั้นใช้?

หากพวกเขาไม่อนุญาตให้คุณใช้บุคคลเป็นชื่อตัวแปรคุณอาจพิจารณาเพิ่มคำนำหน้า "a"

aPerson = Person()

ฉันคิดว่าสิ่งที่คุณกำลังทำอยู่นั้นสบายดี ฉันคิดว่าโดยทั่วไปแล้วสิ่งสำคัญคือต้องตกลงมาตรฐานการเข้ารหัส

ตัวอย่างเช่นฉันใช้ lowerCamelCase สำหรับอินสแตนซ์ตัวแปรและ UpperCamelCase สำหรับคลาส ฯลฯ

มาตรฐานการเข้ารหัสควรขจัดปัญหานี้

เมื่อฉันดูโปรแกรมโอเพนซอร์สที่ประสบความสำเร็จพวกเขามักจะมีมาตรฐานการเข้ารหัส

http://drupal.org/coding-standards

http://help.joomla.org/content/view/826/125/

http://wiki.rubyonrails.org/rails/pages/CodingStandards

http://lxr.linux.no/linux/Documentation/CodingStyle

การยอมรับมาตรฐานการเข้ารหัสควรเป็นการต่อสู้ครั้งสุดท้ายที่คุณมีในเรื่องนี้

ในความเป็นจริงดูรายการวิกิพีเดีย (จากhttp://en.wikipedia.org/wiki/CamelCase )

รูปแบบการเขียนโปรแกรมและการเข้ารหัส

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

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

รูปแบบการเขียนโค้ด Java ที่ใช้กันอย่างแพร่หลายกำหนดให้ใช้ UpperCamelCase สำหรับคลาสและ lowerCamelCase ใช้สำหรับอินสแตนซ์และวิธีการ [19] เมื่อรับรู้ถึงการใช้งานนี้ IDE บางตัวเช่น Eclipse ใช้ทางลัดตาม CamelCase ตัวอย่างเช่นในคุณสมบัติ Content Assist ของ Eclipse การพิมพ์เพียงตัวอักษรตัวพิมพ์ใหญ่ของคำ CamelCase จะแนะนำคลาสหรือชื่อเมธอดที่ตรงกัน (ตัวอย่างเช่นการพิมพ์ "NPE" และการเปิดใช้งานการช่วยเหลือเนื้อหาอาจแนะนำ "NullPointerException")

สัญกรณ์ภาษาฮังการีดั้งเดิมสำหรับการเขียนโปรแกรมระบุว่าตัวย่อของ "ประเภทการใช้งาน" (ไม่ใช่ประเภทข้อมูล) ควรนำหน้าชื่อตัวแปรทั้งหมดโดยส่วนที่เหลือของชื่อใน UpperCamelCase; ดังนั้นจึงเป็นรูปแบบของ lowerCamelCase CamelCase เป็นแบบแผนอย่างเป็นทางการสำหรับชื่อไฟล์ใน Java และสำหรับคอมพิวเตอร์ส่วนบุคคลของ Amiga

Microsoft .NET แนะนำ lowerCamelCase สำหรับพารามิเตอร์และฟิลด์ที่ไม่ใช่สาธารณะและ UpperCamelCase (หรือที่เรียกว่า "Pascal Style") สำหรับตัวระบุประเภทอื่น ๆ [20]

Python แนะนำ UpperCamelCase สำหรับชื่อคลาส [21]

รีจิสทรี NIEM ต้องการให้องค์ประกอบข้อมูล XML ใช้ UpperCamelCase และแอตทริบิวต์ XML ใช้ lowerCamelCase

ไม่มีแบบแผนเดียวสำหรับการรวมตัวย่อตัวพิมพ์ใหญ่ (ส่วนใหญ่เป็นคำย่อและการเริ่มต้น) ภายในชื่อ CamelCase วิธีการรวมถึงการทิ้งตัวย่อทั้งหมดไว้ในตัวพิมพ์ใหญ่ (เช่นใน "useHTTPConnection") และเหลือเพียงตัวอักษรตัวแรกในตัวพิมพ์ใหญ่ (เช่นใน "useHttpConnection")

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

เป็นไปได้ที่จะสร้างข้อโต้แย้งที่ชัดเจนขึ้นว่าชื่อเมธอดประเภทนั้นไม่เพียง แต่ไม่เป็นอันตราย แต่ยังเป็นตัวบ่งชี้รหัสคุณภาพที่ดี

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

• ตัวบ่งชี้ของการคำนวณวัตถุประสงค์ทั่วไปถูกผลักลงไปในวิธีการวัตถุประสงค์ทั่วไป: หากคุณทำการจัดการโครงสร้างข้อมูลระดับกลางในวิธีการทางธุรกิจตัวอย่างเช่นอาร์เรย์ของผู้ใช้จะต้องมีการอนุมานซ้ำคุณจะต้องมีตัวแปรในขอบเขต ที่มีชื่อเหมือนusers[]และdeduplicatedUsers[]. ถ้าคุณย้ายการขจัดข้อมูลซ้ำซ้อนเป็นวิธียูทิลิตี้ที่คุณสามารถเรียกวิธีUtils.dedup(array)และคุณสามารถโทรอาร์เรย์ซ้ำหรือเพียงแค่deduplicatedArrayresult

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

• หลักการดูแลร์รี่กำแพงของ "ความคลุมเครือท้องถิ่น is OK" - http://www.wall.org/~larry/natural.html

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

newContactดังนั้นถ้าคุณต้องการที่จะสร้างรายชื่อใหม่ในการประยุกต์ใช้สมุดที่อยู่ของคุณคุณอาจต้องการที่จะเรียกตัวแปร

และถ้าคุณกำลังทดสอบโค้ดของคุณเพื่อตรวจสอบพฤติกรรมของอPersonอบเจ็กต์ที่ไม่มีการตั้งชื่อคุณอาจต้องการเรียกunnamedPersonสิ่งเหล่านี้หรือสิ่งที่คล้าย

เรียกได้ว่าเป็นการpersonละทิ้งโอกาสครั้งใหญ่ในการจัดทำเอกสารด้วยตนเองของโค้ด

เฉพาะในกรณีที่คุณกำลังเขียนโปรแกรมใน VB6 ในกรณีนี้สิ่งที่คุณทำนั้นผิดกฎหมาย แต่ไม่ผิดศีลธรรม

ฉันก็ทำเช่นกันและฉันก็ไม่เข้าใจว่าทำไมจึงควร 'ผิดศีลธรรม' แม้ว่าฉันจะเข้าใจว่าบางครั้งอาจจะสับสน แต่วันนี้เรามี IDE ที่มี Intellisense และการเน้นไวยากรณ์ซึ่งจะทำให้แน่ใจได้ว่า (ถ้าคุณทำผิดและอ้างอิงตัวแปรของคุณแทนชั้นเรียนของคุณและในทางกลับกัน) คุณจะ เห็นข้อผิดพลาดของคุณค่อนข้างเร็ว และเรายังมีคอมไพเลอร์ :)

ฉันไม่เห็นปัญหาใด ๆ กับการปฏิบัตินี้ ตราบใดที่มีตัวแปรเดียวของคลาสนั้นก็เขียนง่ายและอ่านง่าย Imo ที่ใช้ในโปรแกรมแก้ไขข้อความพื้นฐาน โดยส่วนตัวฉันจำไม่ได้ว่ามีใครเรียกสิ่งนี้ว่าเลวร้ายหรือผิดศีลธรรม ทำสิ่งนี้ต่อไป :)

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

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

Decimal _decimal = item.BaseCost + item.Tax;

แต่ขอแนะนำให้ใช้ชื่อที่สื่อความหมายมากขึ้นเช่น "_total" หรือ "_cost"

ปัญหาเดียวของสิ่งนี้ที่ฉันพบคือถ้าคุณต้องการชื่อเดียวกันสำหรับสมาชิกส่วนตัวและทรัพย์สินสาธารณะ

หากสิ่งเหล่านี้แตกต่างกันเฉพาะในกรณีนี้จะใช้งานได้ดีในภาษาที่คำนึงถึงตัวพิมพ์เล็กและใหญ่เช่น C # แต่ไม่ใช่ใน VB.NET

ตัวอย่างเช่นใน VB ฉันจะเขียน

Private _name As String

แต่

Public Property Name() As String
    Get
        Return _name
    End Get
    Set(ByVal Value As String)
        _name = Value
    End Set
End Property

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

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

ผมใช้Person person = new Person()เองบ่อยๆ นิยมใช้ใน Java / C #

แม้ว่าฉันจะสงสัยเมื่อวานนี้ว่าทำไม

private enum DataType {NEW, OLD}

ไม่ทำงานใน C # ...

โดยเฉพาะอย่างยิ่งที่ได้เห็นวิธีการที่คุณสามารถใช้String, string, Double, double... ที่จะใน C #

Person person = new Person()

หนังสือของฉันสบายดี

สิ่งที่น่ากลัวก็คือเมื่อคุณมี:

string Person;
string person;

ง่ายมากที่จะผสม 2.

สิ่งที่แสดงต่อฉันอื่น ๆ ที่ไม่เป็นไปตามมาตรฐานการเข้ารหัสของเราคือการหลีกเลี่ยงการเพิ่มความสับสนเมื่อมีคนอื่นอ่านรหัสของฉัน โดยส่วนตัวฉันไม่เห็นปัญหากับมันตราบใดที่ความหมายยังชัดเจน

สำหรับประเภท CLR (int, string ฯลฯ ) คุณสามารถใช้ String หรือ string (ฯลฯ ) เพื่อประกาศประเภทได้ดังนั้นฉันจะหลีกเลี่ยงการใช้สิ่งต่างๆเช่น

int Int = 0;
string String = "hi there";

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

fastPerson / slowPerson เหมือนข้างบนนั้นใช้ได้ ... มันอธิบายและแตกต่างจากชื่อประเภทตัวแปร ... แต่มากับมนุษย์การเรียก int "Int" จะเป็นเรื่องขี้เกียจธรรมดา

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

void SaveToDatabase(Person person) {...}

เกี่ยวกับสิ่งเดียวที่คุณสามารถเรียกคนอย่างสมเหตุสมผลได้คือperson_to_saveหรืออะไรทำนองนั้นที่ดูเหมือนซ้ำซ้อน

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

void AddToAccount(Account account, Person person)  {...}

กว่านี้

void AddToAccount(Account account, Person dependent)  {...}

อย่างไรก็ตามโปรดอย่าใส่ 'a' หรือ 't' ไว้หน้าชื่อประเภท IE aPerson สำหรับ 'บุคคล' หรือ tPerson สำหรับ 'บุคคล' มันซับซ้อนเกินไปและไม่เพิ่มมูลค่าใด ๆ นอกจากนี้คุณยังเริ่มสร้างมลพิษให้กับขอบเขตของคุณด้วยตัวแปรมากมายที่ขึ้นต้นด้วย a หรือ t ซึ่งสามารถลดค่าของ intelli-sense ได้

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

Person aPerson = new Person();

มันทำให้รหัสอ่านเป็นธรรมชาติมากขึ้นฉันคิดว่า

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

กฎง่ายๆของฉัน? ข้อความในรหัสควรอ่านเหมือนประโยคภาษาอังกฤษง่ายๆ

บุคคล = บุคคลใหม่ ();

พนักงานลูกจ้าง = person.getRole (EMPLOYEE);

ผู้ปกครองหลัก = person.getRole (PARENT);

person.getFullName ();

พนักงาน.getSalary ();

parent.getChildren ();

parent.getFullName (); // สมมติว่าเป็นรูปแบบมัณฑนากรที่เล่น

ถ้า (person.hasRole (EMPLOYEE)) {

  ...

}

และอื่น ๆ

หากขอบเขตของตัวแปรมี จำกัด (เช่นวิธีการห่อหุ้มคือ 10-15 บรรทัด) ฉันอาจใช้ 'p' แทน 'person' ชื่อตัวแปรที่สั้นกว่าจะไม่ทำให้ไขว้เขวน้อยลงเมื่อพยายามเก็บบริบทไว้ในหัว หลีกเลี่ยงคำนำหน้าโดยไม่จำเป็นเช่น "a" หรือ (ตัวสั่น) สัญกรณ์ภาษาฮังกาเรียนและการวางตำแหน่งดังกล่าว (โปรดทราบว่าฉันไม่มีอะไรต่อต้านคำนำหน้าดังกล่าวเมื่อใช้ในบริบทที่เหมาะสม - รหัส C ++ / COM / ATL / Win32 API เป็นต้นซึ่งจะช่วยให้การมอบหมายงาน / การพิมพ์ตรง)

สอง (!) บิตของฉัน :-)