Подозреваете ошибку в компиляторе? Проверьте получше свой код!

(В оригинале - Check Your Code First before Looking to Blame Others)

Все разработчики часто склонны не верить, что ошибка в их коде, обвиняя вместо этого, например, компилятор.

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

Один раз я сталкнулся с реальной ошибкой компилятора, неправильно оптимизировавшего цикл, однако я обвинял компилятор и операционку гораздо чаще. Я убил очень много времени на попытки доказать наличие ошибок в системе, и все лишь для того, чтобы в конце испытать неловкость, найдя ошибку в своем коде.

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

Взяв за основу то, что ошибки в компиляторах – очень большая редкость, вы сможете гораздо эффективнее тратить свое время на поиски ошибок у себя вместо попыток доказать, что виноват компилятор. Применяйте все обычные практики отладки: изолируйте проблему, отслеживайте вызовы, окружайте ее тестами, проверяйте соглашение о вызовах, общие библиотеки и версии, расскажите о проблеме кому-нибудь еще, проверьте переполнение и повреждение стека, запустите код на разных машинах и с разными конфигурациями сборки (debug и release).

Если кто-то заявляет о проблеме, которую вы не можете воспроизвести, то пойдите и посмотрите, как это у него получается. Возможно, он делает что-то, что вы не учли, или делает это каким-то другим способом.

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

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

Так что перед тем, как обвинить компилятор, вспомните правило Шерлока Холмса: «После того, как вы исключили невозможное, то все, что осталось, независимо от того, насколько невероятным оно выглядит, является истиной», и отдавайте предпочтение именно ему, а не правилу Дирка Джентли «Посл того, как вы исключили невероятное, все, что осталось, независимо от того, насколько невозможным оно выглядит, является истиной».

Автор оригинала - Allan Kelly