Здравствуйте, VladD2, Вы писали:

VD>Зачем ты навставлял проверок такого вида:
VD>

VD>if (String.IsNullOrEmpty(filePath))
VD>{
VD>    return false;
VD>}
VD>...
VD>            if (request == null)
VD>{
VD>    return;
VD>}
VD>

VD>?

VD>Там действительно приходил null и пустая строка? Если, да, то неужели это нормальное поведение этих методов?

В некоторых случаях там действительно может прийти null. Может прийти и пустая строка. Use-case сценарий приводить не буду, но пару раз ловил исключения при тестировании. Проверки я ставил только там, где есть смысл.

VD>Если на оба последних вопроса ответ отрицательный, и этот код создан для чистоты, так сказать, то будь добр, замени его на генерацию исключений ArgumentNullException/ArgumentException.

Хм, может лучше ассерты?

VD>Сразу объясняю почему так нельзя делать. Рано или поздно кто-то может ошибиться и случаяно передать в такой метод null или пустую строку. Наличие исключения или даже просто отсуствие проверки параметров приведет к тому, что мы увидим эту ошибку. А вот возврат null-ов и т.п. приведет к появлению исключений в совсем дургм месте или просто замажет ошибку (будет некорректное поведение о котором никто не будет знать).

Если разработчик точно уверен, что в этом методе не придет null, тогда он ставит Debug.Assert. Я так глубоко не копал, чтобы точно знать, какие данные передаются в методы. Поиск по вызывающим функциям показал, что вполне могут приходить некорректные строки. Возврат null-а я вообще нигде не делаю, и больно бью по рукам своих сотрудников если они так делают.

VD>Да, ив if-ов с одним выражением внутри не стоит ставить скобки. Они соврешенно лишние. Только место занимают. Отбивки достаточно.

Ага, и в итоге блок if-a вообще становится незаметным в общем объеме кода. Странно, почему вы тогда не используете форматирование K&R (фигурная скобка ставится в конце строки) — ведь это еще больше места экономит? С другой стороны, если так сильно хочется, то не буду занимать места — как скажешь, так и буду делать.

P.S. Все-таки не понимаю, к чему придирки к проверкам? Сами же сказали, что код находится на еще очень ранней стадии. Я отловил пару раз NullReferenceException и поставил проверки. Я еще не настолько разобрался в проекте, чтобы знать корень этого null-а, и поставил проверки, чтобы просто студия не вываливалась. Предложи мне другую стратегию разработки, и тогда я не буду так делать.