Чи правильно використовувати #define, щоб полегшити введення повторного коду?

Чи є думка про те, чи є використання #define для визначення повних рядків коду для спрощення кодування є хорошою чи поганою практикою програмування? Наприклад, якщо мені потрібно було друкувати купу слів разом, я би роздратований набравши текст

<< " " <<

Щоб вставити пробіл між словами в cout оператор. Я міг би просто зробити

#define pSpace << " " <<

і тип

cout << word1 pSpace word2 << endl;

Для мене це ні додає, ні віднімає ясності коду, а введення тексту трохи простіше. Є й інші випадки, які я можу придумати, де набрати текст буде набагато простіше, як правило, для налагодження.

Будь-які думки з цього приводу?

EDIT: Дякую за всі чудові відповіді! Це питання якраз прийшло до мене після багаторазового набору тексту, але я ніколи не думав, що будуть використовувати інші, менш заплутані макроси. Для тих, хто не хоче прочитати всі відповіді, найкращою альтернативою є використання макросів IDE для зменшення повторного введення тексту.

Написати код легко. Читання коду важко.

Ви пишете код один раз. Це живе роками, люди читають його сто разів.

Оптимізуйте код для читання, а не для письма.

Особисто я це ненавиджу. Існує ряд причин, чому я відштовхую людей від цієї методики:

1. Під час компіляції фактичні зміни коду можуть бути суттєвими. Наступний хлопець приходить і навіть включає фіксатор, що закриває, у свій #define або виклик функції. Те, що написано в певному коді, далеко не те, що буде там після попередньої обробки.

2. Це не читається. Вам може бути зрозуміло .. поки що .. якщо це лише одне визначення. Якщо це стане звичкою, незабаром ви закінчитеся з десятками #defines і почнете втрачати себе. Але найгірше, що ніхто більше не зможе зрозуміти, що word1 pSpace word2саме означає (не дивлячись на #define).

3. Це може стати проблемою для зовнішніх інструментів. Скажімо, ви якось закінчилися з #define, який включає в себе дужку закриття, але не відкриває дужку. Все може працювати добре, але редактори та інші інструменти можуть бачити щось на кшталт function(withSomeCoolDefine;досить своєрідного (тобто вони повідомлятимуть про помилки та інше). (Подібний приклад: виклик функції всередині визначення - чи зможуть ваші інструменти аналізу знайти цей виклик?)

4. Технічне обслуговування стає набагато складніше. У вас є всі ці функції, які визначаються, крім звичайних проблем, які підтримує технічне обслуговування. На додаток до вищезазначеного, на підтримку інструментів для рефакторингу також може негативно вплинути.

Моя головна думка з цього приводу полягає в тому, що я ніколи не використовую "полегшення введення тексту", як правило, під час написання коду.

Моє головне правило при написанні коду - це зробити його легко читабельним. Обґрунтуванням цього є просто те, що код читається на порядок більше, ніж він написаний. Таким чином, час, який ви втрачаєте писати ретельно, впорядковано, правильно викладено, насправді витрачається на подальше читання та розуміння набагато швидше.

Таким чином, #define, який ви використовуєте, просто порушує звичайний спосіб чергування <<та інших матеріалів . Це порушує правило про найменший сюрприз, і це не хороша річ.

Це питання дає наочний приклад того, як можна погано використовувати макроси. Щоб побачити інші приклади (і розважитись), дивіться це запитання .

Сказавши це, я наведу приклади реального світу того, що я вважаю гарним включенням макросів.

Перший приклад з'являється в 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 ++, ви ненадовго вибачитеся за допомогою блоку макросів, а потім знову повертаєтесь до норми. У прикладах "злих макросів" макроси розкидані по коду, і нещасний читач не може знати, коли застосовуються правила C ++, а коли - ні.

Буде, безумовно, краще, якщо ви налаштуєте улюблений редактор IDE / тексту для вставки фрагментів коду, який вам здасться втомленим знову і знову. І краще - "ввічливий" термін для порівняння. Насправді я не можу думати про якийсь подібний випадок, коли попередня обробка макросів редактора перемагає. Ну, може бути одне - коли з якихось загадкових і нещасних причин ви постійно використовуєте різний набір інструментів для кодування. Але це не виправдання :)

Це також може бути кращим рішенням для складніших сценаріїв, коли попередня обробка тексту може зробити набагато більш нечитабельною і складною (подумайте про параметризований ввід).

Інші вже пояснили, чому ви не повинні цього робити. Ваш приклад, очевидно, не заслуговує на реалізацію з макросом. Але, існує широкий спектр випадків, коли вам доводиться використовувати макроси заради читабельності.

Сумно відомий приклад розумного застосування такої методики - проект Clang : подивіться, як .defтам використовуються файли. За допомогою макросів #includeви можете надати єдине, іноді цілком декларативне визначення для колекції подібних речей, які будуть розгорнуті в декларації типів, caseзаяви, коли це доречно, ініціалізатори за замовчуванням тощо. Це значно збільшує ремонтопридатність: ви ніколи не забудете додати нові caseтвердження скрізь, коли ви додали нове enum, наприклад.

Отже, як і будь-який інший потужний інструмент, ви повинні ретельно використовувати C-препроцесор. У мистецтві програмування немає загальних правил, наприклад "ти ніколи не повинен цим користуватися" або "ти завжди повинен цим користуватися". Усі правила - це не що інше, як настанови.

Ніколи не доречно використовувати #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;

Макроси, які використовуються в деклараціях (як, наприклад, у відповіді Ендрю Шеперд), можуть уникнути більш нещільного набору правил, якщо вони не порушують навколишній контекст (наприклад, перемикання між publicі private).

Це досить обгрунтована справа в чистому "С" програмі.

Це зайве і заплутане в програмі C ++.

Існує багато способів уникнути повторного введення коду в C ++. Якщо використовувати засоби, надані вашим IDE (навіть при vi простому " %s/ pspace /<< " " <</g", ви врятуєте стільки ж набравши текст, тим не менш виробляєте стандартний читабельний код). Ви можете визначити приватні методи для реалізації цього або для більш складних випадків шаблон C ++ був би більш чистим і простим.

У C ++ це можна вирішити за допомогою перевантаження оператора. Або навіть щось таке просте, як різноманітна функція:

lineWithSpaces(word1, word2, word3, ..., wordn)це одночасно просто і дозволяє економити вас pSpacesзнову і знову.

Тож, хоча у вашому випадку це не може здатися великою справою, є рішення, яке є більш простим і надійним.

Загалом, мало випадків, коли використання макросу значно коротше без введення обфускування, і в основному існує досить коротке рішення з використанням фактичних мовних особливостей (макроси є більш простою підстановкою рядків).

Чи є думка про те, чи є використання #define для визначення повних рядків коду для спрощення кодування є хорошою чи поганою практикою програмування?

Так, це дуже погано. Я навіть бачив людей, що роблять це:

#define R return

щоб зберегти введення тексту (чого ви намагаєтесь досягти).

Такий код належить тільки в таких місцях , як це .

Макроси є злими і їх слід використовувати лише тоді, коли вам це справді доведеться. Є кілька випадків, коли макроси застосовні (в основному налагодження). Але в C ++ у більшості випадків можна використовувати замість них вбудовані функції.

Ні, вам не дозволяється використовувати макроси для збереження набору тексту .

Однак вам дозволено, навіть вимагати їх використовувати для відділення незмінної частини коду від змінної та зменшення надмірності. Для останнього ви повинні продумати альтернативи та вибрати макрос, лише якщо кращі інструменти не працюють. (Для практики макрос знаходиться в кінці рядка, тому його наявність передбачає крайню можливість ...)

Для зменшення набору тексту більшість редакторів мають макроси, навіть інтелектуальні фрагменти коду.