Здравствуйте, Ватакуси, Вы писали:
В>Вот мне на вид поставили, что я не написал production ready code. В>Т.е., всё работает, всё правильно, но не production ready.
В>А в другом месте им camelCase не понравился. Это говорит противоречит стандарту :D
Здравствуйте, Ватакуси, Вы писали:
В>Вот мне на вид поставили, что я не написал production ready code. В>Т.е., всё работает, всё правильно, но не production ready.
А что такое в их понимании "production ready"? И чего вашему коду не хватило до него?
В>А в другом месте им camelCase не понравился. Это говорит противоречит стандарту :D
А есть какое-то единое соглашение по стилю написания кода с C++? Я вот изучал этот вопрос недавно. Как по мне там полный бардак (по сравнению с другими языками что я знаю) т.е. стандарта де-факто нет.
Мы были здесь. Но пора идти дальше. (с) Дуглас Коупленд, Рабы "Микрософт"
Здравствуйте, Closer, Вы писали:
C>А есть какое-то единое соглашение по стилю написания кода с C++? Я вот изучал этот вопрос недавно. Как по мне там полный бардак (по сравнению с другими языками что я знаю) т.е. стандарта де-факто нет.
В каждой нормальной конторе есть требования к стилю, и это правильно, потому что код, который каждый мимокрокодил пишет как ему вздумается, очень быстро превращается в помойку.
Здравствуйте, scf, Вы писали:
scf>Без подробностей сложно что-то сказать.
Да не сложно. Хоть snake_case хоть CamelCase, главное — единообразие. Требовать использовать стиль компании на собеседовании — бред. Говорить, что какой-то стиль это стандард — бред вдвойне.
Здравствуйте, Sealcon190, Вы писали:
S>В каждой нормальной конторе есть требования к стилю, и это правильно, потому что код, который каждый мимокрокодил пишет как ему вздумается, очень быстро превращается в помойку.
Только какое это отношение имеет к стандарту языка и собеседованию? Если у собеседующего подгорает, что кто-то за пределами компании использует другой стиль, то с такими людьми лучше не работать
Здравствуйте, Skorodum, Вы писали:
S>Да не сложно. Хоть snake_case хоть CamelCase, главное — единообразие. Требовать использовать стиль компании на собеседовании — бред. Говорить, что какой-то стиль это стандард — бред вдвойне.
Возможно, имели в виду стиль stdlib. Там, действительно, camelCase не любят, хотя кое-где он встречается.
Почему сразу не спросил, какой именно стандарт они имеют в виду?) Очевидно, что не Стандарт (который с большой буквы С)
Здравствуйте, Skorodum, Вы писали:
S>Только какое это отношение имеет к стандарту языка и собеседованию? Если у собеседующего подгорает, что кто-то за пределами компании использует другой стиль, то с такими людьми лучше не работать
А это точно с собеседования? Я никаких намёков не заметил, вроде чел адаптируется на новом месте уже?
Здравствуйте, Sealcon190, Вы писали:
S>В каждой нормальной конторе есть требования к стилю, и это правильно, потому что код, который каждый мимокрокодил пишет как ему вздумается, очень быстро превращается в помойку.
Я же не про это говорю, а про то, что в C++ этих соглашений "вагон да маленькая тележка". А какого-то общего соглашения принятого большинством нет (может я не прав конечно т.к. на C++ очень мало пишу, но ощущение сложилось именно такое).
Вот например ситуация с Clang-Tidy линтером. По сути, линтер должен за стилями следить и говорить как можно делать, а как нельзя. А ему пофиг написано у меня поле в структуре в lowerCameCase или UpperCamelCase формате (только что проверил). И таких правил для проверки у него нет т.к. у каждого свои соглашения по стилям кодирования.
Мы были здесь. Но пора идти дальше. (с) Дуглас Коупленд, Рабы "Микрософт"
Здравствуйте, Sealcon190, Вы писали:
S>А это точно с собеседования? Я никаких намёков не заметил, вроде чел адаптируется на новом месте уже?
Не знаю, но мне кажется, что он говорит однозначно о собеседованиях
В>>Вот мне на вид поставили, что я не написал production ready code. В>>Т.е., всё работает, всё правильно, но не production ready.
C>А что такое в их понимании "production ready"? И чего вашему коду не хватило до него?
Сложно сказать наверняка, ибо мне ответ дали на английском и писал человек его не очень хорошо знающий. Но похоже, им нужно было всё в контейнеры завернуть, устроить устойчивый кластер, подумать о петафлопах и самое главное в readme написать как я решал задачу.
Всё это совершенно не оговаривалось заранее, более того было сказано "тебе выбирать решение".
В>>А в другом месте им camelCase не понравился. Это говорит противоречит стандарту :D
C>А есть какое-то единое соглашение по стилю написания кода с C++? Я вот изучал этот вопрос недавно. Как по мне там полный бардак (по сравнению с другими языками что я знаю) т.е. стандарта де-факто нет.
Это вообще по Яве было собеседование, но спрашивали про питон :D
Здравствуйте, Ватакуси, Вы писали:
В>>>Вот мне на вид поставили, что я не написал production ready code. В>>>Т.е., всё работает, всё правильно, но не production ready.
C>>А что такое в их понимании "production ready"? И чего вашему коду не хватило до него? В>Сложно сказать наверняка, ибо мне ответ дали на английском и писал человек его не очень хорошо знающий. Но похоже, им нужно было всё в контейнеры завернуть, устроить устойчивый кластер, подумать о петафлопах и самое главное в readme написать как я решал задачу. В>Всё это совершенно не оговаривалось заранее, более того было сказано "тебе выбирать решение".
В>>>А в другом месте им camelCase не понравился. Это говорит противоречит стандарту :D
C>>А есть какое-то единое соглашение по стилю написания кода с C++? Я вот изучал этот вопрос недавно. Как по мне там полный бардак (по сравнению с другими языками что я знаю) т.е. стандарта де-факто нет. В>Это вообще по Яве было собеседование, но спрашивали про питон :D
Вот поэтому я и не верю в байки про "нехватку программистов". 2020-й год на дворе, а большинство собеседований — фейспалм...
Здравствуйте, Closer, Вы писали:
C>А есть какое-то единое соглашение по стилю написания кода с C++? Я вот изучал этот вопрос недавно. Как по мне там полный бардак (по сравнению с другими языками что я знаю) т.е. стандарта де-факто нет.
Ну может не по стилю, но по тому как надо писать таки есть.
Здравствуйте, kaa.python, Вы писали:
KP>Здравствуйте, Closer, Вы писали:
C>>А есть какое-то единое соглашение по стилю написания кода с C++? Я вот изучал этот вопрос недавно. Как по мне там полный бардак (по сравнению с другими языками что я знаю) т.е. стандарта де-факто нет.
KP>Ну может не по стилю, но по тому как надо писать таки есть.
Кстати, классная штука для разрешения любых холиваров.
Как только начинаются споры вокруг код ревью насчет того как передавать смарт поинтеры в функции — даешь народу ссылку на пункт в CoreGuidelines — и все успокаиваются
Здравствуйте, Sealcon190, Вы писали:
S>В каждой нормальной конторе есть требования к стилю, и это правильно, потому что код, который каждый мимокрокодил пишет как ему вздумается, очень быстро превращается в помойку.
Но только трудно ожидать, что соискатель прям на собеседовании научет писать в стиле, принятом в данной конторе.
Здравствуйте, Skorodum, Вы писали:
S>Здравствуйте, scf, Вы писали:
scf>>Без подробностей сложно что-то сказать. S>Да не сложно. Хоть snake_case хоть CamelCase, главное — единообразие. Требовать использовать стиль компании на собеседовании — бред. Говорить, что какой-то стиль это стандард — бред вдвойне.
Это еще что, я помню был случай, дали тестовое задание, а потом отказ мотивировали тем, что типа в коммитах гита не виден прогресс работы, типа надо было не одним коммитом заливать тестовое задание, а после каждой строчки делать коммиты, да еще не в мастере
Короче эти уроды если хотят отказать всегда найдут тысячу и одну причину.
Один раз мне вообще заявили, что отказывают потому, что у меня в коде тестового задания было разное кол-во пробелов-строк между методами — где-то 2, а где-то аж 3!
Здравствуйте, UrgentUnixAdmin, Вы писали:
UUA>Это еще что, я помню был случай, дали тестовое задание, а потом отказ мотивировали тем, что типа в коммитах гита не виден прогресс работы, типа надо было не одним коммитом заливать тестовое задание, а после каждой строчки делать коммиты, да еще не в мастере
Если тестовое задание большое или явно оговоренно использование гита, то вполне логично желание увидеть историю разработки и умение пользоваться гитом.
UUA>Короче эти уроды если хотят отказать всегда найдут тысячу и одну причину.
Отказали -> "уроды"?
UUA>Один раз мне вообще заявили, что отказывают потому, что у меня в коде тестового задания было разное кол-во пробелов-строк между методами — где-то 2, а где-то аж 3!
Вряд ли именно поэтому, но "не аккуратное форматирование" — еще один штрих
З.Ы. IMHO, больше одной пустой строки не нужно никогда.
Здравствуйте, Faland, Вы писали:
F>Вот поэтому я и не верю в байки про "нехватку программистов". 2020-й год на дворе, а большинство собеседований — фейспалм...
Тут фейспалм работодателей. В процессе поиска и найма разрабов заняты толпы номенклатурных бездарей, собеседующих для создания вида деятельности и действующих по модным и молодёжным букварям.
А программистов да, нехатка, собственно, поэтому упомянутые деятели и имеют возможность вести свою кипучую деятельность.
Здравствуйте, kaa.python, Вы писали:
KP>Ну может не по стилю, но по тому как надо писать таки есть.
https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines
...
NL.10: Prefer underscore_style names
...
must follow an established style for consistency
Здравствуйте, Ватакуси, Вы писали:
В>Сложно сказать наверняка, ибо мне ответ дали на английском и писал человек его не очень хорошо знающий. Но похоже, им нужно было всё в контейнеры завернуть, устроить устойчивый кластер, подумать о петафлопах и самое главное в readme написать как я решал задачу. В>Всё это совершенно не оговаривалось заранее, более того было сказано "тебе выбирать решение".
Согласен, странно требовать от тестового задания решения "production ready" уровня. Тем более если это явно не сказано.
Да и сам термин довольно размыт. У меня бы это означало что нужно логирование нормально сделать, health-check-и добавить, мониторинг, всякие corner cases проверить и т.п., а нужны ли там контейнеры, HA и пр. это уже надо по заданию смотреть.
В>Это вообще по Яве было собеседование, но спрашивали про питон :D
Понятно, умные указатели сбили меня с толку
Мы были здесь. Но пора идти дальше. (с) Дуглас Коупленд, Рабы "Микрософт"
S>https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines
S>...
S>NL.10: Prefer underscore_style names
S>...
S>must follow an established style for consistency
S>
Вот это интереснее:
NL.8: Use a consistent naming style
Rationale: Consistence in naming and naming style increases readability.
Note
There are many styles and when you use multiple libraries, you can’t follow all their different conventions. Choose a “house style”, but leave “imported” libraries with their original style.
т.е. получается я прав и с соглашениями по именованию в С++ бардак т.е. какого-то единого или доминируещего соглашения нет, поэтому придумывайте своё соглашение и используйте его в своём коде. Грубо говоря, получается: сколько компаний столько и соглашений. Как-то грустно это выглядит.
Мы были здесь. Но пора идти дальше. (с) Дуглас Коупленд, Рабы "Микрософт"
Здравствуйте, smeeld, Вы писали:
S>Для подростающего молодняка, продакшон код означает упаковаанность в докер, ибо так в очередном новомодном букваре от очередного болтуна написано.
Нет, что вы. Контейнеры, Docker, k8s и пр. это всё для таких старперов как я Подрастающее поколение сейчас интересуется serverless архитектурой, хотя вроде и этот хайп уже на исходе
Мы были здесь. Но пора идти дальше. (с) Дуглас Коупленд, Рабы "Микрософт"
Здравствуйте, Skorodum, Вы писали:
S>Если тестовое задание большое или явно оговоренно использование гита, то вполне логично желание увидеть историю разработки и умение пользоваться гитом.
Еще логичнее озвучить заранее желание видеть коммит после каждой новой строчки. У людей в конце-концов разные стили работ бывают. Гит же использовали вроде.
UUA>>Короче эти уроды если хотят отказать всегда найдут тысячу и одну причину. S>Отказали -> "уроды"?
Если отказ только по этой причине, то это действительно, странные люди. Но скорее он им просто не понравился, прямо же так сказать обычно нельзя, вот и придумывают в таких случаях разные причины.
UUA>>Один раз мне вообще заявили, что отказывают потому, что у меня в коде тестового задания было разное кол-во пробелов-строк между методами — где-то 2, а где-то аж 3! S>Вряд ли именно поэтому, но "не аккуратное форматирование" — еще один штрих
S>З.Ы. IMHO, больше одной пустой строки не нужно никогда.
Здравствуйте, Michael7, Вы писали:
M>Почему? Чисто для облегчения чтения.
Смотря где эта пустая строка. Если так предусмотрено стандартом или общепринятыми правилами, то ладно. Но вот когда пустая строка встретилась внутри метода/процедуры/функции, это прямо беда. Это просто расширяет границы экрана, и проплачено производителями мониторов. Когда читаешь такой код "через столетия", всегда хочется спросить у автора, что он имел ввиду. Ну потому что, если он отделил одну часть кода от другой, то ему следовало написать комментарий, чем эти части отличаются. Ну или поделиться откатами с теми, кто такой код читает после него.
Здравствуйте, Ватакуси, Вы писали:
В>Вот мне на вид поставили, что я не написал production ready code. В>Т.е., всё работает, всё правильно, но не production ready.
В>А в другом месте им camelCase не понравился. Это говорит противоречит стандарту :D
Если это всё на собеседовании и в тестовом задании — так радуйся, что не попал туда.
Здравствуйте, Michael7, Вы писали:
M>Еще логичнее озвучить заранее желание видеть коммит после каждой новой строчки.
Нет. Дело не в размере коммита, а в минимальном логичном и целостном изменении. Коммит может быть и 1000 строк, а может быть и один символ. Собственно, эта дискуссия хорошо демонстрирует проблему.
M>У людей в конце-концов разные стили работ бывают.
Во-во и некоторые стили в команду лучше не брать, т.к. переучивать "сеньёров" на нормальное пользование системой контролей версий дело очень неблагодарное
M>Если отказ только по этой причине, то это действительно, странные люди.
В общем случае каким бы хорошим кандидат не был, всегда есть вероятность, что был кто-то БОЛЕЕ ПОДХОДЯЩИЙ конкретно им. Отказ — это совершенно нормально, детальный feedback — вообще круто.
M>Но скорее он им просто не понравился, прямо же так сказать обычно нельзя, вот и придумывают в таких случаях разные причины.
Да это все домыслы. Надо не искать виртуальные причины для обиды, а понять, почему кто-то оказался более подходящим.
S>>З.Ы. IMHO, больше одной пустой строки не нужно никогда. M>Почему? Чисто для облегчения чтения.
Чтение это никак не облегачает, а вот непоследовательность в использовании пустых строк будет лишним раздражителем.
Сложно формализировать когда использовать одну пустую строку, а когда больше. Поэтому всем проще если всегда только одна пустая строка.
Здравствуйте, smeeld, Вы писали:
S>Для подростающего молодняка, продакшон код означает упаковаанность в докер, ибо так в очередном новомодном букваре от очередного болтуна написано.
Если к проекту идет контейнер который позволяет его намного проще собрать и запустить, то это однозначно большой плюс. Разве нет?
Здравствуйте, Closer, Вы писали:
C>т.е. получается я прав и с соглашениями по именованию в С++ бардак т.е. какого-то единого или доминируещего соглашения нет, поэтому придумывайте своё соглашение и используйте его в своём коде. Грубо говоря, получается: сколько компаний столько и соглашений. Как-то грустно это выглядит.
Да нормально. Если два основных формализованных и логичных стиля: Qt — CamelCase и stl/boost — snake_case. Есть извращенцы которые их мешают, есть извращены которые любят подчеркивания в начале или в конце, код превращаеся в азбуку Морзе: variable_._another_variable
Здравствуйте, Skorodum, Вы писали:
S>Если к проекту идет контейнер который позволяет его намного проще собрать и запустить, то это однозначно большой плюс. Разве нет?
Нет. Софт должен распростарняться в пакетах под конкретную ОС. Деплоить софт вместе с образами системного окружения ОС-это эра засилья безмозглых девляпсов. Докер-это прежде всего система контейнерной виртуализации и изоляции приложений. Самая худшая из всех, которые сть (solaris zone, freebsd jail, linux openvz). Просто пример того, как нельзя делать. В способ распространения и деплоя софта докер превратили уже потом, те самые девляпсы.
Здравствуйте, smeeld, Вы писали:
S>Нет. Софт должен распростарняться в пакетах под конкретную ОС. Деплоить софт вместе с образами системного окружения ОС-это эра засилья безмозглых девляпсов. Докер-это прежде всего система контейнерной виртуализации и изоляции приложений. Самая худшая из всех, которые сть (solaris zone, freebsd jail, linux openvz). Просто пример того, как нельзя делать. В способ распространения и деплоя софта докер превратили уже потом, те самые девляпсы.
Да вы спорите с какими-то своими тараканами. Напомню, что разговор про тестовые задания. С учетом того, что в плюсовом мире нет станадартов на сборку и управление зависимостями, предоставление готового образа для демонстрации это признак вежливости и профессионализма.
Здравствуйте, Skorodum, Вы писали:
>С учетом того, что в плюсовом мире нет станадартов на сборку и управление зависимостями, предоставление готового образа для демонстрации это признак вежливости и профессионализма.
Предоставить rpm и rpms, или deb пакеты. Это всё, что нужно.
Здравствуйте, smeeld, Вы писали:
S>Предоставить rpm и rpms, или deb пакеты. Это всё, что нужно.
Для системного софта — норм, для прикладного — не, лучше контейнер.
Иначе будешь потом все эти rpm/deb переделывать на каждый чих при обновлениях ОС (в т.ч. минорных)
Здравствуйте, smeeld, Вы писали:
S>Предоставить rpm и rpms, или deb пакеты. Это всё, что нужно.
Категоричное утверждение.... В вашем мире розовых понигиков:
1. На винде и маке разработки не ведется?
2. Всегда есть все необходимые версии?
3. Нет никаких конфликтов с уже установленными пакетами?
Здравствуйте, Skorodum, Вы писали:
S>Категоричное утверждение.... В вашем мире розовых понигиков:
Так в мире софта для тырпрайза, а не всякой модномолодёжной эфемерной чухни.
S>1. На винде и маке разработки не ведется?
Линуксы и юниксы.
S>2. Всегда есть все необходимые версии?
Всегда. Синдромом тащить на каждый чих новомодную либу самой распоследней версии никто не страдает в принудительном порядке.
S>3. Нет никаких конфликтов с уже установленными пакетами?
В рамках мажорных версий дистров каждой из используемых ОС нет. Ибо используются только штатные пакеты дистра.
совсем не эфемерные радары, разработчики сидят на всех платформах и используем мы 5 разных компиляторов.
S>>1. На винде и маке разработки не ведется? S>Линуксы и юниксы.
Ну так это 5-10% разработчиков максимум.
S>>2. Всегда есть все необходимые версии? S>Всегда. Синдромом тащить на каждый чих новомодную либу самой распоследней версии никто не страдает в принудительном порядке.
Ну вот например, Matlab это новомодная либа?
S>>3. Нет никаких конфликтов с уже установленными пакетами? S>В рамках мажорных версий дистров каждой из используемых ОС нет. Ибо используются только штатные пакеты дистра.
Это в теории, а на практике при более-менее сложно разработке конфликты очень часто бывают и нервы сильно портят.
совсем не эфемерные радары, разработчики сидят на всех платформах и используем мы 5 разных компиляторов.
Хочу рассказать о норвежском высокотехнологичном стартапе: Novelda.
Как раз оно самое и есть, ефемерное и модномолодёжное. Тема может и не молодёжная, но сам проект просто истекает смузями.
S>Ну так это 5-10% разработчиков максимум.
Это компании, владеющие 95%-ами фин. ресурсов планеты, и на которые приходится столько же процентов оборота в IT.
S>Ну вот например, Matlab это новомодная либа?
Мы о серверном или о десктоповом софте говорим? Я о серверном.
S>Это в теории, а на практике при более-менее сложно разработке конфликты очень часто бывают и нервы сильно портят.
Только если пользоваться пакетами из васянских реп. При использовании пакетов из штатных реп такого не бывает.
Здравствуйте, smeeld, Вы писали:
S>Как раз оно самое и есть, ефемерное и модномолодёжное.
Точно, раз радиоволны же эфимерны
S>Тема может и не молодёжная, но сам проект просто истекает смузями.
У вас какая-то фобия на смузи? Они есть у нас на ланч
S>>Ну так это 5-10% разработчиков максимум. S>Это компании, владеющие 95%-ами фин. ресурсов планеты, и на которые приходится столько же процентов оборота в IT.
Громкое и ни чем не подтвержденное заявление.
S>>Ну вот например, Matlab это новомодная либа? S>Мы о серверном или о десктоповом софте говорим? Я о серверном.
Да о любом, какая разница где он физически находится
S>Только если пользоваться пакетами из васянских реп. При использовании пакетов из штатных реп такого не бывает.
Это, мягко говоря, не так.
