มีเทคนิคหรือแบบทดสอบที่ดีสำหรับประเภทการตั้งชื่อหรือไม่

คำถามเปิดกว้างที่น่าอึดอัดใจ แต่มันเป็นปัญหาที่ฉันต้องเผชิญกับ:

ซอฟต์แวร์ที่ง่ายต่อการบำรุงรักษาและใช้งานด้วยซอฟต์แวร์ที่ออกแบบมาอย่างดี การพยายามออกแบบให้ใช้งานง่ายหมายถึงการตั้งชื่อคอมโพเนนต์ของคุณในลักษณะที่นักพัฒนาซอฟต์แวร์รายต่อไปควรสามารถสรุปการทำงานของส่วนประกอบ นี่คือเหตุผลที่เราไม่ตั้งชื่อคลาสของเรา "Type1", "Type2" เป็นต้น

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

มันแย่ลง (สำหรับฉัน) เมื่อพยายามตั้งชื่อตระกูลประเภทโดยใช้ประเภทฐานหรือส่วนต่อประสานที่อธิบายถึงองค์ประกอบที่ต้องทำ แต่ไม่ใช่วิธีการทำงาน สิ่งนี้นำไปสู่แต่ละประเภทที่ได้มาโดยพยายามอธิบายถึงรสชาติของการนำไปใช้ (เช่นIDataConnectionและSqlConnectionใน. NET Framework) แต่คุณจะแสดงบางสิ่งที่ซับซ้อนเช่น "ทำงานโดยสะท้อนและมองหาชุดคุณลักษณะเฉพาะ" ได้อย่างไร

จากนั้นเมื่อคุณเลือกชื่อสำหรับประเภทที่คุณคิดว่าอธิบายว่ามันกำลังพยายามทำอะไรเพื่อนร่วมงานของคุณถามว่า "WTF ทำสิ่งนี้ได้DomainSecurityMetadataProviderจริงหรือไม่ "

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

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

สำหรับการตั้งชื่อมีหกเทคนิคที่พิสูจน์แล้วว่าเหมาะกับฉัน:

1. ใช้เวลามากมายในการประดิษฐ์ชื่อ
2. ใช้ความคิดเห็นรหัส
3. อย่าลังเลที่จะเปลี่ยนชื่อ
4. ใช้เวลามากมายในการประดิษฐ์ชื่อ
5. ใช้ความคิดเห็นรหัส
6. อย่าลังเลที่จะเปลี่ยนชื่อ

PS ในกรณีที่ API ของคุณเป็นแบบสาธารณะข้างต้นจะใช้ก่อนหน้านั้นเพราะคุณรู้

"Public APIs เช่นเดียวกับเพชรนั้นคงอยู่ตลอดไปคุณมีโอกาสเดียวที่จะทำให้ถูกต้องดังนั้นจงทำให้ดีที่สุด ... " (Joshua Bloch, วิธีการออกแบบ API ที่ดีและทำไมจึงเป็นเรื่องสำคัญ )

การทดสอบพื้นฐานของฉันคือถ้าคุณสามารถอธิบายฟังก์ชั่นของตัวแปรโดยใช้คำเพียงคำเดียวจากตัวแปร:

เช่นถ้า DomainSecurityMetadataProvider อาจเป็น "ให้ข้อมูลเมตาความปลอดภัยของโดเมน" หรือ "แสดงข้อมูลเมตาที่เกี่ยวข้องกับความปลอดภัยของโดเมน" ก็ถือว่าดี

อย่างไรก็ตามมีความแตกต่างที่แตกต่างกันไปในแต่ละบุคคล:

เช่นสำหรับฉัน original_team_code เป็นรหัสสำหรับทีมดั้งเดิมในขณะที่คนอื่นอาจเป็นรหัสดั้งเดิมสำหรับทีม หนึ่งในรายการโปรดส่วนตัวของฉันคือ "UnsafeLegacyMutex" ซึ่งฉันอดไม่ได้ที่จะอ่านว่า "นี่คือ Mutex แบบดั้งเดิมซึ่งไม่ปลอดภัย" แทนที่จะเป็น "นี่คือ Mutex สำหรับ ThreadUnsafe Legacy Code"

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

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

ไม่ได้จริงๆ

อย่างไรก็ตามหนึ่งเคล็ดลับคือการหลีกเลี่ยง

"DomainSecurityMetadataProvider" เป็นแบบพาสซีฟ ไม่มีคำกริยามันเป็นคำนามและคำนามทั้งหมดที่ใช้เป็นคำคุณศัพท์

"ProvideMetadataForDomainSecurity" เปิดใช้งานมากกว่า มีคำกริยา

การเขียนโปรแกรมเชิงวัตถุเป็นคำนามทั้งหมด (จริงๆ) คำนาม == วัตถุ Verb == method ดังนั้นชื่อคลาสจึงมักเป็น "คำนาม" มาก การเลิกนิสัยนี้และเริ่มเติมคำกริยาเป็นเรื่องยาก

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

ใช่. คุณกำหนดการทดสอบที่ยอดเยี่ยมในคำถามของคุณ ถามคนอื่น

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

การใช้อรรถาภิธาน

บ่อยครั้งที่ฉันจะอ้างถึงอรรถาภิธานเมื่อทำการพัฒนาใหม่เพื่อหาคำที่เหมาะสมเพื่ออธิบายชั้นเรียนและวิธีการของฉัน

คลาสที่มีตรรกะการดำเนินงานเป็นหลัก

ฉันมักจะตั้งชื่อคลาสที่ให้วิธีการดำเนินการเป็นหลักในโครงสร้างคำนามคำกริยาเช่น "EntityProvider", "EntityLocator" ฯลฯ

คลาสเหล่านี้โดยทั่วไปไม่มีสถานะเป็นจำนวนมาก

คลาสที่มีสถานะ

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

ตัวอย่าง: บุคคลพนักงานลูกจ้างปัจจุบันพนักงานเก่าลูกจ้าง

คลาสยูทิลิตี้

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

ตัวอย่าง: NetworkUtilities, FileUtilities

การทดสอบ

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

หากคุณรู้สึกว่ามีคลาส / เมธอดที่ไม่ได้รับการบันทึกโดยชื่อคลาส / เมธอดนั้นอาจต้องได้รับการปรับโครงสร้างใหม่

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

บทความของ Jeff ยังแสดงรายการแนวทางที่แนะนำจาก Code Complete ของ Steve McConnell

ตัวแปร

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

string firstNameOfEmployee;

string lastNameOfEmployee;

// here I nimbly avoid worrying about whether to call it "Id" or "ID" :)
int idOfEmployee;

decimal amountForDeposit;

Account accountForDeposit;

ฉันพบว่ามันใช้งานได้ดีกับฟีเจอร์ Intellisense ของ Visual Studio ทำให้พิมพ์ชื่อยาวเหล่านี้ได้ง่าย ฉันยังพบว่ามีการทำซ้ำคำนำหน้าชื่อตัวแปรน้อยกว่า (เช่น personID, personFirstName, personLastName เทียบกับ idOfPerson, firstNameOfPerson, lastNameOfPerson) ซึ่งจะให้ "แฮช" ที่ดียิ่งขึ้นซึ่งทำให้ Intellisense มีประโยชน์มากยิ่งขึ้น

จากนั้นเมื่อคุณเลือกชื่อประเภทที่คุณคิดว่าจะพยายามทำอะไรเพื่อนร่วมงานของคุณถามว่า "WTF DomainSecurityMetadataProvider นี้ทำ WTF ได้จริงหรือไม่"

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

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

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

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

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

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

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