Давненько использовал в коде поиск по наименованию пользователя. В коде было настроено для одного пользователя, что ему приходит на почту разные данные по базе (были и важные данные). Этот пользователь уволился, но а код остался. Пришел новый пользователь с таким же наименованием. Так вот ему сразу стало приходить вся эта информация. Поэтому лучше не использовать поиск по наименованию.

Вспоминается... Я не сапер, поэтому ошибаюсь постоянно.
Вообще то типичная ошибка программистов - со знаками, в нотации 1С еще дебет/кредит, приход/расход.
На эту тему даже специальный анекдот есть
Физик, математик и программист спасаются от пожара на крыше высокого здания, внизу натянули тент. Первым прыгает физик, рассчитывает траекторию, чтобы гасить скорость, использует подручные средства для купола парашюта, спускается удачно. Вторым прыгает математик, замеряет скорость ветра, высоту здания, рассчитывает свою скорость, попадает точно в центр тента.
Программист думает - я что, хуже всех что ли. Замерил скорость ветра, рассчитал высоту здания, выбрал скорость, разбежался и с криком "Твою ...! Знак перепутал!!!" улетает в небо.
Но моя программистская ошибка которую я запомнил, не связана ни со знаками, ни с 1С вообще.
Писали мы приложение психологических тестов для ... госструктуры. У них отряды по 15 человек максимум. Поэтому уникальным ключом БД выбрали ФИО, это же логично.
Первый же оттестировавшийся был из Туркменистана, три Атабека Атабаевича Атабаева... из 10 человек л/с.
Понятно - у всех абсолютно одинаковый нордический характер получился.
Переписывали логику в поезде Санкт-Петербург-Москва, хорошо еще сапсанов тогда не было.

Однажды бился над очень скользкой ошибкой в незнакомой конфе, подходит начальник в хорошем настроении - да, я щас тут быстро тебе помогу, и через плечо набросал пару-тройку строк. В результате его код оказался под моими обрамляющими комментариями.
Выпускаем релиз, и в этом, наспех написаном коде, обнаруживается критическая ошибка. И, естественно, мне от этого же начальника перед всем коллективом влетело по самый понедельник))).
Я нисколько оправдываться не стал, т.к. это бумеранг добра))).

Сложно вспомнить ситуацию, которая связана непосредственно с кодом. Пропущенной точкой или запятой. Все запомнившиеся косяки были связаны с отсутствием актуального бекапа и порчей данных. Например, я узнал что SQL сервер может без проблем дропнуть таблицу в базе, где работают много пользователей. Надо было сделать копию базы без документов. Дропнул все DH, DT, _1SJourn и прочие таблицы, а потом понял, что сделал это в рабочей базе а не в копии. Ощущения просто непередаваемые.
Но больше всего мне запомнилась история "Как я познакомился с весовыми штрихкодами". Тогда я еще был эникеем на мясокомбинате. Торговая сеть Ашан дала под новый год заказ на 400 кг продукции и прислала требования снабдить продукцию штрихкодами по формату "27ххххх00000с": где ххххх - код товара, а с - контрольный символ. Ну я запрограммировал весы, распечатал этикетки, налепил на лист А4 и отослал им по факсу пример. Они ответили что все ОК. Ну мы и приступили к сборке заказа. Собирали до поздней ночи, пришлось заночевать в городе у знакомых, потому что домой добраться было нечем. А после выходых приезжают все 400 кг с претензией, что все штрихкоды показывают нулевой вес. Кто же знал, что вместо нулей должен отображаться вес товара. Зато я запомнил на всю жизнь что такое ВЕСОВОЙ ШТРИХКОД ТОВАРА.

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

1. После первого языка Borland Pascal 7.0 не ставил символ ";" перед оператором КонецЕсли" или закрытием цикла, жутко раздражает коллег) До сих пор иногда не ставлю)
2. Исходя из 1, начал ставить ";" везде, в том числе и после описания процедур и функций), платформа непонятно пишет ошибку, не поймешь в чем дело, но со временем привык.
Всех с Днем программиста!

студенческая лабораторная.
У нас с напарником сортировка не работает. Значениями переменных i,j играм 0 или 1. Ну не работает сортировка.
Поменяли у переменной i значение на 2 и заработало! Вот тут мы удивились, и задумались.

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

Уже тогда у меня была привычка, перед погружением в дебри отладки, прочитать бегло весь код, с целью поверхностной инспекции и общего понимания хода алгоритма. В ходе такого осмотра и зацепился глаз за очевидно ошибочную функцию, возвращающую очевидно неправильный результат в стиле 2+2=5. В итоге картина стала очевидной - функция возвращает значение, участвующее в формировании некоего коэффициента, который потом используется для расчетов. Мгновенно исправляю ошибку и довольный как бегемот докладываю о блистательной в стиле Цезаря победе.

Меня спасло тестирование... Тогда это было не так уже распространено, но алгоритм был важный и ошибки стоили дорого. После моей правки все расчеты за редкими исключениями перестали работать и выдавать невероятные результаты. Тогда я был готов потерять веру в законы физики и мироздания. Но причина была прозаичнее. В формировании итогового коэффициента участвовали несколько разных функций. И две из них содержали ошибки. Ошибки были такого плана, что взаимно компенсировали друг друга на подавляющем числе реальных данных. После моего исправления одной из ошибок, шаткое равновесие было нарушено и работать перестало вообще всё. После поимки и фикса второй ошибки, алгоритм стал работать как часы и по моим сведениям работает до сих пор без единой правки многие годы подряд.

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

Во времена студенческой юности писал я дипломную работу, тогда еще на 1с 7.7. Это было некое подобие "конвертации данных", только гораздо хуже (естественно), зато свое-родное. Тогда я еще про конвертацию не знал.
Данные переносились из самописной конфы 7.7 в типовую "Бухгалтерия госучереждения". База-приемник подключалась по OLE. На небольших объемах данных все работало быстро, но если количество проводок в операции достигало нескольких тысяч (отражение ЗП в учете за месяц по 300 сотрудникам) - наблюдалось экспоненциальное замедление работы - перенос мог занимать пару часов.
Тогда я не смог себе этого объяснить, и в работе написал "Наблюдаемое замедление связано с особенностями технологии OLE". Прокатило.
Позже, через несколько лет, зачем то открыл тот код, и обнаружил
//Создаем документ
Для а = 1 По Счетчик Цикл
///добавляем в него строки
Документ.Записать();
КонецЦикла;
Запись документа выполнялась внутри цикла.
Перенес строчку записи на 2 строки вниз и скорость работы даже для большого количества проводок больше никогда не превышала нескольких секунд.

Была как-то серьёзная ошибка по невнимательности...
В общем есть обработка, которая массово отправляет на почту клиентам акты сверки. Доработал я её значит, проверил на ОДНОМ контрагенте, - всё работает!
Сдаю заказчику, и он сразу поставил массовую рассылку на 200 контрагентов и в итоге вышло так, что ОДНОМУ контрагенту пришли все эти 200 писем, которые предназначались для разных контрагентов... И потом вдобавок почта заблокировалась за спам (на время)...
Денег за задачу разумеется не взял, было очень стыдно...
Вывод - тестировать нужно точно не на одном наборе данных=)

Ошибку, которую никогда не забуду допустил во сне. Приснилось, что простой код в проведении документа не работал. И ничего не мог сделать с этим кодом, пол ночи сидел в отладке. Проснулся в холодном поту.

Первая ошибка, которую никогда не забуду. Правил права в УПП, там где разделение по Контрагентам, Организациям, Подразделениям. Надо было добавить еще один разрез. Написал, проверил - поставил свои права, сохранил, открыл, все прочиталось. Катим на прод. Вы уже догадались? Неправильный отбор при записи в Регистр сведений! На следующее утро ответственный сотрудник устанавливает права по новому разрезу... и стирает все установки по разрезам Контрагенты, Организации и тд. Спасибо админам, поднимаем ночной бекап и через ВыгрузкуXML восстанавливаем настройки прав, а я пошел заниматься отладкой.

Вторая ошибка, которую я никогда никогда НИКОГДА не забуду. Была она в ЗУП... Есть там такой документ - Отпуск сотрудника. В нем заполняются два поля - год за который начисляется отпуск. И вот, в какой-то момент две даты стали меняться местами: т.е. вместо с 01.01.2006 по 31.12.2006 пишется с 31.12.2006 по 01.01.2006. На линии консультации ничего кроме как "Обновите до последнего релиза" не сказали. Обновили, а ошибка осталась... Кто-нибудь занимался отладкой ЗУП? Это бесконечный вызовы функций, в которые передается запрос наполняемый временными таблицами. А на выходе запроса - две даты. Я делал подход к этой ошибке около года, часов отладки наверно с месяц накопилось, но в чем была проблема так и не нашел((

Ошибки в коде конечно были, но это все рабочие моменты, которые сразу правятся, документы перепроводятся, отчеты переформируются)
И ничего особо критичного, за что увольняли бы, или рушились бы организации и цивилизации, не было)

Как хорошо, что я всегда делал бэкапы, никогда не форматировал диски с рабочими базами, и не запускал массовую правку данных без проверки и без возможности отката действий назад)

Один раз только помню что-то в середине дня в рабочей базе поправил "демоническим" обновлением, и в SQL испортилась таблица с конфигурацией БД, а в это время в этой далекой базе за 1000 км от меня работало около 150 человек... Конечно, первоначальный шок от этого не забыть, но все быстро поправили, последствий никаких не было, можно сказать даже почти никто и не заметил. Да и не совсем это моя ошибка была, скорее глюк платформы, который неудачно проявил себя в неподходящий момент. Динамическим обновлением пользоваться не перестал, и все равно больше таких случаев в практике не было, поэтому и он запомнился. Спасибо разработчикам платформы за исправление этой ошибки в последующих релизах)

Видимо мои эпичные ошибки, о которых стоило бы рассказывать коллегам и внукам, еще впереди)
А пока правлю свои мелкие ошибки и ошибки чужие - это тоже доставляет удовольствие)

Вспомнил одну очень интересную ошибку в коде. Совершил ее не я. Но мне выпала честь искать её и исправлять. 1С-ники в России скорее всего никогда с таким и не сталкивались. Внезапно (впрочем как всегда) в базе перестают правильно формироваться проводки документа. Причина непонятна. Есть рабочая база на сервере у клиента, но там ленивый админ не хотел поставить флаг -debug в реестре, и серверный код не отлаживался. Есть копия этой базы на нашем сервере. Конфигурации идентичные. Настройки в базе, права и все-такое тоже одинаковое. Да и не лазил туда никто. Там в расчете партий жуткий говнокод, шаткая конструкция из костылей, которую трогать страшно. Синдром "У меня все работает" в полный рост. На нашем серваке все правильно, у клиента - неправильно, но еще вчера было правильно. Как оказалось, накануне вечером админы обновляли платформу 1С. При установке подтянулись региональные настройки системы. Раньше конфигуратор был русский, а стал украинский. Вместо "Ложь" - "Хибність" например.
А в том самом жутком говнокоде оказались такие чудесные строки: