Алексей Пахунов

Вопрос из комментариев:

Не могли бы прокомментировать ответ “Lepsik” по порядкам в Microsoft (тред):

автор – Диез

1, 2. Естественно, полтора – это величина условная. Просто большая длина обычно требует более одного движения для полного обзора

3. Никто не мешает сделать методы того же класса, но часто удобнее и логичнее разнести код на уровни, т.е. в отдельные классы (а то и в отдельные библиотеки).

Вообще, все это есть у Фаулера

это просто у вас программы маленькие.

в больших компаниях Microsoft/IBM/SONY, …. таких правил нет. У нас есть методы с телом в сотню экранов. А файл с методом тела процесса больше мегобайта.

За весь Microsoft не скажу. Расскажу, что видел сам.

Во-первых, такие правила, «coding guidelines», – есть. И они не сильно отличаются от тех образцов, что можно найти в Сети. Их специфика больше зависит от истории продукта или группы, ими пользующейся. Скажем, команды, так или иначе относящиеся к организации Microsoft Office, вполне ожидаемо используют схожие стили написания кода. Схожие, но не обязательно одинаковые. Единого, годного на все случаи жизни стандарта нет.

Во-вторых, ограничение на размер функции/метода носит все же рекомендательный характер. Существует масса причин, по которым существование длинных функций может быть оправдано. Скажем функции инициализации ядра, те которые инициализируют различные подсистемы, – длиннющие простыни. Их можно было бы разбить на функции поменьше размером. Логика там не очень сложная, хотя и далеко не линейная. Но это тянет на масштабный рефакторинг кода, преимущества которого не очевидны, а риск поломать что-либо весьма велик.

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

Не стоит забывать про генерируемый код. Автоматические генераторы не ведают про существование «coding guidelines». Ну и много чего ещё есть. Самое главное, что важность соблюдения разумных размеров функций стоит далеко не на первом месте. Куда важнее писать работающий и безопасный код.

Программирование, Microsoft