Здравствуйте, Дарней, Вы писали:
Д>не бывает "сишников" и "не-сишников", бывают только "просто программисты". А разводить лишние непонятности в программе — это от дури и желания выпендриться.
Если следовать этой логике, то предлагается отказаться:
— от оператора ?, т.к. этот непонятный элемент присутствует только в С и отсутствует в других языках;
— от оператора switch, т.к. "просто программист" может не понимать, что означает отсутствие break после очередной ветки case;
— от оператора for, т.к. его гибкая трехсекционная организация может быть непонятна "просто программисту";
— от перегрузки фукнций, т.к. множество функций с одинаковым названием, несомненно, вносят "лишние непонятности";
— ...
Список можно продолжать. Особенно если определиться с той гранью, которая отличает "дурь и желание выпендриться" от "нормального стиля программирования". Какие будут предложения по определению этой грани?
Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>Здравствуйте, jhfrek, Вы писали:
ГВ>>>Кстати, пример с итераторами и постинкрементами уж куда как каноничен. Практически, копия ARM-овского варианта. J>>Каноничен для человека, воспитанного Страуструпом. А если этот код будет пытаться понять не Сишник(такое, кстати, бывает) — ему прийдется много думать, в отличии от CopyTo(source, dest)
ГВ>Вывод: не надо тащить на поддержку C++-ных проектов кого попало.
Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>А с другой стороны, риск посадить трудноотлавливаемую ошибку за счёт кастрации инструмента ещё не понятно как сопоставим, например, с риском посадить трудноотлавливаемую ошибку из-за состязаний в многопоточной программе. Так что, одно абстрактное рассуждение супротив другого.
Легко сопоставим. Решение обоих значительно зависит от скорости разбирательства в коде и времени, оставшегося после знакомства с ним. Конечно, если кастрировать язык с ущербом для этой характеристики, то это только повредит.
Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>Странный у тебя какой-то вывод. Если код не понятен "не Сишнику", то значит — это выпендрёж. ИМХО, справедливый вывод здесь: нечего "не Сишнику" делать на поддержке "сишных" проектов. И уж тем более нечего ему делать на поддержке проектов на C++.
Читать все равно бывает нужно. Типичная ситуация, когда приходится прыгать с языка на язык, и выучивать новый за несколько дней в той мере, чтобы поддерживать проект. С одной стороны, все детали за это время не изучишь. С другой стороне, при аккуратном написании этих знаний достаточно для решения задачи. Так зачем все усложнять ? C++ — только один из кучи языков, с которыми приходится иметь дело, и в последнее время мне с ним дело иметь не приходится. Вон, на следующей неделе придется с места в карьер изучать .NET и поддерживать проект. Не впервой, провусь. Другим на предыдущей работе давали задачку писать парсер XML. Писали, успешно. Попутно изучали XML.
Здравствуйте, Александр Каширин, Вы писали:
Д>>не бывает "сишников" и "не-сишников", бывают только "просто программисты". А разводить лишние непонятности в программе — это от дури и желания выпендриться.
АК>Если следовать этой логике, то предлагается отказаться:
АК>- от оператора ?, т.к. этот непонятный элемент присутствует только в С и отсутствует в других языках; АК>- от оператора switch, т.к. "просто программист" может не понимать, что означает отсутствие break после очередной ветки case; АК>- от оператора for, т.к. его гибкая трехсекционная организация может быть непонятна "просто программисту"; АК>- от перегрузки фукнций, т.к. множество функций с одинаковым названием, несомненно, вносят "лишние непонятности"; АК>- ...
АК>Список можно продолжать. Особенно если определиться с той гранью, которая отличает "дурь и желание выпендриться" от "нормального стиля программирования". Какие будут предложения по определению этой грани?
Главное, следить за балансом пользы/вреда. Для каких-то вещей достаточно потребовать, чтобы их было мало (что такое мало, обычно вопросов не возникает), а для оставшихся попросить быть готовым предоставить обоснование с одобрением непосредственного руководителя. Все перечисленное — общее место, оно разбирается во время изучения C и перехода к C++, и потом распространяется на остальные языки, если там такие фичи есть. Пока еще эт этого ставшего традиционным порядка язучения языков не отошли. Вот когда отойдут, тогда ваш вопрос может оказаться не столь риторическим.
С другое стороны, что мешает запретить триграфы ? Вы, например, хорошо помните, что это такое ?
Здравствуйте, kittown, Вы писали:
K>Здравствуйте, Александр Каширин, Вы писали:
АК>>Список можно продолжать. Особенно если определиться с той гранью, которая отличает "дурь и желание выпендриться" от "нормального стиля программирования". Какие будут предложения по определению этой грани?
K>Главное, следить за балансом пользы/вреда. Для каких-то вещей достаточно потребовать, чтобы их было мало (что такое мало, обычно вопросов не возникает), а для оставшихся попросить быть готовым предоставить обоснование с одобрением непосредственного руководителя. K>... K>С другое стороны, что мешает запретить триграфы ? Вы, например, хорошо помните, что это такое ?
Совершенно согласен. Надо только понимать, где тот баланс пользы и вреда. Если решение этого вопроса отдано на усмотрение непосредственного руководителя — то я согласен и с этим решением.
Да, собственно, мой предыдущий ответ был скорее на тему "просто программистов не си-шников", и я хотел показать, что "просто программисту" в любом случае предстоит стать "си-шником", чтобы разбираться в С-шных проектах. Что Дарней опровергает
Здравствуйте, Александр Каширин, Вы писали:
АК>Да, собственно, мой предыдущий ответ был скорее на тему "просто программистов не си-шников", и я хотел показать, что "просто программисту" в любом случае предстоит стать "си-шником", чтобы разбираться в С-шных проектах. Что Дарней опровергает
С++ слишком часто превращают в птичий язык, вот что я хочу сказать. Пример с мегаупакованным циклом копирования — один из ярких примеров. Вместо того, чтобы написать одну функцию копирования и использовать, люди занимаются фигней
Здравствуйте, Дарней, Вы писали:
Д>Вместо того, чтобы написать одну функцию копирования и использовать, люди занимаются фигней
Трудно не согласиться. Особенно если речь идет о каком-то обозримом количестве функций. (Кстати, функция, заменяющая код этого примера, существует испокон веков и называется strcpy).
Однако я думал, что речь идет не о конкретной функции копирования буфера, а о применении инкрементов указателей прямо в выражении с разыменованием указателя. А таких применений бесконечно много: на все случаи жизни функций не напишешься.
У кого-то тут видел интересную подпись: "Любая проблема дизайна может быть решена добавлением нового абстрактного слоя, кроме проблемы слишком большого количества абстрактных слоев" Как бы с функциями не напороться на подобную ситуацию.
Здравствуйте, Privalov, Вы писали:
Д>>пожалуй, так оно и есть. Обычная история о сапожнике, который взялся пироги печь. P>Скорее, взялся возглавить сапожное производство — там от него избавиться намного сложнее.
Т.е. бывший программист, взявшийся возглавить процесс разработки, это плохо?
Здравствуйте, kittown, Вы писали:
ГВ>>Странный у тебя какой-то вывод. Если код не понятен "не Сишнику", то значит — это выпендрёж. ИМХО, справедливый вывод здесь: нечего "не Сишнику" делать на поддержке "сишных" проектов. И уж тем более нечего ему делать на поддержке проектов на C++.
K>Читать все равно бывает нужно. Типичная ситуация, когда приходится прыгать с языка на язык, и выучивать новый за несколько дней в той мере, чтобы поддерживать проект. С одной стороны, все детали за это время не изучишь. С другой стороне, при аккуратном написании этих знаний достаточно для решения задачи. Так зачем все усложнять ?
Неправильный вывод. Это означает, что поддержка программы требует определённой квалификации сопровождающего программиста. С этой работой, конечно, управится и новичок, но только ему придётся чуть подольше почитать мануалы.
А то мы так докатимся, что "лучше, проще и яснее" писать malloc/free и lock/unlock чем пользоваться деструкторами. Ясен пень, тут же мануалы читать надо. За шаблоны вообще лучше промолчу.
K>C++ — только один из кучи языков, с которыми приходится иметь дело, и в последнее время мне с ним дело иметь не приходится.
И что с того? А мне приходится. И избыточно упрощать код в расчёте на то, что я отдам его первоклассникам у меня нет ровным счётом никакой мотивации.
K>Вон, на следующей неделе придется с места в карьер изучать .NET и поддерживать проект. Не впервой, провусь. Другим на предыдущей работе давали задачку писать парсер XML. Писали, успешно. Попутно изучали XML.
Ну что же, рад за всех вас.
<< Под музыку: Аквариум — Бессмертная Сестра Хо >>
<< При помощи Януса: 1.2.0 alpha rev. 650 >>
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, Геннадий Васильев, Вы писали:
K>>Читать все равно бывает нужно. Типичная ситуация, когда приходится прыгать с языка на язык, и выучивать новый за несколько дней в той мере, чтобы поддерживать проект. С одной стороны, все детали за это время не изучишь. С другой стороне, при аккуратном написании этих знаний достаточно для решения задачи. Так зачем все усложнять ?
ГВ>Неправильный вывод. Это означает, что поддержка программы требует определённой квалификации сопровождающего программиста. С этой работой, конечно, управится и новичок, но только ему придётся чуть подольше почитать мануалы.
Опять 25. Повторяю то, что уже говорил, другими словами.
Берем неквалифицированного программиста с книжкой в руках. Даем ему сложный и простой код одинаковой функиональности. Первый он поправит, допустим, за полчаса, а второй за десять минут. Возьмем программиста высокой квалификации. Сложный код он будет править минут минут пять, а простой — две минуты. При одинаковой функциональности. Вопрос, зачем в таких условиях писать сложный код ?
Эти условия соответствует большинству попадавшихся мне реальных ситуаций. Профессионалу высокой квалификации сложный код точно так же не нужен, как и начинающему. Исключение — воинствующие эстеты, которым нравятся красивости, но которые при этом время не считают.
ГВ>А то мы так докатимся, что "лучше, проще и яснее" писать malloc/free и lock/unlock чем пользоваться деструкторами. Ясен пень, тут же мануалы читать надо. За шаблоны вообще лучше промолчу.
Простота и доступность каждой фичи оценивается исходя из практики, а не берется с потолка. Деструкторы — проще, чем malloc/free, особенно если запретить невиртуальные деструкторы. А без шаблонов в основном коде жить вполне можно, оставив их только в библиотеках. Хотя любителям монолитных приложений этого не понять.
K>>C++ — только один из кучи языков, с которыми приходится иметь дело, и в последнее время мне с ним дело иметь не приходится.
ГВ>И что с того? А мне приходится. И избыточно упрощать код в расчёте на то, что я отдам его первоклассникам у меня нет ровным счётом никакой мотивации.
Значит займетесь чем-то другим, а засабмиченный вами код может оказаться откачен. Никаких проблем или претензий, просто качество кода имеет вполне определенное средство измерения — степень соответствия предьявляемым требованиям. Если ваш код требованиям компании не соответствует, значит, он некачественен, вне зависимости от вашей субьективной его оценки.
Здравствуйте, kittown, Вы писали:
K>Берем неквалифицированного программиста с книжкой в руках. Даем ему сложный и простой код одинаковой функиональности. Первый он поправит, допустим, за полчаса, а второй за десять минут. Возьмем программиста высокой квалификации. Сложный код он будет править минут минут пять, а простой — две минуты...
Не, я бы сказал, что простой — 10 минут Просто потому что его больше
Здравствуйте, Александр Каширин, Вы писали:
K>>Берем неквалифицированного программиста с книжкой в руках. Даем ему сложный и простой код одинаковой функиональности. Первый он поправит, допустим, за полчаса, а второй за десять минут. Возьмем программиста высокой квалификации. Сложный код он будет править минут минут пять, а простой — две минуты...
АК>Не, я бы сказал, что простой — 10 минут Просто потому что его больше
Основная часть простого кода просто скипается за ненадобностью вносить в него изменения или разбираться в нем. И наоборот, если попадается мудреный компактный код, то приходится делать его некомпактным, иначе трудно изменять. В результате обьем работы по изменениям, несмотря на меньший исходный код, оказывается больше. В частности, регулярно приходилось разламывать компактные if-ы с множеством условий в одном месте, изничтожать многочисленные return и оставлять один, и тому подобное, иногда даже добавлять буленовые флаги, как в приводившемся тут примере. Если же условия были бы разбиты на вложенные if-ы изначально, анализировать и разбирать пришлось бы меньше.
Что до темплейтов и особенно частичной специализации и похожих на них фич, то из-за них постоянно приходилось лезть в сорсы. Есть ситуации, когда вывод о работоспособности кода делается после запуска тестов, а есть ситуации, когда это недостаточно убедительно и надо проследить всю логику обработки конкретного типа запроса, включая альтернативные ветки. В последнем случае чем проще код, тем лучше.
Если нужны красивые фичи, то для этого есть более другие языки — Erlang, OCaml. Там они родные. А в C++ висят словно заплатки на старом штопаном кафтане и только мешают.
Здравствуйте, Александр Каширин, Вы писали:
K>>[...] Возьмем программиста высокой квалификации. Сложный код он будет править минут минут пять, а простой — две минуты...
АК>Не, я бы сказал, что простой — 10 минут Просто потому что его больше
Вот! Как раз в этом-то и дело.
<< Под музыку: silent >>
<< При помощи Януса: 1.2.0 alpha rev. 650 >>
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, kittown, Вы писали:
ГВ>>Неправильный вывод. Это означает, что поддержка программы требует определённой квалификации сопровождающего программиста. С этой работой, конечно, управится и новичок, но только ему придётся чуть подольше почитать мануалы.
K>Опять 25. Повторяю то, что уже говорил, другими словами.
K>Берем неквалифицированного программиста с книжкой в руках. Даем ему сложный и простой код одинаковой функиональности. Первый он поправит, допустим, за полчаса, а второй за десять минут. Возьмем программиста высокой квалификации. Сложный код он будет править минут минут пять, а простой — две минуты. При одинаковой функциональности. Вопрос, зачем в таких условиях писать сложный код ?
Александр Каширин очень точно подметил особенность простого кода. Вы никогда не сталкивались с проектами на десяток мегабайт очень-очень простого кода, где зависимости проявляются в самых неожиданных местах?
K>Эти условия соответствует большинству попадавшихся мне реальных ситуаций. Профессионалу высокой квалификации сложный код точно так же не нужен, как и начинающему. Исключение — воинствующие эстеты, которым нравятся красивости, но которые при этом время не считают.
Да я тоже как-то не ратую за красоты ради красот. Просто наперёд трудно знать, что именно потребуется из механизмов C++. Потому мне и кажется глупостью превентивный запрет на что-то, мотивированный борьбой с "красотами ради красот". То есть механизм языка здесь неправомерно приравнивается к "красивостям", только и всего.
ГВ>>А то мы так докатимся, что "лучше, проще и яснее" писать malloc/free и lock/unlock чем пользоваться деструкторами. Ясен пень, тут же мануалы читать надо. За шаблоны вообще лучше промолчу.
K>Простота и доступность каждой фичи оценивается исходя из практики, а не берется с потолка. Деструкторы — проще, чем malloc/free, особенно если запретить невиртуальные деструкторы.
Даже в сугубо инлайновых классах тоже нужно запрещать невиртуальные деструкторы? Это чтобы у любого класса была VMT или ещё зачем-то?
K>А без шаблонов в основном коде жить вполне можно, оставив их только в библиотеках. Хотя любителям монолитных приложений этого не понять.
Да ну? А RAII-обёртки как же?
K>>>C++ — только один из кучи языков, с которыми приходится иметь дело, и в последнее время мне с ним дело иметь не приходится. ГВ>>И что с того? А мне приходится. И избыточно упрощать код в расчёте на то, что я отдам его первоклассникам у меня нет ровным счётом никакой мотивации.
K>Значит займетесь чем-то другим, а засабмиченный вами код может оказаться откачен. [...]
А с чего вы взяли, что я пойду работать в такую компанию, а если и пойду, то буду нарушать установленные в ней правила? Просто вы говорите, что, мол, сталкиваетесь с тем-то и тем-то, я тоже делюсь своими наблюдениями.
<< Под музыку: silent >>
<< При помощи Януса: 1.2.0 alpha rev. 650 >>
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, Eurispheus, Вы писали:
Д>>>пожалуй, так оно и есть. Обычная история о сапожнике, который взялся пироги печь. P>>Скорее, взялся возглавить сапожное производство — там от него избавиться намного сложнее.
E>Т.е. бывший программист, взявшийся возглавить процесс разработки, это плохо?
Обобщать нельзя, но зачастую ситуация напоминает "потеряли хорошего программиста и получили паршивого менеджера".
<< Под музыку: silent >>
<< При помощи Януса: 1.2.0 alpha rev. 650 >>
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>Обобщать нельзя, но зачастую ситуация напоминает "потеряли хорошего программиста и получили паршивого менеджера".
Но еще хуже, когда хороший менеджер превращается в никудышного тим лида или например архитектора.
Здравствуйте, kittown, Вы писали:
K>В результате обьем работы по изменениям, несмотря на меньший исходный код, оказывается больше. В частности, регулярно приходилось разламывать компактные if-ы с множеством условий в одном месте, изничтожать многочисленные return и оставлять один, и тому подобное, иногда даже добавлять буленовые флаги, как в приводившемся тут примере. Если же условия были бы разбиты на вложенные if-ы изначально, анализировать и разбирать пришлось бы меньше.
Мне как раз показалось наоборот: в приведенном примере с булевскими флагами код значительно сложнее для анализа и хуже структурирован.
K>Есть ситуации, когда вывод о работоспособности кода делается после запуска тестов, а есть ситуации, когда это недостаточно убедительно и надо проследить всю логику обработки конкретного типа запроса, включая альтернативные ветки. В последнем случае чем проще код, тем лучше.
Насколько мне известно, тестирование как раз и придумано потому, что человек не в состоянии безошибочно проанализировать поведение программы на основании code review — он все равно чего-то не заметит. Так "может в консерватории что-то подправить"? (с) М.Жванецкий Я имею в виду, может тест-кейсы переработать и дополнить?
