การใช้ #define เหมาะสมเพื่อให้การพิมพ์รหัสซ้ำง่ายขึ้นหรือไม่

มีความเห็นว่าการใช้ #define เพื่อกำหนดรหัสเต็มบรรทัดสำหรับการทำให้โค้ดง่ายขึ้นหรือไม่นั้นเป็นวิธีปฏิบัติที่ดีหรือไม่ดี? ตัวอย่างเช่นหากฉันต้องการพิมพ์คำจำนวนมากด้วยกันฉันจะรู้สึกรำคาญเมื่อพิมพ์

<< " " <<

เพื่อแทรกช่องว่างระหว่างคำในคำสั่ง cout ฉันทำได้

#define pSpace << " " <<

และประเภท

cout << word1 pSpace word2 << endl;

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

ความคิดใด ๆ เกี่ยวกับเรื่องนี้?

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

การเขียนรหัสเป็นเรื่องง่าย การอ่านรหัสเป็นเรื่องยาก

คุณเขียนโค้ดครั้งเดียว มันมีชีวิตอยู่นานหลายปีผู้คนอ่านมันร้อยครั้ง

ปรับรหัสให้เหมาะสมสำหรับการอ่านไม่ใช่เพื่อการเขียน

ส่วนตัวฉันเกลียดมัน มีหลายสาเหตุที่ฉันไม่แนะนำให้ผู้คนใช้เทคนิคนี้:

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

2. มันไม่สามารถอ่านได้ อาจเป็นที่ชัดเจนสำหรับคุณ .. ในตอนนี้ .. หากเป็นเพียงนิยามนี้ หากมันกลายเป็นนิสัยคุณจะพบกับ #defines จำนวนมากและจะเริ่มติดตามตัวเองในไม่ช้า แต่ที่แย่ที่สุดคือไม่มีใครสามารถเข้าใจความword1 pSpace word2หมายที่แท้จริง (โดยไม่ต้องค้นหา #define)

3. มันอาจกลายเป็นปัญหาสำหรับเครื่องมือภายนอก สมมติว่าคุณลงท้ายด้วย #define ที่มีเครื่องหมายวงเล็บปิดอยู่ แต่ไม่มีเครื่องหมายวงเล็บเปิด ทุกอย่างอาจทำงานได้ดี แต่บรรณาธิการและเครื่องมืออื่น ๆ อาจเห็นสิ่งfunction(withSomeCoolDefine;ที่ค่อนข้างแปลกประหลาด (เช่นพวกเขาจะรายงานข้อผิดพลาดและอะไรก็ตาม) (ตัวอย่างที่คล้ายกัน: การเรียกใช้ฟังก์ชันภายใน define - เครื่องมือวิเคราะห์ของคุณจะสามารถค้นหาการโทรนี้ได้หรือไม่)

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

ความคิดหลักของฉันเกี่ยวกับเรื่องนี้คือฉันไม่เคยใช้ "ทำให้การพิมพ์ง่ายขึ้น" เป็นกฎเมื่อเขียนโค้ด

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

เช่น #define ที่คุณใช้เพียงแค่แบ่งทางปกติของการสลับ<<และอื่นสิ่ง มันทำลายกฎของความประหลาดใจน้อยที่สุดและไม่ใช่ IMHO

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

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

ตัวอย่างแรกปรากฏในCppUnitซึ่งเป็นกรอบการทดสอบหน่วย เช่นเดียวกับกรอบการทดสอบมาตรฐานอื่น ๆ ที่คุณสร้างคลาสการทดสอบและจากนั้นคุณต้องระบุวิธีการที่ควรจะเรียกใช้เป็นส่วนหนึ่งของการทดสอบ

#include <cppunit/extensions/HelperMacros.h>

class ComplexNumberTest : public CppUnit::TestFixture  
{
    CPPUNIT_TEST_SUITE( ComplexNumberTest );
    CPPUNIT_TEST( testEquality );
    CPPUNIT_TEST( testAddition );
    CPPUNIT_TEST_SUITE_END();

 private:
     Complex *m_10_1, *m_1_1, *m_11_2;
 public:
     void setUp();
     void tearDown();
     void testEquality();
     void testAddition();
}

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

บล็อกมาโครเหล่านี้ขยายออกเป็นดังนี้:

public: 
  static CppUnit::Test *suite()
  {
    CppUnit::TestSuite *suiteOfTests = new CppUnit::TestSuite( "ComplexNumberTest" );
    suiteOfTests->addTest( new CppUnit::TestCaller<ComplexNumberTest>( 
                                   "testEquality", 
                                   &ComplexNumberTest::testEquality ) );
    suiteOfTests->addTest( new CppUnit::TestCaller<ComplexNumberTest>(
                                   "testAddition",
                                   &ComplexNumberTest::testAddition ) );
    return suiteOfTests;
  }

คุณต้องการอ่านและบำรุงรักษาข้อใด

ตัวอย่างอื่นอยู่ในกรอบงาน Microsoft MFC ซึ่งคุณแมปฟังก์ชันกับข้อความ:

BEGIN_MESSAGE_MAP( CMyWnd, CMyParentWndClass )
    ON_MESSAGE( WM_MYMESSAGE, OnMyMessage )
    ON_COMMAND_RANGE(ID_FILE_MENUITEM1, ID_FILE_MENUITEM3, OnFileMenuItems)
    // ... Possibly more entries to handle additional messages
END_MESSAGE_MAP( )

ดังนั้นสิ่งที่แตกต่าง "มาโครที่ดี" จากความชั่วร้ายที่น่ากลัวคืออะไร?

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

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

มันจะเป็นการดีกว่าถ้าคุณปรับแต่ง IDE / text editor ที่คุณชื่นชอบสำหรับการแทรกโค้ดที่คุณพบว่าน่าเบื่อเพื่อพิมพ์ซ้ำอีกครั้ง และดีกว่าคือคำว่า "สุภาพ" สำหรับการเปรียบเทียบ ที่จริงแล้วฉันไม่สามารถคิดเกี่ยวกับกรณีที่คล้ายกันใด ๆ เมื่อ preprocessing แมโครของบรรณาธิการเต้น อาจเป็นหนึ่งในเหตุผลที่ลึกลับและไม่มีความสุขคุณกำลังใช้ชุดเครื่องมือที่แตกต่างกันสำหรับการเข้ารหัส แต่มันไม่ใช่เหตุผล :)

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

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

ตัวอย่างที่ฉาวโฉ่เกี่ยวกับการประยุกต์ใช้เทคนิคที่ชาญฉลาดนี้คือโครงการเสียงดังกราวด์ : ดูว่าอย่างไร.defมีการใช้ไฟล์ด้วยแมโครและ#includeคุณสามารถให้คำจำกัดความการประกาศบางครั้งเดียวทั้งหมดสำหรับคอลเลกชันของสิ่งที่คล้ายกันซึ่งจะไม่ถูกควบคุมลงในการประกาศประเภทคำcaseสั่งตามที่เหมาะสมเริ่มต้นเริ่มต้น ฯลฯ มันเพิ่มการบำรุงรักษาอย่างมีนัยสำคัญ: คุณจะไม่ลืมเพิ่มcaseคำสั่งทุกที่เมื่อคุณเพิ่มใหม่enumตัวอย่างเช่น

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

ไม่เหมาะสมที่จะใช้ #defines เช่นนั้น ในกรณีของคุณคุณสามารถทำได้:

class MyCout 
{
public:
  MyCout (ostream &out) : m_out (out), m_space_pending (false)
  {
  }

  template <class T>
  MyCout &operator << (T &value)
  { 
    if (m_space_pending)
      m_out << " ";

    m_out << value;
    m_space_pending = false;
    return *this;
  }

  MyCout &operator << (const char *value)
  {
    if (m_space_pending)
      m_out << " ";

    m_out << value;
    m_space_pending = true;
    return *this;
  }

  MyCout &operator << (char *value) { return operator << (static_cast <const char *> (value)); }
  MyCout &operator << (ostream& (*fn)(ostream&)) { m_out << fn; return *this; }

private:
  ostream
    &m_out;

  bool
    m_space_pending;
};

int main (int argc, char *argv [])
{
  MyCout
    space_separated (cout);

  space_separated << "Hello" << "World" << endl;
}

เลขที่

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

// These don't compile:

#define pSpace (<< " " <<)
cout << word1 pSpace word2 << endl;

#define space(x) (" " << (x))
cout << word1 << space(word2) << endl;

// These do:

#define FOO_FACTOR (38)
x = y * FOO_FACTOR;

#define foo() (cout << "Foo" << endl)
foo();

#define die(c) { if ((c)) { exit(1); } }
die(foo > 8);

#define space(x) (" " + string((x)))
cout << "foo" << space("bar") << endl;

มาโครที่ใช้ในการประกาศ (เช่นตัวอย่างในคำตอบของ Andrew Shepherd) สามารถหนีออกมาได้ด้วยชุดของกฎที่หลวมตราบใดที่พวกเขาไม่ได้ทำให้บริบทรอบข้างไม่พอใจ (เช่นการสลับระหว่างpublicและprivate)

เป็นสิ่งที่สมเหตุสมผลที่ควรทำในโปรแกรม "C" ที่บริสุทธิ์

มันไม่จำเป็นและสับสนในโปรแกรม C ++

มีหลายวิธีในการหลีกเลี่ยงการพิมพ์รหัสซ้ำใน C ++ จากการใช้สิ่งอำนวยความสะดวกที่มีให้โดย IDE ของคุณ (แม้จะมี vi ง่าย " %s/ pspace /<< " " <</g" จะช่วยประหยัดการพิมพ์ได้มากและยังคงผลิตรหัสที่สามารถอ่านได้มาตรฐาน) คุณสามารถกำหนดวิธีการส่วนตัวเพื่อใช้สิ่งนี้หรือสำหรับกรณีที่ซับซ้อนมากขึ้นแม่แบบ C ++ จะเป็นวิธีที่สะอาดและง่าย

ใน C ++ สามารถแก้ไขได้ด้วยตัวดำเนินการมากไป หรือแม้แต่บางสิ่งที่ง่ายเหมือนฟังก์ชั่น Variadic:

lineWithSpaces(word1, word2, word3, ..., wordn)ทั้งง่ายและช่วยให้คุณพิมพ์pSpacesซ้ำแล้วซ้ำอีก

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

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

มีความเห็นว่าการใช้ #define เพื่อกำหนดรหัสเต็มบรรทัดสำหรับการทำให้โค้ดง่ายขึ้นหรือไม่นั้นเป็นวิธีปฏิบัติที่ดีหรือไม่ดี?

ใช่มันแย่มาก ฉันเคยเห็นคนที่ทำสิ่งนี้:

#define R return

เพื่อบันทึกการพิมพ์ (สิ่งที่คุณพยายามจะทำ)

รหัสดังกล่าวอยู่ในสถานที่เช่นนี้เท่านั้น

มาโครเป็นสิ่งชั่วร้ายและควรใช้เมื่อคุณต้องทำเท่านั้น มีบางกรณีที่สามารถใช้งานแมโครได้ (มีการดีบักเป็นหลัก) แต่ใน C ++ ส่วนใหญ่คุณสามารถใช้ฟังก์ชั่นอินไลน์แทน

ไม่มีคุณไม่ได้รับอนุญาตให้ใช้แมโครเพื่อบันทึกการพิมพ์

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

เพื่อลดการพิมพ์บรรณาธิการส่วนใหญ่มีมาโครแม้แต่โค้ดอัจฉริยะ