Здравствуйте, Skorodum, Вы писали:

J>>Это яркий пример 15 лет опыта (думаю что у него даже побольше будет) при которых человек так и застрял на базовом уровне.
S>Причем это вещи, которые сейчас считаются само-собой разумеющимися, их активно обсуждали и искали решения лет 15 назад.

Тише, не спугните. У нас тут, похоже, живая иллюстрация эффекта Даннинга-Крюгера.

Здравствуйте, ukrspecs, Вы писали:

U> Скрипя зубы

Все эти глупые вопросы помогают понять, на каком уровне с вами получится разговаривать — и можно ли донести мысль, когда возникнет желание её донести.

U> Оборудование, бухгалтерия, переговоры, настройка инфраструктуры и многое другое — все на тебе. И вот мой кейс.

Круто, респект. Честно.

U> Что такое ООП?

Тут надо понимать, что есть работа, а есть сознание этой работы. Если вы не осознаёте, что вы делаете, с вами тяжело будет общаться. Ответ-то просто: при написании когда программы, можно выбрать один из нескольких базисов, в которых вы формулируете идеи. ООП — это базис в котором идеи формулируются в терминах объектов и их взаимодействий.

U> Чем интерфейс отличается от абстрактного класса?

В общем случае под интерфейсом понимается контракт по которому один объект взаимодействует с другим. В более общем случае это называется "контракт".

Абстрактный класс — это механизм ОО-языков, позволяющий описать высокоуровневые аспекты поведения и позволяя саб-классам описать низкоуровневые подбробности.

U> Что такое эксепшн?

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

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

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

Вы идёте работать не в компанию, а с конкретными людьми. Если вам не нравится, просто не идите. Настоящие засранцы очень явно показывают себя на интервью. Если вы это видите и не нравится, просто не идите дальше. Собеседования для этого и есть. Не только _ответы_ важны, но и _вопросы_.

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

Здравствуйте, so5team, Вы писали:

N>>Ну вот, вы, оказывается, сами понимаете, что доводить до абсурда — бессмысленно. Тогда зачем всё это было?
S>В моем случае целью было показать насколько обозначенный подход порочен. Видимо, получилось.

Насколько порочно ваше утрирование — да, получилось. Про подход в целом — нет.

[skip повторы про то же]

N>>Потому что я не считаю различие "на бумажке" и "в IDE" сколь-нибудь значимым самим по себе, без прочих параметров, как сложность, объём и всё такое.
S>Речь не об этом. Речь о том, что в своей работе когда программист сталкивается с непонятным кодом, то он может позволить себе запустить его и посмотреть результаты. Ну или выделить фрагмент в обособленный автономный пример и поэкспериментировать с ним. Т.е. может получить обратную связь и корректировать свои представления о том, что и как должно было бы быть, посредством актуальных результатов.

И тоже ой не всегда. Вы абсолютизируете это, но если там создаётся объект весьма непонятного назначения и сверхсложной функциональности — какой-нибудь корневой управляющий модуль всей логикой компонента? Что вам даст возможность запустить без функционального теста верхнего уровня? И, заметьте, это отнюдь не маргинальный случай.

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

Это совершенно естественные условия. Ну с поправкой бумаги на терминал/IDE. У вас что-то написано размером в экран и что вы, без запуска вообще не поймёте, что там происходит?

Ну вот пример (извините, что не C++ — просто вот сейчас копаюсь)

        if event.getData('hold_cc_api'):
            self.recvApiEvent(event, ua)
        if event.et_dialog == ET_D_NOTIFY and event.et_notify_real:
            self.recvCustomHoldEvent(event, ua, SIDE_O if ua == self.uaO else SIDE_A)
            return

За каждым вызовом ещё слоёв на 10 внутрь логики. Запускаем и смотрим, да? Тут как минимум юниттест с тонной моков нужен.
А вот по названиям можно понять, что происходит (а тот, кто хотя бы несколько недель работал с компонентом, уже знает, что за каждым термином стоит)
Кстати, вы точно так же можете найти примеры из своего фреймворка. Только не хотите.

Да, тут рассказать, что происходит — это уровень джуна. На мидла нужен пример потолще или завершённый попроще. Но не в этом суть.

S>И один из вопросов, который при этом у меня возникает, это: "Ну и нафига?"

Чтобы проверить соответствующие базовые способности.

N>>Ничего фатального тут в бумаге нет, пока не требуются специфические возможности IDE (о которых уже упоминал).
N>>И вот почему бумага вас так отпугивает тут — непонятно — это и есть тот ваш странный абсолют, который сбивает конструктивность дискуссии.
S>Еще раз, дело не в бумаге. Дело, как минимум, в оторванности от жизни.

Которой тут нет.

S>>>Если да, то мне бы хотелось увидеть пример того, когда программиста брали на работу для того, чтобы он затем смотрел на распечатанные куски чужого кода и рассказывал, что произойдет в результате работы этого кода.
N>>Читать код — норма.
S>Норма. Не норма, это когда вам приносят код и требуют сказать, что будет в результате его работы.

Сильно зависит от конкретного кода.

N>>Понимать, что делает код, если он объёма, например, до экрана и все вызываемые средства понятны — тоже норма.
S>А вот эта "норма" уже из области фантастики. Ну типа когда кода мало. И когда все понятно.
S>Сами часто в таких условиях оказываетесь, особенно с чужим кодом?

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

N>>Перенос, как вы описали — что на работе будет тоже бумага — не имеет смысла.
S>Еще как имеет. Но если вы его не видите, то это не значит, что его нет.

Это вы в упор отказываетесь видеть, что он есть.

S>Ах да, примера-то ожидаемо не было.

Естественно, на такой бредово-деструктивный запрос примера не будет.

S>>>>>c) есть более эффективный подход с использованием распечатанного на бумаге кода.
N>>>>Какой?
S>>>Внимательнее, пожалуйста, читайте то, что вам пишут. Я уже говорил: дайте соискателю распечатку реального кода и попросите рассказать, что он о нем думает.
N>>А это ничего, что я предложил как раз осмысливание кода вслух? Вы теперь то же самое говорите мне.
S>Я вам это с самого начала говорил. Но говорил про примеры кода для которых нет однозначно верного ответа.

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

Которую вы создали искусственно. Я не знаю, что за вид невнимательности пропустить break в пяти строчках — у меня так не получается (хотя бывают другие варианты невнимательности). И, честно говоря, плохо верю — потому что break внутри цикла это стандартный паттерн и ловить его каждый, кто обучился хотя бы на школьном уровне, должен ловить автоматом. Но предположим — да, у вас такое зрение. Тогда почему и в этом случае не предполагаете от кандидата возможность в рамках диалога описать всё, что видит — и, если нужно, про злосчастный break просто подсказать?

И "что увидим на экране" в этом случае тоже легко выясняется — как в случае с соседом по треду, который, если я правильно понял, ответил не тем, что в cout, а тем, что в следующем выражении. Это или простая невнимательность, или полное непонимание — и это легко выяснится.

S>>>Кстати говоря, вы почему-то решили, что здесь речь должна идти о стиле кода. Непонятно почему.
N>>Потому что стиль тоже важен. И я написал
>>>> а потом и к стилю перейти?
N>>"потом" тут принципиально.
S>Так вы не ответили на вопрос о том, почему вы решили, что речь пойдет о стиле? Стиль при таком подходе -- это последнее, что нужно обсуждать. Если кто-то думает, что стиль важен.
S>Опять же, возможно, мы "стиль" трактуем по-разному. Я в данном случае поразумеваю camelCase/snake_case, переносы и расставление скобочек.

Ну вот и ваше заблуждение от того, что вы трактуете "стиль" только как то, что вы описали, хотя практически у всех вокруг есть десятки разных аспектов стиля (например, все параметры в конструкторе или передавать как сеттеры, требовать обязательно чёткого while в условии или допускается for(;) с пачкой внутренних выходов, один return на функцию или как можно раньше выходить по каждому чиху... да даже тысячи их). Это ещё один случай, когда ваше определение чего-то начинает радикально не совпадать с общепринятым. Зачем?

N>>И что из этого должно следовать?
S>То, что для разных целей нужно использовать разные походы. Если вам нужно набрать большое количество людей, что означает: a) большой поток соискателей, поэтому каждому из них вы не сможете уделять много времени, и b) относительно невысокий уровень у большинства соискателей, поэтому вам потребуется какой-то повторяемый критерий, который позволит отсеивать людей с самым низким уровнем без привлечения ценных интервьюеров.
S>Если вы ищете буквально 4-5 крутых сотрудников, чтобы с нуля поднять совершенно новую тему, то подходы будут другие.

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

N>>Вот я предлагаю прочитать 10-строчный пример с бумаги. Он тут же разворачивается и хлопает дверью, как ТС по рассказам его критиков?
S>Соискатель может повести себя как угодно. Я про другое: если вы даете соискателю 10-строчный пример и просите рассказать, что будет в результате его работы, то с моей точки зрения как интервьюер вы так себе. Ну или вам нужно за 3 месяца набрать 50 гребцов на галлеру, дабы закрыть потребности нового клиента.

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

N>>В чём вы пытаетесь меня убедить — что если кто-то предложил прочитать с бумаги, то он робот, действующий по алгоритму и он отбракует самых интересных?
S>Я говорю о том, что есть более интересные и, с моей точки зрения, более адекватные подходы. И что если человек вместо них использует порочные методы, то есть вопросы к его профпригодности.

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

N>>"Оценка по количеству правильных ответов" != "оценка только по количеству правильных ответов"
N>>Уже говорил: я такое проходил. Вначале дали тест, на пачке коварных примеров. Потом пошло обсуждение. Просто тест сам по себе недостаточен, но заведомо непригодных позволяет отсеять.
S>Да без разницы. Важен сам факт того, что количество неправильных ответов влияет на итоговый результат. И это при том, что в реальной работе у вас потом этот человек ни с одним из ваших коварных примеров не столкнется. А если и столкнется, то у него будет возможность написать тестик и посмотреть что к чему. И все это без присущего собеседованию стреса.

Нет, это не так. Во-первых, регулярно сталкиваемся — на каких-то крайних случаях. Вот пример, когда я лажанулся (тут уже патч исправления):

@@ -853,7 +853,7 @@
void BARequestsThread::requestApplyNewConfig(
         std::shared_ptr<const CqtConfigBase> config)
 {
     // Run in main thread. Send request to do reconfig.
-    mIOService.dispatch([&]() { applyNewConfig(config); });
+    mIOService.dispatch([=] { applyNewConfig(config); });
 }

Представим себе, что я даю кусок исходного кода на анализ. Важно, что за конфиг? Тут — нет, пофиг. Поймает ли кандидат проблему? Вообще озвучит ли возможность (даже если не скажет твёрдо, будет она или нет)?
Мне достаточно было бы озвученного сомнения.

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

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

N>>"Когда изучал", был после этого реальный фидбэк?
S>Народ не жаловался. И отрицательных отзывов от наших собеседований потом не слышал.

Так это было "4-5 гуру" или "50 середнячков"?

S>Для меня существенно то, что человек усомнился и упомянул вариант устранения этих сомнений.
S>Если же человек знает, что char != signed char != unsigned char, да еще вне зависимости от ключей компилятора, то он вообще ответит однозначно и вопросов к нему не будет.

Нет, он может не ответить однозначно из-за 1 vs 2. А потом вы его подминусуете чуть из-за того, что не вспомнил незначащий тут ключ.

S>Но редко кто сможет дать абсолютно правильный ответ на эту задачку с перегрузками. Я не дал. Вы не дали.

Ну вот потому я по ней послушал бы рассуждения, а не точный ответ.

N>>Если идти по собеседованиям — да, надо знать. Потому что если таких заметная часть, придётся к этому готовиться, даже если знаешь, что внутри есть реальные задачи.
N>>Это не очевидно?
S>Нет. Для меня сейчас не очевидно вы сейчас про чью точку зрения говорите: собеседующих или собеседуемых.

Именно сейчас — собеседуемого.

S>Меня больше заботит точка зрения собеседующих, т.е. как выстроить процесс интервьюирования так, чтобы не отсеивать самых толковых соискателей. И чтобы при этом не создать своей компании подмоченную репутацию. А это можно запросто сделать, если будет плохой сарафан от тех, кто не прошел интервью.

И вы на стороне ТС — если приходит кандидат сразу на сеньора, то явного контроля на базу уже не делается?
И вы уверены, что своим процессом сможете всё равно отсеять неподходящих?
Ну хорошо, если это работает для одной конторы. Но при этом у вас всё равно неявный контроль на всех уровнях.

S>Однако, когда система интервьюирования выстроена, то нужно задасться следующим вопросом: а пройду ли через нее я сам? И если не пройду, то хорошо ли это.
S>Так вот, с точки зрения выстраивания системы интервьюирования совершенно без разницы, как часто на собеседованиях в других компаниях пересчитывают гномиков и/или определяю форму крышек люков.

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

Вы, кажется, предполагаете, что все интервью всеми будут проводиться на максимуме уровня мышления со всех сторон. Может, это верно для кандидата (если он не впал в стресс, о котором вы ж сами и упомянули), но и у интервьюера могут быть разные состояния.
Хотя, если у вас только гуру и вы проверяете в лучшем случае 1 человека в месяц, такое пойдёт.
У меня не гуру, но и не галера штампованных гребцов, я вижу картину посредине (несмотря на ваши немедленные сравнения с 50 стандартными сотрудниками).

N>>>>Вторая, если я правильно понял, о чём речь — совсем не принципиальна (разве что для разработчика компилятора — и то не всегда).
S>>>Поскольку никто причин потенциально провальной компиляции не озвучил, то даже не буду гадать, что вы подразумеваете.
N>>Я оценивал в следующем порядке: 1) 'C++' (до 20-го) 2) отсутствие include.
S>Первый пункт не понял. Там же по std::cout, auto и использованию universal references очевидно, что это, как минимум C++11 (код в режиме C++11 компилируется, кстати).

Ну вот и видно, что это извращение мне ни разу не требовалось, хотя и парсеры писал, и всё такое сейчас увидел, да, что они давно, но implementation-defined.

S>Второй пункт -- да, в точку. Но вот я не сразу обратил внимание. Привык к тому, что примеры в презентациях обычно дают в сокращенном виде, без необходимых прологов. Однако, если брать именно как есть, то не скомпилируется.
S>Еще есть такой момент, что если в компиляторе выставить -Wall (-Weverything) и -Werror, то будет ошибка компиляции из-за неиспользуемых аргументов в нешаблонных функциях f и multibyte character constant. Не зря же я говорил "что у меня такой код вообще не соберется". Мол, я всегда с -Wall/-Werror компилируюсь

Я "у меня" воспринял в контексте предыдущего упоминания MSVC. Так как работаю только под Unix, мне это было неинтересно.

Здравствуйте, netch80

Простите, netch80. Я внимательно прочитал то, что вы мне ответили. Но отвечать не буду из-за того, что вы упорно спорите не со мной, а с тем, что вы с моих слов навыдумывали. Вот, самый яркий пример:

N>Нет, он может не ответить однозначно из-за 1 vs 2. А потом вы его подминусуете чуть из-за того, что не вспомнил незначащий тут ключ.

Я нигде не говорил, что заминусую. Говорил, что бонусом будет знание существование такого ключа.

И такое передергивание и возведение в маразм с вашей стороны на каждом шагу. Начиная от того, что вы мне приписали неприятие написания кода на собеседовании вообще. И заканчивая тем, что якобы мое определение "стиля" отличается от общепринятого (хотя то, что перечислили вы подразумевается и мной, только я не ударялся в написание столь подробного перечня). Только вот "в функциональном стиле", "в процедурном стиле", в "ОО-стиле" -- это тоже попадает под "стиль". И мне было важно, чтобы "стиль" в смысле "единственный return" не отождествлялся со "стиль" в смысле парадигм программирования.

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

PS. Если у кого-то есть желание предметно и непредвзято пообщаться на тему применяемых на собеседовании приемов, то без проблем. Но давайте без додумывания и без навешивания смыслов, которых не было. Я всегда готов пояснить что именно подразумевалось и почему, а что не подразумевалось.

Здравствуйте, AlexGin, Вы писали:

AG>Нет там никакой фигни, ещё раз прочитав тогдашние мои сообщения, могу сказать — только изложение точки зрения есть.
Там показано непонимание проблемы, причем проблема показана в 10 строчках в дистиллированном виде.

AG>Для ясности подскажу, что решения, подобные приведенным там и защищиемые (как мной, некоторыми другими форумчанами) -
AG>имеют место и в многочисленной литературе по C++ и на сайтах (SO, codeproject и т.д).
Вы никакого решения там не приводите.

AG>Посему считаю — что выражена точка зрения, применимая для многих задач на современном C++.
AG>Да, она не соответствует универсальному подходу к выделению памяти (в т.ч. на кофеварках и в часах).
Выделение памяти тут вообще не причем. Может быть утечка любого ресурса: сокета, соединения с БД, открытыго файл, etc.

AG>Но делать всё универсальным бессмысленно:
AG>типа на вот тебе робот-пылесос, но у него степени защиты ПО как в авионике,
AG>правда стоит он как новое авто из салона
AG>Согласись, что такой подход именуется "из пушки по воробьям".
Это основы управления ресурсами в С++. Даже не знаю, что написать...

AG>P.S. Sorry, уважаемый Skorodum, если прежнее моё мнение о вас у меня изменилось
Мммм... Ок

Здравствуйте, mgu, Вы писали:

mgu>Здравствуйте, AleksandrN, Вы писали:

AN>>Т.е. — граница между интерфейсом и абстрактным классом в C++ очень размыта. В отличие других языков, например Java, где эти понятия жёстко разделены.

mgu>Хе-хе. В Джаве №8 в интерфейсах разрешили имплементацию методов по умолчанию. Я живо представил, как я это сообщаю специалистам по допотопным версиям, и как они гонят меня ссаными тряпками.

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

Здравствуйте, so5team, Вы писали:

S>Я нигде не говорил, что заминусую. Говорил, что бонусом будет знание существование такого ключа.

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

S>И такое передергивание и возведение в маразм с вашей стороны на каждом шагу.

Вы сами его породили, упорно в этом постаравшись.

S> Начиная от того, что вы мне приписали неприятие написания кода на собеседовании вообще.

Не было такого.

S> И заканчивая тем, что якобы мое определение "стиля" отличается от общепринятого (хотя то, что перечислили вы подразумевается и мной, только я не ударялся в написание столь подробного перечня).

И тоже вы сами этого сказали открытым текстом:

>> Опять же, возможно, мы "стиль" трактуем по-разному. Я в данном случае поразумеваю camelCase/snake_case, переносы и расставление скобочек.

Как это ещё понять? Или "в данном случае" было "в четверг"?

S> Только вот "в функциональном стиле", "в процедурном стиле", в "ОО-стиле" -- это тоже попадает под "стиль". И мне было важно, чтобы "стиль" в смысле "единственный return" не отождествлялся со "стиль" в смысле парадигм программирования.

Вы этого не говорили. Зато сказали открытым текстом совершенно другое.

S>Так что, поскольку вы явно беседуете не со мной, а с каким-то вымышленным образом в вашем собственном представлении, то оставлю вас общаться с вашими тараканами на тему того, насколько so5team неправ.

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

S>PS. Если у кого-то есть желание предметно и непредвзято пообщаться на тему применяемых на собеседовании приемов, то без проблем. Но давайте без додумывания и без навешивания смыслов, которых не было. Я всегда готов пояснить что именно подразумевалось и почему, а что не подразумевалось.

Не думаю, что с вашим стилем будет что-то успешное в этом, но готов с интересом понаблюдать.

Здравствуйте, netch80, Вы писали:

Два крутых специалиста с хорошей репутацией, а разговор скатился к какой-то ерунде...

Лучше

Здравствуйте, Skorodum, Вы писали:

S>Два крутых специалиста с хорошей репутацией, а разговор скатился к какой-то ерунде...

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

S>Лучше

Скорее :wine:

Здравствуйте, mgu, Вы писали:

bnk>>>Ну вот скажи например, что есть "эксепшен" ("исключение")? Я так сходу пожалуй и не отвечу

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

mgu>Я бы сказал "исключаемая".

Тут интереснее. Дело в том, что у exception кроме "исключение" ещё есть смысл "возражение" (особенно любят в суде — "Exception, your honor!"), и оно тут ближе к сути механизма. То, что у нас перевели как "исключение" и так оно закрепилось — одна из многочисленных диверсий переводчиков (как "поток" для thread).

Здравствуйте, netch80, Вы писали:

S>> Начиная от того, что вы мне приписали неприятие написания кода на собеседовании вообще.

N>Не было такого.

Было.

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

"Сходу" — неточно, "без ошибок" — перебор (хотя сильно зависит от типа ошибки — естественно, опечатки, порядок аргументов и пр. — не в счёт), писать на бумаге — разве что на каплю хуже, чем на доске.
Хотя я согласен, что по умолчанию лучше предлагать доску — потому что уметь сделать на бумаге так, чтобы читалось даже со 100500 помарками, это уже скилл старшего поколения (может, ещё такого, как я, что помнит перфокарты).

Я ничего плохого не говорил о таком общем приеме, как написание кода на бумаге во время собеседования. И я не отрицал этот подход в общем. Но ваши слова выглядят так, как будто бы это было сделано.

S>> И заканчивая тем, что якобы мое определение "стиля" отличается от общепринятого (хотя то, что перечислили вы подразумевается и мной, только я не ударялся в написание столь подробного перечня).

N>И тоже вы сами этого сказали открытым текстом:

>>> Опять же, возможно, мы "стиль" трактуем по-разному. Я в данном случае поразумеваю camelCase/snake_case, переносы и расставление скобочек.

N>Как это ещё понять? Или "в данном случае" было "в четверг"?

S>> Только вот "в функциональном стиле", "в процедурном стиле", в "ОО-стиле" -- это тоже попадает под "стиль". И мне было важно, чтобы "стиль" в смысле "единственный return" не отождествлялся со "стиль" в смысле парадигм программирования.

N>Вы этого не говорили. Зато сказали открытым текстом совершенно другое.

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

"Стиль" в употребленном мной смысле -- это когда мы можем переписать один и тот же код разными способами, но принципиально он не изменится. Например:

/*!
 @brief Поиск значения максимального элемента в векторе.
 
 @param data Вектор в котором нужно искать максимальный элемент. Не должен быть пустым.

 @throw std::invalid_argument если @a data пуст.
*/
int max_value_of(const std::vector<int> & data) {
  if(data.empty())
    throw std::invalid_argument("max_value_of: emtpy vector");
  auto it = data.begin();
  int max = *(it++);
  for(auto end = data.end(); it != end; ++it)
    if(max < *it) max = *it;
  return max;
}

И

//! Поиск значения максимального элемента в векторе.
int MaxValueOf(
  //! Вектор в котором нужно искать максимальный элемент. Не должен быть пустым.
  std::vector<int> const & Data)
{
  int Result;

  if(!Data.empty())
  {
    auto Current = Data.begin(), Last = Data.end();
    Result = *Current;
    for(++Current; Current != Last; ++Current)
    {
      if(Result < *Current)
      {
        Result = *Current;
      }
    }
  }
  else
    //! @throw std::invalid_argument если @a Data пуст.
    throw std::invalid_argument("MaxValueOf: empty vector");

  return Result;
}

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

std::optional<int> max_value_of(const std::vector<int> & data) noexcept
  {
    const auto it = std::max_element(begin(data), end(data));
    return it != end(data) ? *it : std::nullopt;
  }

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

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

N>А описывать текстом (русским или английским по фоновому) — получается то, что сейчас получилось.

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

Здравствуйте, so5team, Вы писали:

S>Я ничего плохого не говорил о таком общем приеме, как написание кода на бумаге во время собеседования. И я
не отрицал этот подход в общем. Но ваши слова выглядят так, как будто бы это было сделано.

Для кого они так выглядят? По-моему, очевидно, что в этой цитате я как раз не возражал против него. Вы вцепились в контекст спора и не заметили, что тут его уже нет? Ну извините, не оправдал ожидания.

S>Чтож, давайте еще раз на пальцах. При этом, чтобы вы опять не домыслили чего ("ещё одна откровенная попытка принизить оппонента") подчеркну, что "на пальцах" означает самый упрощенный, не допускающий неточных и двояких толкований уровень из тех, что могу придумать себе я сам.

S>"Стиль" в употребленном мной смысле -- это когда мы можем переписать один и тот же код разными способами, но принципиально он не изменится. Например:

Прямое несогласие с вашими же словами раньше:

>> Опять же, возможно, мы "стиль" трактуем по-разному. Я в данном случае поразумеваю camelCase/snake_case, переносы и расставление скобочек.

В общем-то это уже несущественно, но давайте таки ровнее.

S>И вы правы, в "стиле" куча аспектов. Если вы хотели, чтобы я обозначил пару-тройку дюжин из них, а не ограничился лишь тройкой наиболее ярко выраженных, то извините. Надеюсь, сейчас мое понимание "стиля" стало понятнее.

Сейчас — да. Перед этим — нет. Так как далее это явно не будет существенным — считаю вопрос закрытым.

N>>А описывать текстом (русским или английским по фоновому) — получается то, что сейчас получилось.
S>Попробуйте как-нибудь свои тексты перечитать непредвзято. Вы удивитесь. Говорю вам как человек, который написанное вами внимательно читает.

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

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

Здравствуйте, netch80, Вы писали:

N>Для кого они так выглядят?

Для меня.

N>Прямое несогласие с вашими же словами раньше:

>>> Опять же, возможно, мы "стиль" трактуем по-разному. Я в данном случае поразумеваю camelCase/snake_case, переносы и расставление скобочек.

Есть ощущение, что вы пропустили слово "возможно". Когда вы заговорили о стиле, я воспринял это именно в том контекте, до которого мы сейчас договорились (надеюсь что), т.е. нотация, оформление, какие-то рекомендации по организации кода и пр. Но т.к. "стиль" можно трактовать и как использование разных парадигм (и даже как использование разных практик/паттернов в рамках одной парадигмы), то я сделал оговорку на счет того, что могу неверно интерпретировать ваши слова. Отсюда и "возможно". Типа того, что возможно, вот здесь

Автор: netch80
Дата: 02.12.20

:

Ну а почему бы не "что он делает?" спросить для начала? а потом и к стилю перейти?

вы говорили о парадигмах, а не о нотации/оформлении/рекомендациях.

N>Я это периодически делаю. Да, я вижу моменты, когда можно было бы высказать то же самое компактнее и точнее, но чтобы обнаружить явную некорректность, если это не тупая обмолвка или недосмотр — не было очень давно.

Речь не про компактнее/точнее. А, например, про то какой собственный смысл вы умудряетесь вкладывать в мои слова. Примеры этого я уже приводил выше.

Здравствуйте, netch80, Вы писали:

bnk>>>>Ну вот скажи например, что есть "эксепшен" ("исключение")? Я так сходу пожалуй и не отвечу

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

mgu>>Я бы сказал "исключаемая".

N>Тут интереснее. Дело в том, что у exception кроме "исключение" ещё есть смысл "возражение" (особенно любят в суде — "Exception, your honor!"), и оно тут ближе к сути механизма. То, что у нас перевели как "исключение" и так оно закрепилось — одна из многочисленных диверсий переводчиков (как "поток" для thread).

Objection же.

Здравствуйте, mgu, Вы писали:

bnk>>>>>Ну вот скажи например, что есть "эксепшен" ("исключение")? Я так сходу пожалуй и не отвечу
A>>>>Исключительная ситуация, когда что-то пошло не так. А дальше, можно развернуть.
mgu>>>Я бы сказал "исключаемая".
N>>Тут интереснее. Дело в том, что у exception кроме "исключение" ещё есть смысл "возражение" (особенно любят в суде — "Exception, your honor!"), и оно тут ближе к сути механизма. То, что у нас перевели как "исключение" и так оно закрепилось — одна из многочисленных диверсий переводчиков (как "поток" для thread).

mgu>Objection же.

В каком смысле? Ну да, основное слово для "возражение" — objection. Но смысл, о котором я говорю, тоже есть, и был использован явно он.

Здравствуйте, netch80, Вы писали:

N>Здравствуйте, mgu, Вы писали:

bnk>>>>>>Ну вот скажи например, что есть "эксепшен" ("исключение")? Я так сходу пожалуй и не отвечу
A>>>>>Исключительная ситуация, когда что-то пошло не так. А дальше, можно развернуть.
mgu>>>>Я бы сказал "исключаемая".
N>>>Тут интереснее. Дело в том, что у exception кроме "исключение" ещё есть смысл "возражение" (особенно любят в суде — "Exception, your honor!"), и оно тут ближе к сути механизма. То, что у нас перевели как "исключение" и так оно закрепилось — одна из многочисленных диверсий переводчиков (как "поток" для thread).

mgu>>Objection же.

N>В каком смысле? Ну да, основное слово для "возражение" — objection. Но смысл, о котором я говорю, тоже есть, и был использован явно он.

Я бы для языков программирования ввернул термин rejection, как раз отражает суть. Главное, чтобы не было go to -- конструкции, подвергнутой анафеме на всех программистских соборах и шабащах.