И еще о поддерживаемости кода

[beldmit]

Вдогонку к этой
и немного этой записям. И еще немного к боковому хвосту у Витуса.

Один из типичных приемов собеседования с программистами - показ зубодробительной конструкции на языке, на котором собирается программировать соискатель, и вопрос, что она делает. Наиболее часто мне попадался C-шный пример, когда вместо переменной объявлялась функция.

Так вот, господа. Когда вам показывают такой пример (если он выходит за пределы разумного понимания языка и знания ключевых слов или общепринятых идиом), то скорее всего - одно из двух.

1. Собеседующий пытается срезать соискателя. То есть самоутвердиться. Вам нужен такой начальник?
2. Код реально используется в проекте? Вы действительно хотите это поддерживать?

Да, и главное, без чего пп.1-2 не действуют. Понимать, что предъявленный пример собой представляет - все-таки надо. Чтобы было ясно, что объявлена таки переменная, а не функция.

Comments

[raydac.livejournal.com]

что то никогда не просил на собеседованиях что то разобрать, даже в голову не приходило такое

[beldmit.livejournal.com]

Меня несколько раз просили объяснить именно код. Но в качестве вопросов на собеседование нечто подобное пару регулярно встречается.

[grzegorzrus.livejournal.com]

А что является разумным пониманием?

[beldmit.livejournal.com]

Я бы определил примерно так: исходя из общей идеологии языка, сделать вывод можно, даже не зная конкретной идиомы.

[gornal.livejournal.com]

Я почти всегда спрашиваю
c=3;
d=++c++;
printf("%d\n",d);

Но всегда подразумеваю, что если кто-то правильно ответит, то это плюс, а не минус, если не ответит. Отвечают крайне-крайне редко.

[beldmit.livejournal.com]

Ну, на это я отвечу. Неопределенное поведение, зависит от компилятора, за такой код убивать.

[singalen]

Третье противоречит первым двум.
Вы же не считаете, что большинство собеседующих не понимают этих трёх тезисов?

[beldmit.livejournal.com]

Часть явно не понимает.

[shigin.livejournal.com]

У меня несколько другая точка зрения.

1. Если нанимают программиста на C++ (то есть весь код у нас плюсовый и всё такое), то как--то логично проверить, знает ли человек подводные камни этого самого C++. Тем более, что приведенный пример может получиться и сам по себе.

2. Иногда приходится лезть в чужой код. Вообще чужой, а уж что бывает в чужом коде никому объяснять не надо.

3. Я не очень понимаю, чем это принципиально отличается от предложения отсортировать терабайтный файл, если у нас есть только 2 гига памяти.

[beldmit.livejournal.com]

1. Да. Я ж говорю - понимание необходимо.
2. Согласен. А с другой стороны - стоит ли связываться с этим чужим кодом?
3. Тут несколько сложнее. В идеале стоит думать о том, что ресурсов не хватит объективно. И описывать границы применения предложенного решения. Любого.

[fdo-eq.livejournal.com]

С выводами относительно конкретного примера согласен полностью.

[beldmit.livejournal.com]

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

[oldbukh.livejournal.com]

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

Зачем нужно вот такое макроопределение
#define MACRO(a,b) (&((b*)NULL)->a)

Работает как из пушки :)

[oldbukh.livejournal.com]

или чем плох вот такой код?

void print(std::vector& v)
{
for (unsigned i = 0; i < v.size(); i++)
printf("%d\n", v[i]);
}

Или чем STL-ный vector хуже чем имплементация списков из /usr/include/linux/list.h?

P.S. В плюсовом синтаксисе могу ошибаться :) Это не на подкорке

[besm6.livejournal.com]

Работает как из пушки :)

Из той самой, из которой нужно пристрелить того, кому эта информация в программе понадобилась?

[beldmit.livejournal.com]

Типа смещение элемента a в структуре/классе b? Убивать.

[dimas.livejournal.com]

Дим, ты не поверишь сколько народу срезается по пост-кондициям банального префиксного и постфиксного инкремента в цикле ... Когда мне на собеседовании в SWSoft об этом рассказали, я не поверил ... как подавал на собеседованиях сам - офигел ...


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

Но любителей подсунуть что-нить на undefined behavior, и заставляющих объяснить почему неправильно ... или всякие неоднозначные штуковины ... Я вот считаю что проще сказать что не правильно, и как - правильно, чем объяснять ... С другой стороны - собеседование, это ж взаимный экзамен, проще отсеять невменяемое место сразу, чем потом мучаться :)

[beldmit.livejournal.com]

Верю. Дофига. И с твоими выводами полностью согласен.
Ты, кстати, окопался где-нибудь?

[vtosha.livejournal.com]

Рассказывают, что на некоем коллоквиуме у медиков по черепу (или отверстиям черепа) преподаватель просверливал две дополнительные дырки и требовал ответить, что это. Мало кто сознавался, что этих дырок не должно было быть.

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

А когда речь доходит до дела, как бы мы отнеслись к медикам, не сдавшим такой коллоквиум?

[dimas.livejournal.com]

м-м-м ... можете рассказать на Ваш взгляд аналогию этим дыркам? :)

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

[slobin.livejournal.com]

Поскольку здесь всё равно не собеседование, не могу не удержаться и не рассказать свой любимый вопрос про язык C: как выглядит самая короткая программа на нём? На всякий случай проверяемая постановка задачи: из какого самого короткого файла команда gcc myfile.c создаст a.out? Варианты: (1) без ворниногов (2) ворнинги допустимы.

... За окном сверкает пол-луны ...

[abraham1901.livejournal.com]

main;
main () {}

[besm6.livejournal.com]

Так эти два вопроса надо задавать не в ЖЖ, а собеседующему... И принимать решение исходя из его реакции.

[beldmit.livejournal.com]

Я бы сказал, эти вопросы стоит держать в голове во время собеседования.

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

[arilou]

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

[beldmit.livejournal.com]

Нет. Я имел в виду другое: конструкции, которые не очевидны с первого и со второго взгляда - неудачные конструкции. Преимущества их мне еще надо обосновывать. Хотя выигрыш я допускаю.

Я, например, долго не любил конструкцию a?b:c; И сейчас недолюбливаю. Понимать я ее прекрасно понимаю, но эта конструкция, в отличие от честного if-а, неустойчива к малым воздействиям типа добавления отладочной печати.

[yakov-sirotkin.livejournal.com]

Да, я хочу это поддерживать, это моя специализация! Только на Java, а не на C++.

[beldmit.livejournal.com]

Скажи, а почему у тебя образовалась такая специализация?

Здесь идет речь о псевдоидеомах, которые чаще всего - "выпендрись как я".

[persinval.livejournal.com]

Согласен с тобой. Скорее всего, старший разработчик, который столь "любуется языком", не понимает, что в продукте это не главное. Тем самым какую либо ситсемную компоненту он напишет отлично, а продумать решение более сложной проблемы просто не сможет, так как не понимает ни задач, ни принципов, ни возможностей, которые требуются на "столь высоком уровне".
Мне самому нравятся всякие красивости языка, но задавать их на собеседовании? Уж нет.