Đây có phải là cách sử dụng thích hợp của #define để giúp việc nhập mã lặp lại dễ dàng hơn không?

Có bất kỳ quan điểm nào về việc sử dụng #define để xác định các dòng mã đầy đủ để đơn giản hóa mã hóa là thực hành lập trình tốt hay xấu? Ví dụ: nếu tôi cần in một loạt các từ với nhau, tôi sẽ cảm thấy khó chịu khi gõ

<< " " <<

Để chèn khoảng trắng giữa các từ trong câu lệnh cout. Tôi chỉ có thể làm

#define pSpace << " " <<

và gõ

cout << word1 pSpace word2 << endl;

Đối với tôi điều này không thêm hoặc bớt đi sự rõ ràng của mã và làm cho việc gõ dễ dàng hơn một chút. Có những trường hợp khác mà tôi có thể nghĩ về việc gõ sẽ dễ dàng hơn nhiều, thường là để gỡ lỗi.

Bất kỳ suy nghĩ về điều này?

EDIT: Cảm ơn tất cả các câu trả lời tuyệt vời! Câu hỏi này chỉ đến với tôi sau khi thực hiện nhiều lần gõ lặp đi lặp lại, nhưng tôi không bao giờ nghĩ rằng sẽ có các macro khác, ít gây nhầm lẫn hơn để sử dụng. Đối với những người không muốn đọc tất cả các câu trả lời, cách thay thế tốt nhất là sử dụng các macro của IDE của bạn để giảm việc gõ lặp đi lặp lại.

Viết mã rất dễ. Đọc mã là khó.

Bạn viết mã một lần. Nó sống trong nhiều năm, mọi người đọc nó hàng trăm lần.

Tối ưu hóa mã để đọc, không phải để viết.

Cá nhân, tôi ghê tởm nó. Có một số lý do tại sao tôi không khuyến khích mọi người từ kỹ thuật này:

1. Tại thời điểm biên dịch, các thay đổi mã thực tế của bạn có thể là đáng kể. Anh chàng tiếp theo xuất hiện và thậm chí bao gồm một khung đóng trong #define của anh ta hoặc một lệnh gọi hàm. Những gì được viết tại một điểm mã nhất định khác xa với những gì sẽ có sau khi xử lý trước.

2. Nó là không thể đọc được. Nó có thể rõ ràng với bạn .. bây giờ .. nếu đó chỉ là một định nghĩa. Nếu nó trở thành thói quen, bạn sẽ sớm kết thúc với hàng tá #defines và sẽ bắt đầu tự mình theo dõi. Nhưng tệ nhất trong tất cả, không ai khác có thể hiểu word1 pSpace word2chính xác nghĩa là gì (mà không cần tra cứu #define).

3. Nó có thể trở thành một vấn đề cho các công cụ bên ngoài. Giả sử bạn bằng cách nào đó kết thúc với #define bao gồm khung đóng, nhưng không có khung mở. Mọi thứ có thể hoạt động tốt, nhưng các biên tập viên và các công cụ khác có thể thấy một cái gì đó function(withSomeCoolDefine;khá kỳ dị (nghĩa là họ sẽ báo cáo lỗi và không có gì). (Ví dụ tương tự: một lệnh gọi hàm bên trong một định nghĩa - các công cụ phân tích của bạn có thể tìm thấy cuộc gọi này không?)

4. Bảo trì trở nên khó khăn hơn nhiều. Bạn có tất cả những định nghĩa bên cạnh các vấn đề thông thường mà bảo trì mang theo. Ngoài điểm trên, công cụ hỗ trợ tái cấu trúc cũng có thể bị ảnh hưởng tiêu cực.

Suy nghĩ chính của tôi về điều này, là tôi không bao giờ sử dụng "làm cho việc gõ dễ dàng hơn" như một quy tắc khi viết mã.

Quy tắc chính của tôi khi viết mã là làm cho nó dễ đọc. Lý do đằng sau điều này chỉ đơn giản là mã được đọc một thứ tự cường độ nhiều lần hơn nó được viết. Như vậy, thời gian bạn mất việc viết nó một cách cẩn thận, có trật tự, được đặt ra một cách chính xác trên thực tế đã được đầu tư để làm cho việc đọc thêm và hiểu nhanh hơn nhiều.

Như vậy, #define bạn sử dụng chỉ đơn giản là phá vỡ cách thông thường của xen kẽ <<và các công cụ khác . Nó phá vỡ quy tắc ít bất ngờ nhất và không phải là một điều tốt.

Câu hỏi này đưa ra một ví dụ rõ ràng về cách bạn có thể sử dụng macro một cách tồi tệ. Để xem các ví dụ khác (và được giải trí) xem câu hỏi này .

Phải nói rằng, tôi sẽ đưa ra các ví dụ trong thế giới thực về những gì tôi cho là kết hợp tốt các macro.

Ví dụ đầu tiên xuất hiện trong CppUnit , là khung kiểm tra đơn vị. Giống như bất kỳ khung thử nghiệm tiêu chuẩn nào khác, bạn tạo một lớp thử nghiệm và sau đó bạn phải bằng cách nào đó chỉ định phương thức nào sẽ được chạy như một phần của thử nghiệm.

#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();
}

Như bạn có thể thấy, lớp có một khối macro là phần tử đầu tiên. Nếu tôi đã thêm một phương thức mới testSubtraction, rõ ràng bạn cần phải làm gì để đưa nó vào trong quá trình chạy thử.

Các khối macro này mở rộng ra một cái gì đó như thế này:

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;
  }

Mà bạn thích đọc và duy trì?

Một ví dụ khác là trong khung Microsoft MFC, nơi bạn ánh xạ các chức năng thành các thông báo:

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( )

Vậy, những điều phân biệt "Macros tốt" với loại ác quỷ khủng khiếp là gì?

• Họ thực hiện một nhiệm vụ không thể đơn giản hóa bằng bất kỳ cách nào khác. Viết một macro để xác định tối đa giữa hai yếu tố là sai, bởi vì bạn có thể đạt được điều tương tự bằng cách sử dụng một phương thức mẫu. Nhưng có một số tác vụ phức tạp (ví dụ: ánh xạ mã thông báo đến các hàm thành viên) mà ngôn ngữ C ++ không xử lý một cách tao nhã.

• Họ có một cách sử dụng cực kỳ nghiêm ngặt, chính thức. Trong cả hai ví dụ này, các khối macro được thông báo bằng cách bắt đầu và kết thúc macro và phần giữa các macro sẽ chỉ xuất hiện bên trong các khối này. Bạn có C ++ bình thường, bạn xin phép một thời gian ngắn với một khối macro và sau đó bạn trở lại bình thường. Trong các ví dụ "macro ác", các macro nằm rải rác trong mã và người đọc không may không có cách nào biết khi nào các quy tắc C ++ được áp dụng và khi nào thì không.

Bằng mọi cách, sẽ tốt hơn nếu bạn điều chỉnh trình soạn thảo IDE / văn bản yêu thích của bạn để chèn đoạn mã bạn thấy mệt mỏi để gõ lại nhiều lần. Và tốt hơn là thuật ngữ "lịch sự" để so sánh. Trên thực tế, tôi không thể nghĩ về bất kỳ trường hợp tương tự nào khi tiền xử lý đánh bại các macro của trình soạn thảo. Chà, có thể là một - khi bởi một số lý do bí ẩn và không vui, bạn liên tục sử dụng các bộ công cụ khác nhau để mã hóa. Nhưng nó không phải là một lời biện minh :)

Nó cũng có thể là một giải pháp tốt hơn cho các kịch bản phức tạp hơn, khi tiền xử lý văn bản có thể làm những điều khó đọc và phức tạp hơn nhiều (hãy nghĩ về đầu vào tham số).

Những người khác đã giải thích lý do tại sao bạn không nên làm điều đó. Ví dụ của bạn rõ ràng không xứng đáng được thực hiện với một macro. Nhưng, có một loạt các trường hợp bạn phải sử dụng macro để dễ đọc.

Một ví dụ nổi tiếng về một ứng dụng khôn ngoan của một kỹ thuật như vậy là dự án Clang : xem cách .defcác tệp được sử dụng ở đó. Với các macro và #includebạn có thể cung cấp một định nghĩa khai báo đôi khi hoàn toàn cho một tập hợp những thứ tương tự sẽ không được kiểm soát thành các khai báo kiểu, các casecâu lệnh bất cứ khi nào thích hợp, các trình khởi tạo mặc định, v.v. Nó làm tăng đáng kể khả năng duy trì casebáo cáo ở khắp mọi nơi khi bạn đã thêm một enumví dụ mới.

Vì vậy, như với bất kỳ công cụ mạnh mẽ nào khác, bạn phải sử dụng C tiền xử lý một cách cẩn thận. Không có quy tắc chung trong nghệ thuật lập trình, như "bạn không bao giờ nên sử dụng cái này" hoặc "bạn luôn phải sử dụng cái đó". Tất cả các quy tắc không có gì ngoài hướng dẫn.

Không bao giờ thích hợp để sử dụng #defines như thế. Trong trường hợp của bạn, bạn có thể làm điều này:

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;
}

Không.

Đối với các macro dự định được sử dụng trong mã, một hướng dẫn tốt để kiểm tra sự phù hợp là bao quanh phần mở rộng của nó bằng dấu ngoặc đơn (cho biểu thức) hoặc dấu ngoặc (cho mã) và xem liệu nó có còn biên dịch không:

// 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;

Các macro được sử dụng trong các khai báo (như ví dụ trong câu trả lời của Andrew Shepherd) có thể thoát khỏi một bộ quy tắc lỏng lẻo miễn là chúng không làm đảo lộn bối cảnh xung quanh (ví dụ: chuyển đổi giữa publicvà private).

Đó là một điều hợp lý để làm trong một chương trình "C" thuần túy.

Nó là không cần thiết và khó hiểu trong một chương trình C ++.

Có nhiều cách để tránh việc gõ mã lặp đi lặp lại trong C ++. Từ việc sử dụng các tiện ích được cung cấp bởi IDE của bạn (ngay cả với vi "" đơn giản %s/ pspace /<< " " <</gsẽ tiết kiệm được nhiều thao tác gõ và vẫn tạo ra mã có thể đọc được tiêu chuẩn). Bạn có thể định nghĩa một phương thức riêng để thực hiện điều này hoặc đối với các trường hợp phức tạp hơn, mẫu C ++ sẽ sạch hơn và đơn giản hơn.

Trong C ++, điều này có thể được giải quyết với quá tải toán tử. Hoặc thậm chí một cái gì đó đơn giản như một hàm matrixdic:

lineWithSpaces(word1, word2, word3, ..., wordn)vừa đơn giản vừa giúp bạn tiết kiệm gõ pSpaceslại nhiều lần.

Vì vậy, trong trường hợp của bạn có vẻ như không phải là vấn đề lớn, có một giải pháp đơn giản và mạnh mẽ hơn.

Nói chung, có một vài trường hợp sử dụng macro ngắn hơn đáng kể mà không giới thiệu obfuscation và chủ yếu là một giải pháp đủ ngắn sử dụng các tính năng ngôn ngữ thực tế (macro chỉ là một sự thay thế chuỗi đơn thuần).

Có bất kỳ quan điểm nào về việc sử dụng #define để xác định các dòng mã đầy đủ để đơn giản hóa mã hóa là thực hành lập trình tốt hay xấu?

Vâng, nó rất tệ. Tôi thậm chí đã thấy những người làm điều này:

#define R return

để lưu gõ (những gì bạn đang cố gắng để đạt được).

Mã như vậy chỉ thuộc về những nơi như thế này .

Macro là xấu xa và chỉ nên được sử dụng khi bạn thực sự phải làm. Có một vài trường hợp áp dụng macro (chủ yếu là gỡ lỗi). Nhưng trong C ++ trong hầu hết các trường hợp, bạn có thể sử dụng các hàm nội tuyến thay thế.

Không, bạn không được phép sử dụng macro để lưu gõ .

Tuy nhiên, bạn được phép, thậm chí được yêu cầu sử dụng chúng để tách phần không thay đổi của mã khỏi thay đổi mã và giảm sự dư thừa. Sau này, bạn phải nghĩ đến các lựa chọn thay thế và chỉ chọn macro nếu các công cụ tốt hơn không hoạt động. (Đối với macro thực hành khá ở cuối dòng, do đó, nó có nghĩa là biện pháp cuối cùng ...)

Để giảm việc gõ hầu hết các trình soạn thảo đều có macro, thậm chí các đoạn mã thông minh.