История №983082
- Такой ужасный программист работал у нас. Сначала вроде всё нормально было, а как уволился и наняли замену, так выяснилось, что он там всё так запутанно наделал, что одному не распутать, пришлось ещё двух нанимать. Но до сих пор то одно не работает, то другое... Не повезло нам с тем программистом!
Имеется вопрос - программист уволился после того, ка ему отказали в повышении зарплаты?
Mike Rotchburnz• 27.11.18 19:02
Фрагмент кода данного специалиста:
if (a)
if (b) x = y; /* присвоить переменной х значение переменной у */
else x = z;
ystervark➦Mike Rotchburnz• 27.11.18 20:28
Да ну. Вы шутите. Утрируете. Если правда, то кто же такое написал?
Между прочим, многие ли здесь в точности укажут, что именно в каких случаях делает этот код?
Mike Rotchburnz➦ystervark• 27.11.18 20:35
В том то и секс, такой код может «работать», no maintainability очень низкая.
Pivo Vodkin ★➦Mike Rotchburnz• 27.11.18 20:42
А тут ничо не пропущено? Что означает "иф(а)"?
Может, так:
if a=5
if b=10
x=y
else
x=z
endif
endif
Pivo Vodkin ★➦ystervark• 27.11.18 20:46
Я предположу, что a и b - какие-то условия.
Тогда код проверяет, выполнено ли условие а. Если не выполнено, пропускает этот отрывок и идёт дальше. Если же выполнено, то проверяет, выполнено ли условие b. Если выполнено, присваивает x значение y, если не выполнено, присваивает x значение z.
ystervark➦Mike Rotchburnz• 27.11.18 20:47
но тут, например, в случае !a переменной x не присваивается вообще ничего. Хорошо, если она проинициализирована чем-то, а если нет?
(я вот как раз сегодня имел дело с неинициализированной переменной в коде от вполне уважаемого поставщика; а видно это по дампу памяти и регистров в момент рахвала, когда в регистре, где должно ыть малое целое числоо, отчетливо виден адрес чего-то в стеке).
Mike Rotchburnz➦ystervark• 27.11.18 21:17
Очевидно сразу несколько проблем с подобным кодом, именно потому, что непонятно, что именно он делает с функциональной точки зрения:
1. Названия переменных должны быть такими, чтобы не возникало вопросов, что это.
Например if (isInitialized) ...
2. Во избежание ошибок, надо обязательно использовать фигурные скобки после if - выражения, хотя это и не всегда обязательно.
3. Комментарии не должны описывать то, что делает язык программирования. Они должны описывать, что тут делается с точки зрения фунциональности, и только тогда, когда это и так не ясно из названия переменных и методов.
ystervark➦Mike Rotchburnz• 27.11.18 22:27
Ну да, все так и есть. В идеале комментарий вообще должен быть не нужен (кроме всяких там жабадоков). А там, где он нужен, он должен описывать скорее даже не что делается, а почему. Типа, "Массив к этому моменту отсортирован, поэтому тут мы можем применить двоичный поиск". Или "Массив тут отсортирован, но очень мал, поэтому двоичный поиск применять мы не будем". Или даже так: "Этот массив нам впоследствии будет нужен отсортированным, однако, мы отсортируем его сейчас, потому что все равно ждем завершения операции ввода-вывода".
Ну а фигурные скобки это недостаток языка C, идущий еще от Алгола-60. Надо отнестись с пониманием и уважением к седой древности. Практически во всех новых языках этот вопрос тем или иным образом решен. Могли бы решить уже и в джаве, мне до сих пор непонятно, почему этого не сделали. Видимо, какие-то маркетинговые соображения.
Dmitry Karpov ★➦ystervark• 27.11.18 22:32
На Хабре есть блог компании - её программа такие вещи отслеживает.
Grok➦Mike Rotchburnz• 27.11.18 22:52
// nested if-statement
https://en.cppreference.com/w/cpp/language/if
Serge712➦Pivo Vodkin• 27.11.18 23:04
В обоих случаях должен каждый вложенный if должен иметь отступ, чтобы было легче отслеживать, где какой if заканчивается. Тривиальные комментарии писать не надо. И код надо писать короче:
if(a) x=z;
if(a && b) x=y;
ystervark➦Dmitry Karpov• 27.11.18 23:29
Да таких продуктов довольно много. Некоторые из них, бывало, оказывались очень полезны. Собственно, рудиментарная (слишком, пожалуй, грубая) проверка инициализации для скаларных переменных просто встроена в жабо-компилятор.
Прноблема с этим всем одна. Общая проблема проверки корректности программы во всех практических смыслах алгоритмически неразрешима. Это значит, что все подобнгые программы неизбежно производят безопасное замыкание. А это значит, потенциально выдают много мусора, то есть реально неактуальных замечаний. Миримся с этим, поскольку даже одно замечание по делу - всегда полезно.
ystervark➦Serge712• 27.11.18 23:34
отступ вещь, вообще, полезная, но его самого по себе недостаточно. Он может быть обманчив. Либо надо, чтобы отступ сопровождался обязательными аналогами фигурных скобок (как в Модуле-2), либо чтобы сам был синтаксическим элементом (как в Питоне), либо чтобы какие-то стандартные средства его проверяли (как в Го). Из этих трех вариантов я за первый.
ystervark➦Mike Rotchburnz• 27.11.18 23:38
Но вообще, все это мелочи. Требовать такие вещи от программиста - это как требовать от лыжника, чтобы умел ходить коньковым ходом. Или от футболиста, чтобы держал мяч обеими руками, когда выбрасывает из-за боковой. Обычно проблемы с плохо написанными программами более глубокие и не так легко формализируемые.
Serge712➦ystervark• 27.11.18 23:47
Чем фигурные скобки помогут? Идет нагромождение скобок, несколько вложений и проследить какая закрытая к какой открытой относится уже не просто. Надо просто писать комментарии типа "это конец операции if(a) ..."
ystervark➦Serge712• 28.11.18 00:02
А чем отступы помогут, если не соответствуют реальному положению дел? Только сделают хуже - создадут ненужную иллюзию.
Я такое видел неоднократно:
if (условие)
<отспуп> оператор
потом кто-то редактирует:
if (условие)
<отспуп> оператор1
<отспуп> оператор2
Так что скобки это не прихоть, за этим практический опыт.
Кстати, средства форматирования текста позволяют по скобкам сделать отступы. А вот по отступам скобки - нет.
Арсений ★➦Serge712• 28.11.18 00:07
"В обоих случаях должен каждый вложенный if должен иметь отступ" - Серж, рекомендую: питончег :) Прекрасный язык, воплощающий принцип "этот самолет не полетит - он некрасивый". Отступы выполняют роль begin-end (ну или {}) и если блок команд неправильно отформатирован - прога тупо не исполнится.
Читать питонский код - одно удовольствие :)
anddestr➦Mike Rotchburnz• 28.11.18 11:21
Хотелось бы увидеть хотя бы функцию в которой такое написано.... а так, на мой взгляд - вырвано из контекста и понять корректно код работает или нет нереально. Ниже писали, что если первый иф не сработал, то не x - может быть непонятно каким. Может. А может быть и другая ситуация: Возможно х изначально равен 5, и текущий фрагмент кода либо его изменит либо оставит "старым".
Конечно можно посудачить о том что нет скобок, что переменный названы просто "х","у","z" и много еще о чем, что касается стиля программирования конкретной особы. Но есть и вероятность того, что автор передавая нам кусочек кода сам некоторые вещи упростил... Названия переменных состоящие из одной буквы я встречал только у студентов и школьников. В более менее сложных программах, что бы 5 переменных были в одну букву? да еще в одном куске кода? верится слабо. Но возможно я ошибаюсь...
ystervark➦anddestr• 28.11.18 15:27
Я так понял, что автор все же не взял это из готовой программы, а выдумал этот кусочек из головы, чтобы продемонстрировать три распространенные стилистические ошибки: невыразительные переменные, пренебрежение фигурными скобками и отступами, и бесполезные комментарии. Понятно, что в реальной жизни все это сразу не встречается. А по отдельности сколько угодно.
Что касается скобок, то тут вот какое дело. Если спросить десять человек, с каким именно оператором if ассоциируется else, то половина скажет, что с ближайшим, а половина скажет - ХЗ. Хочется надеяться, что автор кода принадлежал к первой половине, а вдруг нет? Вдруг указанная трактовка (если а ложно, оставить x как есть) - это не то, чего он изначально хотел? А расставленные скобки сделали бы его замысел однозначным.
К слову, однобуквенные переменные вполне часто употребляются. Например, индексы i, j, k, или указатели p и q. Чтобы условия назывались a и b, это, конечно, более редкий случай.
anddestr➦ystervark• 28.11.18 15:52
Всегда считаю, что лучше использовать лишнюю строчку/символ (поставить скобку, написать case else, сделать отступы и т.п.) если это улучшит чтение программы, уберет возможные неоднозначности и т.п. Это помогает особенно если надо вносить изменения в код через год-два :)
Касательно названий переменных - это вообще вопрос очень спорный. Если программер один на предприятии, то это его личное как писать. Кто-то Венгерскую нотацию использует, а кто-то свои нормы вводит. Если есть программистская контора - то тут могут свои правила придумать. Я вообще люблю писать idxI, idxJ и т.п. Вот не люблю односимвольных переменных.
Ну а придумывать свой пример, что бы "обхаять" другого - считаю это не корректным. Хочешь показать какой человек "криворукий" - покажи реальный кусок "криворукости". А тот так складывается неверное впечатление: работал 1 "криворукий" и у него все работало. Заменили на 2-х пряморуких и у них постоянные лажи. Конечно. В такой ситуации виноват предыдущий программист. :)
ystervark➦anddestr• 28.11.18 16:32
Ну все же странно было бы публиковать в обсуждении анекдота кусок чьего-то реального кода. Тем более, что вряд ли удастся вычленить одну-две характерные строки.
Компании обычно имеют какие-то стандарты форматирования, иногда жестко соблюдаемые, иногда помягче, но в общем проблема со скобками и именами переменных обычно как-то решается. Тогда плохие программы получаются другими способами. А способов этих масса.
anddestr➦ystervark• 28.11.18 16:40
Можно было словами написать: код не отформатирован, открывающие/завершающие операторные скобки не ставятся, наименования переменных не функциональны, переменные не иницилизируются и т.п. Зачем придумывать?
Я так понял, что автор ведет разговор не о софтверной компании, а про обычную торговую/производственную контору, где сидел парень и на чем-то писал программы для нужд конторы. Контора явно небольшая потому как он был один.
Во всех других случаях, когда программистов больше одного - рано или поздно у них возникает вопрос о "чистоте и правильности" кода. И основные ошибки убираются. Или меняются программисты )
andy➦Mike Rotchburnz• 28.11.18 23:14
Э, то вы не видели кода одного, мать его, гения из нашей шараги. Слов нет, чувак за месяц написал кусок функционала, какой планировали писать целой командой полгода. ЧСХ, оно даже как-то работало, хотя, конечно, не без багов, но то дело поправимое, казалось бы.
Вот только вскоре этот гений гордо свалил в закат, оставив разгребать код в духе for (++a->b+=**c;d[(E)f--]->g();(**h++)->--i,*j-=k[**l++]);
А вообще-то это про программистов история? А то, может, тут иносказание, и первый программист это Ельцин, а ему на смену наняли Путина и Медведева. А как эти уволятся, тут и четырех не хватит.
Совершенно непонятно, где тут смеяться.
Описанная ситуация может, с неравными вероятностями, иметь три объяснения:
1) первый программист был долбоеб и код написаг через жопу, вот он и непонятен
2) (более мягкий вариант 1): первый программист был нормальный, но не гениальный, а кусок кода - древний. Его ни разу не переписывали с нуля, а за время жизни он превратился в спагетти. Такое бывает практически у всех, и избежать этого очень трудно. Мало быть хорошим спецом, надо еще и чтобы возможность переписать и отрефакторить была.
3) первый программист невероятно крут, а код его сложен просто по причине естественной сложности задачи. Соответственно, обычным людям его понять крайне трудно. Такое бывает - для примера можно посмотреть на некоторые места кода JDK, на стандартную библиотеку C++ (например, в GCC), да и на сам GCC.
А не равны вероятности от того, что в условиях типичной прикладной конторы вариант 3 встречается крайне редко. И крутованов нет, и задач невероятной сложности тоже нет. Я бы оценил вероятности вариантов где-то в 40-55-5, иными словами, уважаемый адекватный человек, скорее всего, прав.
васька ★★➦ystervark• 27.11.18 20:15
"отрефакторить" - это сильно. Наверное, от слова "fuck".
Pivo Vodkin ★➦ystervark• 27.11.18 20:48
4) программист увольнялся "не по-хорошему" и имел время напакостить.
ystervark➦Pivo Vodkin• 27.11.18 21:03
Маловероятно, по двум причинам. Во-первых, обычно программисты не склонны такое делать, даже если и могут: ну это как писателю нарочно напиисать плохую книгу. Случайно - сколько угодно, по криворукости - пожалуйста, даже по замыслу (например, пародия) - сколько угодно. Специально плохую - нет.
Ну а во-вторых, код же хранится не только на личном компьютере программиста. Даже если в компании нет системы контроля версий (что само по себе почти невероятно), есть общие бэкапы, а также отдельно сложенный в сторонку копии исходников всех релизов.
anddestr➦ystervark• 28.11.18 15:59
Согласен. Второй вариант наиболее частый. И чаще всего возможности переписать и сделать рефакторинг - отсутствует - банально нету времени, потому как только с программой работает не один отдел, а хотя бы 3-4 - список "пожеланий" растет гораздо быстрее чем его можно реализовать. Тут очень подходит пословица "Аппетит приходит во время еды".
"Не повезло нам с тем программистом!"
Правильно тот человек сказал (несмотря на авторские намёки на неадекватность). Специалисты делятся на два вида: те, после кого хоть потоп, и те, кому не всё равно, что останется после него. Специалисты первого вида могут быть даже очень квалифицированными, но это ничего не меняет в их типовом поведении.
Dmitry Karpov ★➦ntktw• 27.11.18 22:34
Смотря как его увольняли - по хорошему или со скандалом.
ystervark➦Dmitry Karpov• 27.11.18 23:45
И если со скандалом, то что? Нет, если чувак готовится к этому за два года, он может заранее на все положить. Но человек, который два года на все кладет, и называется "плохой программист". А за один день что он может сделать?
Dmitry Karpov ★➦ystervark• 28.11.18 22:02
А зачем тратить силы на то, что этому человеку не принесёт пользы? У него в должностных обязанностях не было прописано "делать код легко читаемым" - а если бы было, то это немного совсем другие деньги.
ystervark➦Dmitry Karpov• 28.11.18 22:21
Ну это возвратит нас прямиком в дискуссию о малярах, которые могли сделать плохо, а за особые деньги - хорошо. Тут речь об элементарном стандарте качества. Когда вы нанимаете мужика вскопать вам огород, вы же не пишете в должностной инструкции "копать на полный штык". Это само собой разумеется.
Знаете, стандарты качества в современном программировании и так достаточно низки, чтобы их еще искусственно занижать.
Кроме того, мы же не знаем, сколько получал тот программист, и сколько - другие два.
Бывает. Работал я с одним мужиком, так у него при разработке электронной схемы обычно получался такой же "спагетти-код". То есть, нужна дополнительная функция - бросается дополнительная связь через всю схему. А так как руки у него росли из жопы, мне приходилось собирать макеты. Включаешь, а оно не работает и по частям наладить невозможно. Программисты меня поймут. Начинается возмущённое фырканье, мол, ДОЛЖНО РАБОТАТЬ. Ну так запусти схему, ты же разработчик. Не может. Вместо этого встаёт во всякие гордые позы. Но при этом такие люди умеют создать у начальства впечатление, что они крутые специалисты.
Mike Rotchburnz• 27.11.18 16:23
Есть такое понятие - job security. Не нашёл русского перевода в Википедии, но означает это уровень уверенности в том, что тебя не уволят. Все хотят повысить этот уровень для себя, но каким путём? Для программиста - точно не путем написания так называемого «spaghetti code”, то есть кода без четкой структуры, который трудно поддерживать и исправлять.
Надо понимать, что в современном программировании понятие «работает» - только одно из требований.
Современные работающие системы огромны и написаны десятками или даже сотнями программистов, при этом их контингент время от времени меняется. Поэтому важно, чтобы вся команда придерживалась единого, документированного стиля, разработанного архитекторами. Тогда не будет проблем, если один из программистов уйдёт.
Это как собор Святого Семейства в Барселоне, до сих пор строящийся по чертежам давно умершего Антонио Гауди.
Наличие подобных проблем в компании - признак того, что работа там не организована серьезно. В серьезной организации вероятность написания такого кода мала, так как прежде чем код попадёт в source control depository (опять не знаю, как перевести) - он проверяется другими программистами компании и они как бы ставят свою подпись (электронно), что с ним все нормально.
Арсений ★➦Mike Rotchburnz• 28.11.18 00:16
Майк, твоё описание подходит здоровенной фирме-разработчику, тут же скорей всего речь идёт о маленькой конторе, в которой сначала был целый один программист, а теперь - в два раза больше! Может он вообще макросы писал для экселя... Люди посторонние зачастую программистами считают всех, кто работает с компами (а раньше называли вообще - "компьютерщики").
Двадцатилетним программистам наверно смешно, но оценка работничка скорее всего адекватна. Смотря какие показатели качества приняты в работе. Например понятность системы (discoverability) и сопротивляемость изменениям, насколько поддерживаема система. Т.е. допустим чел нагородил недокументированных костылей и при нем все работало, но фактически результаты работы были завязаны на одного человека. Без пол литра не разберешься и новых функций не добавить.
очень полезно уволиться с работы, чтобы вкусили все прелести жизни. Иногда единственный способ убедить ценить имеющихся сотрудников - вынудить платить двоим после тебя.
yizraor➦Bahruz• 27.11.18 19:32
понимаю, сам недавно сменил место работы из-за паскудности начальства...
правда, в воспитательный эффект подобного ухода не верю - у них же цель не "сделать работу хорошо" (или "добиться наилучших результатов" и т.д. и т.п.), а тупо "хапнуть побольше в карман" :)
Dmitry Karpov ★➦yizraor• 27.11.18 22:35
Ну так зарплата двух программистов - снижает количество хапнутого.
yizraor➦Dmitry Karpov• 27.11.18 23:38
Наоборот :)
Если брать двоих заместо одного, то это же шоколадненько! Выбивается у вышестоящего начальства дополнительная штатная единица. Для данной "единицы" (когда работник на это место найдётся) надо же и денег добавить в фонд зарплаты, от щедрот предприятия. Ну а уж фонд начальством распиливается на себя и коллектив в желаемых (начальством) пропорциях
Ящер12 ★➦Chicago95• 27.11.18 19:44
Сам не видел, но один электрик рассказывал, как пришёл к кому-то домой работать, а там все провода зелёные. Двоюродные постарались.
История с пикабу:
Меня недавно спросили, почему программисты ненавидят работать с чужим кодом. Долго думал, как донести до обычного пользователя всю суть пиздеца. Решил привести небольшую аналогию:
Вот представь, что тебе доверили достроить за другим прорабом лабораторию на острове. Ты приходишь на объект, а там кроме недостроенного здания: огромный вентилятор (размером со здание), большой воздушный шар и комната набитая швабрами. Почесав голову, ты разбираешь этот хлам и доделываешь лабораторию. Сдаешь объект ученным, но через 5 минут они выбегают с криком: "УТЕЧКА ЯДОВИТОГО ГАЗА!!!".
- Как так-то, блять! Должно же работать! - в отчаянии кричишь ты и звонишь прошлому прорабу:
- Вася, у нас ядовитый газ потёк! В чем проблема?
- Не знаю, должно было все работать. Что-то в проекте менял?
- Немного, швабры вынес...
- Швабры потолок держали!
- Что??? Что, блять, извините???
- Говорю, швабры потолок держали. Над ними цистерны с газом были. Очень тяжелые, пришлось в комнату снизу швабры напихать.
- Ты хотя бы записку на двери повесил бы, что швабры для держания потолка! У нас тут ядовитый газ течет! Что нам делать?
- Включай вентилятор. Он сдует газ с острова.
- Я его, блять, демонтировал сразу же!
- Зачем?
- Зачем ты построил 120 тонный вентилятор? Ты не мог положить ящик блядских ПРОТИВОГАЗОВ?
- Ящик противогазов искать нужно, а вентилятор у меня с прошлого заказа оставался.
- Вася, я убрал твой вентилятор! Мы тут задыхаемся!
- Херли вы тогда там делаете? Садитесь на воздушный шар и уебывайте!
За Германию, Кипр и Израиль скажу, все то же самое.
За США только понаслышке, и через совместные проекты. Тоже пипец.
windruf➦Clopodav• 27.11.18 17:30
подтверждаю. работаю в Германии. мой шеф - главный поставщик сайта Unmaintainable Code.
Ну бес его знает...
Теоритически, действительно может быть такая ситуация.
Т.е. ничего не прокоментированно, не продумано и т.д. , что каждое изменение требует переписывания большого количества кода.
Держу пари, сменщики его нашли и проставились за то, что их работой обеспечил!
specialforspam• 27.11.18 10:31
Ну хз. По-разному бывает.
Я вполне допускаю криворукость первого, при которой всё написано/настроено через жопу, но работает (скорее всего, тоже через жопу).
А как начнёшь разбираться, да переделывать как положено - то там выползет, то там (из-за предыдущей кривизны). И если один лет пять писал, то двоим пару лет и надо, чтобы переписать всё...
Хренонимус ★➦specialforspam• 27.11.18 11:36
Если "программист" в контексте России, то не удивлен.
По роду службы насмотрелся и на сервера затрояненные, и на апдейты годами не ставленные, и на сети на железе 2001ого года "за 20ку". Но да "все работает" и именно через жопу.
После такого как минимум еще одна команда сменится: любимый-старый программист - нелюбимый, который все портил - толковый новый (который строит на нормальном основании предыдущего).
windruf➦Соломон Маркович• 27.11.18 17:24
если "то тут не работает - то там ломается" то проблемы с архитектурой и стандартами. у меня парочка таких артефактов на попечении. чтоб что-нибудь туда добавить - нужно килобайты кода перелопатить и то нет полной уверенности, что ничего не упустил и не сломал.
Так-то оно так... только немножечко не так...
В банке, где я работаю, новых программистов две недели обучают нашим внутренним стандартам и требованиям.
В результате, проблемы понимания чужого кода ничем не отличаются от проблем понимания своего.
Корпоративные стандартизация и бюрократия очень помогают в правильно организованной работе.
daledale➦Alexander_A• 27.11.18 10:00
Вы думаете речь идёт о ПРОГРАММИСТЕ в т.ч. пишущем код? Ну-ну... велком ту раша, спуститесь на землю.
ElenaEPetrova ★➦Alexander_A• 27.11.18 10:08
Все верно, стандартизация важна. А ещё неплохо иметь описания программ (видимо, бюрократия :) ) и хотя бы комментарии в коде - почему именно так. Мы на заводе в итоге к этому и пришли. Конечно, пока описываешь прогу, это немного нервирует, зато потом и чужой код проще понять, и состыковать разные программы легче.
Alexander_A ★➦ElenaEPetrova• 27.11.18 10:38
Комментарии в коде и "описания программ" это даже не корпоративные требования. Это ISO 9000.
Я уверен, что в России есть свой аналогичый стандарт.
А корпоративные стандарты включают правила структуры, названия переменных/классов/функций, список не-рекомендуемых функций...
Alexander_A ★➦daledale• 27.11.18 10:40
Вы меня пугаете.
А чем в Раше занимается программист?
(Пиво пьют все).
Гекс ★★➦daledale• 27.11.18 14:24
Дак они же тут все закодированные, а ты Эзопом быкуешь)))
evengerova➦Alexander_A• 27.11.18 15:16
Правильно. А еще в нормальных конторах code review делают.
evengerova➦Alexander_A• 27.11.18 15:21
Тогда уж CMMI (он как-то больше к обсуждаемой области подходит). Но наличие сертификата слабо коррелирует с наличием нормального процесса на предприятии.
Pivo Vodkin ★➦daledale• 27.11.18 20:54
Ну ващета и в "раше" давным-давно уже сисадминов называют сисадминами. Программистами их называли лет 15-20 назад.
Так что, ежели рассказ современный, то, скорее всего, слово "программист" означает именно программист.
Alexander_A ★➦Pivo Vodkin• 27.11.18 23:05
На рубеже веков, когда я активно писал на хоботе, были ещё т.н. эникейщики. Смесь сисамина, техника, администратора сетей, скорой помощи для бухгалтерии и секретарш, чёрт в ступе и т.д.
Pivo Vodkin ★➦Alexander_A• 28.11.18 08:03
Это уже жаргон самих эникейщиков, название произошло от истории про "где находится эни кей" - "да вот же она, под надписью Reset!".
А бухгалтерии и секретарши называли "программист".
От себя добавлю:
И никогда тебе, козлу-начальнику, везти не будет.