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

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

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

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

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

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

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

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

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

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

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

Автор оригинала - [Allan Kelly](http://programmer.97things.oreilly.com/wiki/index.php/Allan_Kelly)


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://97-things-every-x-should-know.gitbook.io/97-things-every-programmer-should-know/ru/thing_61.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.