Конкретные функции против множества аргументов против зависимости от контекста

Я бы избегал вашего первого варианта, потому что, как вы говорите, количество функций, которые вам в конечном итоге придется реализовать (хотя, возможно, только в виде макросов), может выйти из-под контроля. Счетчик удваивается, когда вы решите добавить поддержку курсива, и снова удваивается для подчеркивания.

Я бы, наверное, тоже избегал второго варианта. Снова рассмотрим, что происходит, когда вы считаете необходимым добавить поддержку курсива или подчеркивания. Теперь вам нужно добавить в функцию еще один параметр, найти все случаи, когда вы вызывали функцию, и обновить эти вызовы. Короче говоря, раздражает, хотя, опять же, вы, вероятно, могли бы упростить процесс с помощью соответствующего использования макросов.

Остается третий вариант. На самом деле вы можете получить некоторые преимущества других альтернатив, используя битовые флаги. Например

#define WRITE_FORMAT_LEFT   1
#define WRITE_FORMAT_RIGHT  2
#define WRITE_FORMAT_CENTER 4
#define WRITE_FORMAT_BOLD   8
#define WRITE_FORMAT_ITALIC 16
....
write(char *string, unsigned int format)
{
  if (format & WRITE_FORMAT_LEFT)
  {
     // write left
  }

  ...
}

РЕДАКТИРОВАТЬ: Чтобы ответить Грегу С.

Я думаю, что самое большое улучшение заключается в том, что это означает, что если я решу на этом этапе добавить поддержку подчеркнутого текста, это займет два шага.

1. Добавьте #define WRITE_FORMAT_UNDERLINE 32 в заголовок
2. Добавьте поддержку подчеркивания в write().

В этот момент он может вызывать write(..., ... | WRITE_FORMAT_UNLDERINE) где угодно. Более того, мне не нужно изменять уже существующие вызовы для записи, что мне пришлось бы сделать, если бы я добавил параметр в его сигнатуру.

Другое потенциальное преимущество заключается в том, что он позволяет вам делать что-то вроде следующего:

#define WRITE_ALERT_FORMAT  (WRITE_FORMAT_CENTER | \
                             WRITE_FORMAT_BOLD |   \
                             WRITE_FORMAT_ITALIC)

Я предпочитаю аргументацию.

Потому что будет некоторый код, который необходимо использовать во всех различных сценариях. Создание функции из каждого сценария приведет к дублированию кода, что плохо.

Вместо того, чтобы использовать аргумент для каждого отдельного случая (toUpper, centered и т. д.), используйте структуру. Если вам нужно добавить больше случаев, вам нужно только изменить структуру:

typedef struct {
    int toUpper;
    int centered;
    // etc...
} cases;
write( char *str , cases c ){//..}

Я бы выбрал комбинацию методов 1 и 2.

Закодируйте метод (A), который имеет все аргументы, которые вам нужны/которые вы можете придумать прямо сейчас, и «голую» версию (B) без дополнительных аргументов. Эта версия может вызывать первый метод со значениями по умолчанию. Если ваш язык поддерживает это, добавьте аргументы по умолчанию. Я бы также рекомендовал вам использовать осмысленные имена для ваших аргументов и, по возможности, перечисления, а не магические числа или серию флагов true/false. Это значительно упростит чтение вашего кода и того, какие значения на самом деле передаются, без необходимости искать определение метода.

Это дает вам ограниченный набор методов для поддержки, и 90% ваших применений будут базовым методом.

Если вам нужно расширить функциональность позже, добавьте новый метод с новыми аргументами и измените (A), чтобы вызвать его. Возможно, вы захотите изменить (B), чтобы он также вызывал это, но это не обязательно.

Я несколько раз сталкивался именно с этой ситуацией - я предпочитаю не что-то из вышеперечисленного, а вместо этого использую один объект форматирования. Я могу предоставить ему количество аргументов, необходимых для указания определенного формата.

Одним из основных преимуществ этого является то, что я могу создавать объекты, определяющие логические форматы вместо физических форматов. Это позволяет, например, что-то вроде:

Format title = {upper_case, centered, bold};
Format body = {lower_case, left, normal};

write(title, "This is the title");
write(body, "This is some plain text");

Отделение логического формата от физического дает вам примерно те же возможности, что и таблица стилей. Если вы хотите изменить все свои заголовки с курсива на полужирный шрифт, изменить стиль текста с выравнивания по левому краю на полностью выравнивание по ширине и т. д., это становится относительно легко сделать. С вашим текущим кодом вы, вероятно, в конечном итоге просматриваете весь свой код и проверяете «вручную», чтобы выяснить, является ли конкретный строчный, выровненный по левому краю элемент основным текстом, который вы хотите переформатировать, или сноска, которую вы хотите оставить в покое...

Как вы уже упоминали, одним поразительным моментом является удобочитаемость: writeInUpperCaseAndCentered("Foobar!") гораздо легче понять, чем write("Foobar!", true, true), хотя вы можете устранить эту проблему, используя перечисления. С другой стороны, наличие аргументов позволяет избежать неудобных конструкций, таких как:

if(foo)
  writeInUpperCaseAndCentered("Foobar!");
else if(bar)
  writeInLowerCaseAndCentered("Foobar!");
else
 ...

По моему скромному мнению, это очень сильный аргумент (без каламбура) в пользу аргументации.

Я предлагаю более сплоченные функции, а не суперфункции, которые могут делать все, что угодно, если только суперфункция действительно не требуется (printf был бы довольно неудобным, если бы печатал только один тип за раз). Избыточность подписи, как правило, не следует рассматривать как избыточный код. С технической точки зрения это больше кода, но вы должны больше сосредоточиться на устранении логической избыточности в вашем коде. В результате получается код, который намного легче поддерживать, с очень кратким и четко определенным поведением. Думайте об этом как об идеале, когда кажется излишним писать/использовать несколько функций.