Использует плохую практику

Использование параметра out в методе void обычно является плохой идеей. Вы говорите, что использовали его «вместо того, чтобы заставить сам метод возвращать false/true, поскольку это означало бы, что DoSomething не удалось/удалось» - я не верю, что это подразумевается. Обычно в .NET сбой указывается через исключение, а не через true/false.

out параметры, как правило, более уродливы в использовании, чем возвращаемые значения - в частности, у вас должна быть переменная правильного типа для обработки, поэтому вы не можете просто написать:

if (DoSomething(...))
{
   // Warn user here
}

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

public enum WarningLevel
{
    NoWarningRequired,
    WarnUser
}

Тогда метод мог бы вернуть WarningLevel вместо bool. Это прояснит, что вы имели в виду, хотя вы, возможно, захотите немного переименовать вещи. (Трудно давать советы с метасинтаксическими именами, такими как «DoSomething», хотя я полностью понимаю, почему вы использовали это здесь.)

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

out очень полезная конструкция, в частности в таких шаблонах, как bool TryGetFoo(..., out value), где вы хотите знать "если" и "что" по отдельности (и значение NULL не является обязательно вариант).

Однако - в таком случае, почему бы просто не сделать это:

public bool DoSomething(int id, string input);

и использовать возвращаемое значение, чтобы сигнализировать об этом?

Несколько дополнительных мыслей:

• Что говорит FxCop: CA1021: Избегайте внешних параметров

• Для приватных/внутренних методов (детали реализации) параметры out/ref не представляют особой проблемы.

• Кортежи C# 7 часто являются лучшей альтернативой out параметрам

• Кроме того, C# 7 улучшает обработку out параметра на сайте вызова, вводя "выходные переменные" и позволяя "отбрасывать" out параметры

Учитывая большой устаревший метод кода (скажем, 15+ строк, устаревшие методы кода с 200+ строками довольно распространены), можно использовать рефакторинг «метод извлечения», чтобы очистить и сделать код менее хрупким и более удобным в сопровождении.

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

Лично я использую это обстоятельство для сильного индикатора того, что в предыдущем методе был спрятан один или несколько дискретных классов, поэтому я могу использовать «Извлечь класс», где в новом классе эти выходные параметры получают свойства, видимые вызывающему ( предыдущий) метод.

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

Итак, в таком сценарии выходные параметры, на мой взгляд, являются нарушением SRP с запахом кода.

Это действительно сложный вопрос, на который невозможно ответить, не зная контекста.

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

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

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

public class MyWarningException : Exception() {}

...

try
{ 
     obj.DoSomething(id,input);
}
catch (MyWarningException ex)
{
     // do stuff
}

Идея заключалась бы в том, что исключение возникает в конце реализации DoSomething, чтобы поток не останавливался в середине.

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

public void DoSomething(int id, string input, Action warnUser);

Вы можете передать пустую лямду, где вы не хотите отображать предупреждения пользователю.