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

N>В вашей реплике есть принципиальная ошибка и подтасовка

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

А вообще, тезис в том, что (ИМХО) не надо на компиляцию возлагать больших надежд, связанных с проверкой корректности функционирования программы. Что может проверить компилятор? Соответствие грамматике и т.п. К правильному функционированию это имеет оооооочень опосредованное отношение. Чекеры это уже лучше, это уже тесты, хоть и чисто модульные. А основные выводы о готовности к проду надо делать по результатам интеграционных.

А поскольку я сторонник подхода, что если что-то работает ненадёжно, то и использовать это не надо (идея та же, по которой люди запрещают security through obscurity), я считаю, что не стоит использовать все эти a: int 1..100 ни для чего, кроме как для декларации о намерениях (а вот для этого — надо).

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

N>В вашей реплике есть принципиальная ошибка и подтасовка

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

А вообще, тезис в том, что (ИМХО) не надо на компиляцию возлагать больших надежд, связанных с проверкой корректности функционирования программы. Что может проверить компилятор? Соответствие грамматике и т.п. К правильному функционированию это имеет оооооочень опосредованное отношение. Чекеры это уже лучше, это уже тесты, хоть и чисто модульные. А основные выводы о готовности к проду надо делать по результатам интеграционных.

А поскольку я сторонник подхода, что если что-то работает ненадёжно, то и использовать это не надо (идея та же, по которой люди запрещают security through obscurity), я считаю, что не стоит использовать все эти a: int 1..100 ни для чего, кроме как для декларации о намерениях (а вот для этого — надо). По сути, можно в имени или комментарии то же написать, но просто менее удобно.