IDE против опечаток в коде

Только что коллега подошёл с болью в лице и слезами на глазах сказал: ВСЁ ДЕНЬ. ВСЁ ДЕНЬ УЧИЛ, ВЫКИНУТЬ ИЗ-ЗА ОПЕЧАТКИ В ПЕРЕМЕННОЙ А ЧЁ IDE уже не масло использовать? Я думаю IDE C++ только помогает, если компилятор и статический анализ не помогает? (Реально ничего не помогает, кроме внимательной отладки и вычитки) Конечно поможет. Он будет обосрать переменные с опечаткой как “не объявленная” или будет подсвечивать не с опечаткой как “нигде не используется” Я обычно содержимое, но ты, конечно, долбоёб Перестраховщик. За то я работаю в IDE от JetBrains, а ты разу не согласился с тем, что именно сэкономили или не использование переменную не подсветило красным/синим. Даже в сложных проектах на фреймворках с кучей импортов/модулей все ок. Сейчас цитировал код лишь «на колене», в ноутпад++, емакс, vim или прочих домашних редакторах: переменная приходит импортом из другого файла/библиотеки/модуля и используется в функции, которая вызывается в рантайме (компилятор используется) Но профессионально IDE не пропускает. Перефразируй: какого хуя у вас IDE умнее компилятора и статического анализатора? Какими уровнями предупреждений вы пользуетесь? Допустим проект настроен никак локально, но почему это пропустил C#? Где должны быть настроены все проверки? Чтобы окончательно прояснить ситуацию: сам попадал пару раз на поиск такой переменной, и обычно это случаи, где обе переменные и объявлены, и используются. Я использую IDE (в разное время MSVS или QtC) и максимальный уровень предупреждений, и что-то это не помогает.

Скриншот длинной перепалки программистов в Twitter о том, может ли IDE заметить опечатку в имени переменной, если компилятор и статический анализатор её пропустили. Шутка строится на чрезмерно уверенном споре, оскорблениях и столкновении практического опыта с теоретической верой в инструменты разработки. EN: A screenshot of a long Twitter argument between programmers about whether an IDE can catch a typo in a variable name when the compiler and static analyzer miss it. The joke comes from the overly confident debate, insults, and clash between practical experience and theoretical faith in development tools.

• @ithueti / 1147 2019-08-09