>Поэтому программист просто напишет:if (!newOption)return;
Я же правильно понял, что В вашем примере "программист" напишет следующее в качестве рефакторинга:
if (newOption){return;} if (!(symbol_idleFX)) return; if (!idleFX) return; if(nextReward == 0) return;
? (если Вы не это имели ввиду, то нужно было полностью привести код "до" и "после" для наглядности проблемы)
Ну, и на каком основании программист это напишет, если ниже есть кусок кода, который перескачет в другую ветку кода? Это же логика, и в Вашем примере она просто нарушается, как можно это приравнивать к инвертированию, если это не является инвертированием, а является просто внесением изменений в логику?
Вот будет вполне корректное инвертирование в Вашем примере:
if (newOption) { if (nextReward == 0) return; return; // Да, довольно глупо выглядит из-за отсутствия // описанной логики, но зато логика выполнения // сохранена } if (!(symbol_idleFX)) return; if (!idleFX) return;
И никаких проблем я тут не вижу.
Можете в ЛС прислать листинг или ссылку на какой-то заполненный онлайн-редактор кода, если считаете проблему всё ещё актуальной, я объясню, почему там тоже можно сделать правильно без особых затрат. Мы же всего лишь говорим об условных инструкциях, а не о каких-то сложных конструкциях...
Думаю, там "непотребство" употреблено в смысле чего-то неприличного, NSFW, а не в смысле информационной/художественной ценности. Раз есть контент, то наверняка существует и спрос.
Вы всё ещё настаиваете, что "тихий" выход может повлиять на логику выполнения метода, но я тоже повторю, что в таком случае это уже не чистое инвертирование, а либо ошибочное внесение изменений в поведение, т.е. не относятся к нашему сабжу.
Ваш пример ничего не демонстрирует, какая логика в нём перестаёт выполняться? Покажите, пожалуйста, хотя бы условный кусок кода "до" и "после" рефакторинга, когда в изменении логики виноват именно "тихий выход"? Бьюсь об заклад, что вы просто напишете неэквивалентный код, и проблема будет вовсе не в инвертировании условий с тихими выходами.
Действительно, могут быть куски кода, где 3 подряд подобных условия могли изначально влиять друг на друга или на выполнявшуюся логику, но человек, который эти условия добавляет, должен сам удостовериться в том, что все ветки кода имеют ту доступность, которая ожидается, а если какая-то ветка кода стала недостижимой из-за "тихого выхода", значит кто-то просто криво написал этот код. Не понимаю, как может быть иначе, буду признателен, если пример всё же будет.
Я считаю, что не сталкиваюсь с этими проблемами, потому что Ваши доводы нелогичны, а не по предположенным Вами причинам, но будет интересно ошибиться =)
Человек выше (@SAWER) по моему мнению написал какую-то бессмыслицу, а не аргументы.
Написал следующий абзац в самом в конце, но перетащил наверх, т.к. это самая суть:
Вообще, это всего лишь фича для улучшения читаемости кода, она ВООБЩЕ не меняет логику. А если всё-таки меняет, значит инвертирование условия выполнено некорректно и это уже не попадает под "радоваться выполненной задаче", т.к. на ревью тебе с вопросом "ты понимаешь, что это не эквивалентный код?" вернут задачу на доработку.
Далее имхо:
Я думаю, что если бы автор обсуждаемого комментария попытался написать примеры кода, иллюстрирующие его ошибочные аргументы, то он сумел бы сам себе их и опровергнуть. Мне тяжело представить работающий код, в котором были бы актуальны перечисленные проблемы.
К тому же выше речь не обязательно о "тихом выходе", когда if (!...) { return; } // some stuff, там может возвращаться пустой массив, или просто короткий кусок логики.
В общем виде я это вижу как "много логики внутри if, нужно попытаться инвертировать относительно мЕньшего количества логики вне if", а будет ли там пустой return, о котором сокрушается автор комментария выше или что-либо другое — это всегда вопрос логики и конкретного примера.
Я каждый день вижу много хорошего и плохого кода, простого и переусложнённого, и регулярно что-то перерабатываю и рефакторю, а также периодически возвращаю на доработку задачи с ошибками после ревью, и я никогда не сталкивался со сложностью понимания и переиспользования таких инверсий с "тихим" выходом из функции. Проект у нас на миллионы строк кода, поэтому Простора для возникновения описанных автором проблем там полно, однако самих Проблем всё же нет.
Технология всё ещё развивается, и вообще не предполагает 100% точных ответов сама по себе. Пользуйтесь ей правильно, и будете получать от неё соответствующую меру пользы.
Лично я не пытаюсь от ChatGPT получить "правильный ответ", я просто жду подсказку, и почти всегда получаю её. Она не может решить задачу, зато очень неплохо наталкивает на решение, хотя ей самой кажется, что решает, но на данном этапе развития это не так уж плохо.
О том и речь, что это не проблема ChatGPT, ему никто не программировал "характер", он не живое существо, а всего лишь генератор ответов, поэтому на вопрос всегда будет приходить ответ, а не оправдание, как в случае с человеком, и это логично в контексте ЯЗЫКОВОЙ МОДЕЛИ, которой он и является, и регулярно об этом напоминает.
ChatGPT — это инструмент. Он способен давать правильные ответы, если задавать корректные вопросы.
А если задавать некорректные вопросы и неуместным образом проверять результаты, то можно не заметить пользы от этого инструмента.
Вообще неважно, кто и как Называет ChatGPT, и как к этому инструменту относятся другие люди, важно то, чем он является. Я знаю много примеров, когда люди пользуются в своей проф.деятельности ChatpGPT как инструментом, я сам пользуюсь им, и он помогает, пусть даже пока не стабильно и не идеально, но помогает.
Как говорится "Хоть горшком назови, только в печь не ставь".
Ну, да. Спасибо. Я прочитал и ответ, которому я уже плюсанул.
Такое определение не слишком широко распространено, мягко говоря, поэтому дискутировать не получится.
Чтобы спор вышел плодотворным и приближал к объективной истине, терминология должна быть общая, иначе мы просто на разных языках разговариваем.
Но сложно поспорить, что стать изобретателем, первооткрывателем... творцом, если угодно — это вообще не каждому человеку под силу, хоть 10000 часов дай, хоть 100500... И это тоже за рамками дискуссии.
А по-моему это сравнение тёплого с мягким. Градация профессионального уровня и должностных обязанностей.
Например, в организации, где я работаю, есть чёткое разделение по грейдам (цифрами обозначаются) и должностям. И эти параметры совершенно не обязательно однозначно коррелируют.
Как раз не у всех сеньоров есть какая-то нагрузка по софт-скиллам (нежелающих вставать на соответствующие должности не таскают по собесам и не ставят наставниками к новичкам, например).
Дайте, пожалуйста, своё определение рангу "senior"? Можете в гугле почитать различные и подобрать наиболее удобное под вашу позицию, но уверен, что ни одно не будет противоречить тезису: "за 6 лет, РАБОТАЯ на работе, будучи эффективным сотрудником, которого ценят, которому регулярно поднимают зп, которого не хотят отпускать, невозможно НЕ СТАТЬ сеньором", — какое бы из общепринятых определений для этого термина Вы ни выбрали.
Да, не чистых 10 000 часов, и да — не все задачи в течение рабочего дня добавляют знаний/навыков, но в целом человек лучше всего воспринимает информацию именно из собственного опыта взаимодействия с этой информацией.
Личный опыт: я 5 лет учился на кафедре разработки ПО, потом 5 лет болтался "без дела" (фриланс, пет-проекты) и всё это время не был разработчиком по факту. Зато за 2 года реального "боевого" опыта в проектной разработке узнал и углубил прошлые знания на несколько порядков эффективнее, чем за все прошлые годы вместе взятые.
Не представляю, как можно НЕ СТАТЬ сеньором через ещё 4 долгих года... Надо либо найти токсичную организацию, которая настолько ненавидит своих сотрудников, чтобы у тебя не было опции взять интересную (читай, развивающую) задачу/проект или выделить время на самообучение в рабочее время, в т.ч. для того, чтобы выполнять более сложные задачи или выполнять небольшие более эффективно. Ну либо, если организация нормальная, то придётся самому настолько не хотеть достичь этого, что делать задачи спустя рукава и не интересоваться ничем новым.
Поддержу @Dolios, что в вашем первом комментарии просто не осталось пространства, чтобы понять иначе =)
Существуют люди, которым просто после работы на двух проектах на полный день одновременно не хватает времени "наследить" ещё и где-то в open-source, или просто развивают какой-то приватный pet-проект, не желая шарить его с общественностью.
Однако, если пустой гитхаб в вашем понимании — действительно не приговор для кандидата, то вероятно, что к Вам напрасно прицепились с этой темой.
P.S. По моему личному мнению, гитхаб, полный прекрасно написанного кода — печенька в копилку кандидата, но пустой гитхаб — просто ничего не говорит о кандидате. И сложилось оно у меня из личного опыта:
Не так давно попробовал походить по собеседованиям, календарный опыт у меня довольно скудный, гитхаб пустой. Я оставил 20 откликов (включая MindBox, которые забраковали меня за неучтённую точность double, дословно =)) и получил 19 отказов. А тот единственный собес в течение 15 минут уже сделал мне оффер как хорошему миддлу, притом что у меня неполных 2 года коммерческой разработки за плечами =)
>Из примеров выше очевидно, что concurrent коллекции не дают полной защиты от race conditions
Лично я не готов согласиться, что из примеров выше что-то очевидно, особенно касательно concurrent-коллекций и race condition, т.к. приведенные примеры лишь демонстрируют несостоятельность классических коллекций к многопоточному применению. А очень хотелось бы такую демонстрацию, для того, чтобы это действительно стало очевидно.
И едете 2 раза в месяц через полстраны за зарплатой, или оплачиваете комиссию за денежный перевод...
>Поэтому программист просто напишет:
if (!newOption)return;Я же правильно понял, что В вашем примере "программист" напишет следующее в качестве рефакторинга:
if (newOption){return;}if (!(symbol_idleFX)) return;
if (!idleFX) return;
if(nextReward == 0) return;
?
(если Вы не это имели ввиду, то нужно было полностью привести код "до" и "после" для наглядности проблемы)
Ну, и на каком основании программист это напишет, если ниже есть кусок кода, который перескачет в другую ветку кода? Это же логика, и в Вашем примере она просто нарушается, как можно это приравнивать к инвертированию, если это не является инвертированием, а является просто внесением изменений в логику?
Вот будет вполне корректное инвертирование в Вашем примере:
if (newOption){
if (nextReward == 0) return;
return; // Да, довольно глупо выглядит из-за отсутствия
// описанной логики, но зато логика выполнения
// сохранена
}
if (!(symbol_idleFX)) return;
if (!idleFX) return;
И никаких проблем я тут не вижу.
Можете в ЛС прислать листинг или ссылку на какой-то заполненный онлайн-редактор кода, если считаете проблему всё ещё актуальной, я объясню, почему там тоже можно сделать правильно без особых затрат. Мы же всего лишь говорим об условных инструкциях, а не о каких-то сложных конструкциях...
Вероятно, Вы промахнулись, т.к. заминусили другого человека =)
P.S. Мой комментарий на 100% нейтрален, не надо минусить :D
Думаю, там "непотребство" употреблено в смысле чего-то неприличного, NSFW, а не в смысле информационной/художественной ценности. Раз есть контент, то наверняка существует и спрос.
Вы всё ещё настаиваете, что "тихий" выход может повлиять на логику выполнения метода, но я тоже повторю, что в таком случае это уже не чистое инвертирование, а либо ошибочное внесение изменений в поведение, т.е. не относятся к нашему сабжу.
Ваш пример ничего не демонстрирует, какая логика в нём перестаёт выполняться? Покажите, пожалуйста, хотя бы условный кусок кода "до" и "после" рефакторинга, когда в изменении логики виноват именно "тихий выход"? Бьюсь об заклад, что вы просто напишете неэквивалентный код, и проблема будет вовсе не в инвертировании условий с тихими выходами.
Действительно, могут быть куски кода, где 3 подряд подобных условия могли изначально влиять друг на друга или на выполнявшуюся логику, но человек, который эти условия добавляет, должен сам удостовериться в том, что все ветки кода имеют ту доступность, которая ожидается, а если какая-то ветка кода стала недостижимой из-за "тихого выхода", значит кто-то просто криво написал этот код. Не понимаю, как может быть иначе, буду признателен, если пример всё же будет.
Я считаю, что не сталкиваюсь с этими проблемами, потому что Ваши доводы нелогичны, а не по предположенным Вами причинам, но будет интересно ошибиться =)
Человек выше (@SAWER) по моему мнению написал какую-то бессмыслицу, а не аргументы.
Написал следующий абзац в самом в конце, но перетащил наверх, т.к. это самая суть:
Вообще, это всего лишь фича для улучшения читаемости кода, она ВООБЩЕ не меняет логику. А если всё-таки меняет, значит инвертирование условия выполнено некорректно и это уже не попадает под "радоваться выполненной задаче", т.к. на ревью тебе с вопросом "ты понимаешь, что это не эквивалентный код?" вернут задачу на доработку.
Далее имхо:
Я думаю, что если бы автор обсуждаемого комментария попытался написать примеры кода, иллюстрирующие его ошибочные аргументы, то он сумел бы сам себе их и опровергнуть. Мне тяжело представить работающий код, в котором были бы актуальны перечисленные проблемы.
К тому же выше речь не обязательно о "тихом выходе", когда
if (!...) { return; } // some stuff, там может возвращаться пустой массив, или просто короткий кусок логики.В общем виде я это вижу как "много логики внутри if, нужно попытаться инвертировать относительно мЕньшего количества логики вне if", а будет ли там пустой return, о котором сокрушается автор комментария выше или что-либо другое — это всегда вопрос логики и конкретного примера.
Я каждый день вижу много хорошего и плохого кода, простого и переусложнённого, и регулярно что-то перерабатываю и рефакторю, а также периодически возвращаю на доработку задачи с ошибками после ревью, и я никогда не сталкивался со сложностью понимания и переиспользования таких инверсий с "тихим" выходом из функции. Проект у нас на миллионы строк кода, поэтому Простора для возникновения описанных автором проблем там полно, однако самих Проблем всё же нет.
Технология всё ещё развивается, и вообще не предполагает 100% точных ответов сама по себе. Пользуйтесь ей правильно, и будете получать от неё соответствующую меру пользы.
Лично я не пытаюсь от ChatGPT получить "правильный ответ", я просто жду подсказку, и почти всегда получаю её. Она не может решить задачу, зато очень неплохо наталкивает на решение, хотя ей самой кажется, что решает, но на данном этапе развития это не так уж плохо.
О том и речь, что это не проблема ChatGPT, ему никто не программировал "характер", он не живое существо, а всего лишь генератор ответов, поэтому на вопрос всегда будет приходить ответ, а не оправдание, как в случае с человеком, и это логично в контексте ЯЗЫКОВОЙ МОДЕЛИ, которой он и является, и регулярно об этом напоминает.
ChatGPT — это инструмент. Он способен давать правильные ответы, если задавать корректные вопросы.
А если задавать некорректные вопросы и неуместным образом проверять результаты, то можно не заметить пользы от этого инструмента.
Вообще неважно, кто и как Называет ChatGPT, и как к этому инструменту относятся другие люди, важно то, чем он является. Я знаю много примеров, когда люди пользуются в своей проф.деятельности ChatpGPT как инструментом, я сам пользуюсь им, и он помогает, пусть даже пока не стабильно и не идеально, но помогает.
Как говорится "Хоть горшком назови, только в печь не ставь".
Ну, да. Спасибо. Я прочитал и ответ, которому я уже плюсанул.
Такое определение не слишком широко распространено, мягко говоря, поэтому дискутировать не получится.
Чтобы спор вышел плодотворным и приближал к объективной истине, терминология должна быть общая, иначе мы просто на разных языках разговариваем.
Но сложно поспорить, что стать изобретателем, первооткрывателем... творцом, если угодно — это вообще не каждому человеку под силу, хоть 10000 часов дай, хоть 100500... И это тоже за рамками дискуссии.
А по-моему это сравнение тёплого с мягким. Градация профессионального уровня и должностных обязанностей.
Например, в организации, где я работаю, есть чёткое разделение по грейдам (цифрами обозначаются) и должностям. И эти параметры совершенно не обязательно однозначно коррелируют.
Как раз не у всех сеньоров есть какая-то нагрузка по софт-скиллам (нежелающих вставать на соответствующие должности не таскают по собесам и не ставят наставниками к новичкам, например).
Дайте, пожалуйста, своё определение рангу "senior"? Можете в гугле почитать различные и подобрать наиболее удобное под вашу позицию, но уверен, что ни одно не будет противоречить тезису: "за 6 лет, РАБОТАЯ на работе, будучи эффективным сотрудником, которого ценят, которому регулярно поднимают зп, которого не хотят отпускать, невозможно НЕ СТАТЬ сеньором", — какое бы из общепринятых определений для этого термина Вы ни выбрали.
Да, не чистых 10 000 часов, и да — не все задачи в течение рабочего дня добавляют знаний/навыков, но в целом человек лучше всего воспринимает информацию именно из собственного опыта взаимодействия с этой информацией.
Личный опыт: я 5 лет учился на кафедре разработки ПО, потом 5 лет болтался "без дела" (фриланс, пет-проекты) и всё это время не был разработчиком по факту. Зато за 2 года реального "боевого" опыта в проектной разработке узнал и углубил прошлые знания на несколько порядков эффективнее, чем за все прошлые годы вместе взятые.
Не представляю, как можно НЕ СТАТЬ сеньором через ещё 4 долгих года... Надо либо найти токсичную организацию, которая настолько ненавидит своих сотрудников, чтобы у тебя не было опции взять интересную (читай, развивающую) задачу/проект или выделить время на самообучение в рабочее время, в т.ч. для того, чтобы выполнять более сложные задачи или выполнять небольшие более эффективно. Ну либо, если организация нормальная, то придётся самому настолько не хотеть достичь этого, что делать задачи спустя рукава и не интересоваться ничем новым.
Ну, у разработчиков вроде бы и так 6 часов отводится на активную разработку (у меня так, у моих знакомых также в нескольких организациях).
И почему Вы считаете, что это противоречит задаче "учиться программировать"?
так она же возит
>Не вижу из чего вы сделали такой вывод
Поддержу @Dolios, что в вашем первом комментарии просто не осталось пространства, чтобы понять иначе =)
Существуют люди, которым просто после работы на двух проектах на полный день одновременно не хватает времени "наследить" ещё и где-то в open-source, или просто развивают какой-то приватный pet-проект, не желая шарить его с общественностью.
Однако, если пустой гитхаб в вашем понимании — действительно не приговор для кандидата, то вероятно, что к Вам напрасно прицепились с этой темой.
P.S. По моему личному мнению, гитхаб, полный прекрасно написанного кода — печенька в копилку кандидата, но пустой гитхаб — просто ничего не говорит о кандидате. И сложилось оно у меня из личного опыта:
Не так давно попробовал походить по собеседованиям, календарный опыт у меня довольно скудный, гитхаб пустой. Я оставил 20 откликов (включая MindBox, которые забраковали меня за неучтённую точность double, дословно =)) и получил 19 отказов. А тот единственный собес в течение 15 минут уже сделал мне оффер как хорошему миддлу, притом что у меня неполных 2 года коммерческой разработки за плечами =)
Совершенно несостоятельный комментарий, акцентирующий внимание не на сути оспариваемого мнения, а на приведённом примере.
Если бы ему платили за то, что он учится играть на скрипке, и учит языки, то вероятно справился бы.
>Из примеров выше очевидно, что concurrent коллекции не дают полной защиты от race conditions
Лично я не готов согласиться, что из примеров выше что-то очевидно, особенно касательно concurrent-коллекций и race condition, т.к. приведенные примеры лишь демонстрируют несостоятельность классических коллекций к многопоточному применению. А очень хотелось бы такую демонстрацию, для того, чтобы это действительно стало очевидно.
Прекрасный совет!
Но как быть тем, у кого есть обстоятельства непреодолимой силы, препятствующие покиданию страны тем или иным способом?