avl

Спустя много лет от начала моей программистской карьеры довелось погрузиться и в главное средство разработки микрософтовской платформы - visual studio. Достался в наследство проект, сопровождать и менять который теперь надо мне.

Понимаю, что описанная ниже ошибка - результат "хорошо" написанного проекта, но тем не менее user-friendly интерфейс от микрософта эта ошибка демонстрирует как нельзя лучше.

Итак, есть продукт, написанный на visual studio c++ 2005, в нем есть файл с ресурсами. При внесении изменений в этот файл и попытке сохранить его выдается сообщение "Cannot load external resource file". Вот так, дословно. Какой именно файл оно не может загрузить и чего это вдруг при нажатии на кнопку Save оно хочет чего-то грузить, я должен догадаться сам.

Но это еще не все. Несмотря на высокоинформативное окно, сохранение в этот раз все же происходит. А вот если еще раз поменять этот файл, то теперь при попытке его сохранить выдается уже ошибка "Cannot save file. (skipped).rc". О причине того, какого хера оно не может его сохранить, я опять же, должен догадываться.

А до тех пор, пока не догадался, приходится после каждого изменения файла с ресурсами закрывать visual studio и открывать его заново.

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

Вот такая вот дружелюбная платформа. Не Freescale Codewarrior конечно, но вполне в микрософтовском стиле :)

И да, порадовал еще способ, которым visual studio предлагает мне смотреть в дебаге массивы и области памяти. Спобоб этот единственный - в столбик по одному элементу. Неужели пишущим под винду никогда не надо видеть область памяти в старом добром hex режиме, по 16 байт в строке, разделенных пробелами, и адресом в начале строки?

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

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

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

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

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

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

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

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

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

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

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

Перевод мой, при использовании ссылка на мой живой журнал обязательна!

Афиша детского спектакля:



Да, если что, то словенское "sraka" - это всего лишь русское "сорока" :)

Взято у todash_tahken