ถ้าฉันเขียนรหัสเพิ่มขึ้นเรื่อย ๆ มันจะมีเวลาที่ฉันจะจัดระเบียบรหัสได้ยาก
นี่คือปัญหาของคุณ: ทำให้องค์กรถูกต้องและสไตล์ควรไหลได้ง่ายขึ้น
อย่ารอที่จะจัดระเบียบรหัสของคุณ: จัดระเบียบรหัสของคุณตามที่คุณไป แม้ว่าภาษานั้นจะไม่เหมาะกับคุณ แต่รหัสก็ควรจะจัดเป็นโมดูลที่มีคัปปลิ้งต่ำและการรวมตัวที่สูง
โมดูลเหล่านี้จะให้เนมสเปซตามธรรมชาติ อักษรย่อของชื่อโมดูล (ถ้ายาว) และชื่อฟังก์ชันนำหน้าพร้อมกับโมดูลเพื่อหลีกเลี่ยงการชน
ในระดับของตัวระบุแต่ละตัวสิ่งเหล่านี้อยู่ในลำดับที่เพิ่มขึ้นของความเป็นส่วนตัว:
- เลือกการประชุมและติดกับมัน
- เช่น
function_like_this(struct TypeLikeThis variable)เป็นเรื่องปกติ
หลีกเลี่ยงสัญกรณ์ฮังการีอย่างแน่นอน (ขออภัย JNL)
นอกเสียจากว่าคุณจะยินดีที่จะใช้มันตามที่ตั้งใจไว้เดิมซึ่งหมายถึงสัญกรณ์ของแอพของ Simonyi แทนที่จะเป็นเวอร์ชั่นที่แย่มาก
ทำไม? ฉันสามารถเขียนเรียงความเกี่ยวกับเรื่องนี้ แต่ฉันขอแนะนำให้คุณอ่านบทความนี้โดย Joel Spolsky แล้วตามล่าอีกรอบหากคุณสนใจ มีลิงค์ไปยังเอกสารต้นฉบับของ Simonyi ที่ด้านล่าง
หลีกเลี่ยงการพิมพ์ตัวชี้เว้นแต่ว่าพวกเขาเป็นประเภทคุกกี้ทึบแสงอย่างแท้จริง - พวกเขาสับสนเท่านั้น
struct Type *ok;
typedef struct Type *TypePtr;
TypePtr yuck;
ฉันหมายถึงอะไรโดยคุกกี้ชนิดทึบแสง ? บางสิ่งบางอย่างที่ฉันหมายถึงใช้ภายในโมดูล (หรือห้องสมุดหรืออะไรก็ตาม) ซึ่งจะต้องมีการผ่านออกมาในรหัสลูกค้า แต่รหัสลูกค้าที่ไม่สามารถใช้งานได้โดยตรง มันเพิ่งผ่านมันกลับไปที่ห้องสมุด
ตัวอย่างเช่นไลบรารีฐานข้อมูลอาจเปิดเผยอินเตอร์เฟสเช่น
/* Lots of buffering, IPC and metadata magic held in here.
No, you don't get to look inside. */
struct DBContextT;
/* In fact, you only ever get a pointer, so let's give it a nice name */
typedef struct DBContexT *DBContext;
DBContext db_allocate_context(/*maybe some optional flags?*/);
void db_release_context(DBContext);
int db_connect(DBContext, const char *connect);
int db_disconnect(DBContext);
int db_execute(DBContext, const char *sql);
ตอนนี้บริบทจะทึบกับรหัสลูกค้าเนื่องจากคุณไม่สามารถมองเข้าไปข้างใน คุณเพิ่งส่งมันกลับไปที่ห้องสมุด บางสิ่งที่คล้ายกันFILEนั้นยังทึบแสงและตัวอธิบายไฟล์จำนวนเต็มก็เป็นคุกกี้เช่นกัน แต่ก็ไม่ทึบ
หมายเหตุเกี่ยวกับการออกแบบ
ฉันใช้วลีการมีเพศสัมพันธ์ต่ำและการติดต่อกันสูงด้านบนโดยไม่มีคำอธิบายและฉันรู้สึกไม่ดีเกี่ยวกับเรื่องนั้น คุณสามารถค้นหาและอาจพบผลลัพธ์ที่ดี แต่ฉันจะพยายามพูดสั้น ๆ (อีกครั้งฉันสามารถเขียนเรียงความ แต่จะพยายามไม่ทำ)
ไลบรารีฐานข้อมูลที่ร่างไว้ด้านบนแสดงการมีเพศสัมพันธ์ต่ำเพราะมันเปิดเผยอินเตอร์เฟสขนาดเล็กสู่โลกภายนอก โดยการซ่อนรายละเอียดการใช้งาน (ส่วนหนึ่งด้วยเคล็ดลับคุกกี้ทึบแสง) จะช่วยป้องกันรหัสลูกค้าขึ้นอยู่กับรายละเอียดเหล่านั้น
ลองนึกภาพแทนคุกกี้ทึบแสงเราประกาศโครงสร้างบริบทเพื่อให้มองเห็นเนื้อหาและมีตัวบ่งชี้ไฟล์ซ็อกเก็ตสำหรับการเชื่อมต่อ TCP ไปยังฐานข้อมูล หากในภายหลังเราเปลี่ยนการใช้งานเพื่อรองรับการใช้เซ็กเมนต์หน่วยความจำที่แชร์เมื่อ DB กำลังทำงานบนเครื่องเดียวกันไคลเอนต์จะต้องรวบรวมใหม่แทนที่จะเชื่อมโยงใหม่ ยิ่งไปกว่านั้นไคลเอนต์อาจเริ่มใช้ตัวอธิบายไฟล์เช่นการเรียกsetsockoptเพื่อเปลี่ยนขนาดบัฟเฟอร์เริ่มต้นและตอนนี้ก็จำเป็นต้องเปลี่ยนรหัสเช่นกัน รายละเอียดทั้งหมดเหล่านี้ควรถูกซ่อนอยู่ในโมดูลของเราซึ่งใช้งานได้จริงและทำให้การเชื่อมต่อระหว่างโมดูลมีน้อย
ตัวอย่างยังแสดงให้เห็นถึงการทำงานร่วมกันสูงในที่วิธีการทั้งหมดในโมดูลที่เกี่ยวข้องกับงานเดียวกัน (การเข้าถึงฐานข้อมูล) ซึ่งหมายความว่าเฉพาะรหัสที่จำเป็นต้องรู้เกี่ยวกับรายละเอียดการใช้งาน (นั่นคือเนื้อหาของคุกกี้ของเรา) มีสิทธิ์เข้าถึงได้จริงซึ่งจะช่วยให้การดีบักง่ายขึ้น
คุณจะเห็นว่าการมีข้อกังวลใจเดียวทำให้ง่ายต่อการเลือกคำนำหน้าเพื่อจัดกลุ่มฟังก์ชั่นเหล่านี้เข้าด้วยกัน
ตอนนี้การพูดตัวอย่างนี้เป็นเรื่องง่าย (โดยเฉพาะอย่างยิ่งเนื่องจากมันยังไม่สมบูรณ์) แต่ก็ไม่ได้ช่วยคุณทันที เคล็ดลับคือการดูในขณะที่คุณเขียนและขยายรหัสของคุณสำหรับฟังก์ชั่นที่ทำสิ่งที่คล้ายกันหรือทำงานในประเภทเดียวกัน (ซึ่งอาจจะเป็นผู้สมัครสำหรับโมดูลของตัวเอง) และสำหรับฟังก์ชั่นที่ทำสิ่งต่าง ๆ มากมาย ไม่เกี่ยวข้องกันมากและอาจเป็นผู้สมัครเพื่อแยกออก