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

LMA>Повторю: писать код, который легок для понимания квалифицированным программистом быстрее (а еще приятнее), чем код, понимаемый любым программистом.

Я, кажется, понял, в чём корень разногласий. Чем больше людей может легко понимать и поддерживать код, решающий какую-то конкретную задачу, тем качественнее этот код написан.
Конечно понятно, что более качественный код писать сложнее и дольше. В этом ничего удивительного нет. И при тарет ресурсов на разработку надо искать комперомисс между трудозатратами и качеством кода.
Но преднамеренно тратить ресурсы на осознанное снижение качества кода -- всё таки это явный и злонамеренный саботаж!

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

LMA>Я про себя ничего не писал. Но я действительно считаю, что если человек не знает приоритеты операторов в C++, то язык он не знает. Некоторых других языков программирования это, кстати, касается в меньшей степени.

Кстати, не хочу тебя расстраивать, но в С++ приоритетов у операторов нет
Если тебе так не кажется, то можешь расставить приоритеты в этом вот выражении:

p, q ? p, q : p, q

Либо найти перечень приоритетов в стандарте С++...

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

sc>Не любым человеком, а большинством программистов код должен пониматься без особых напрягов.
Это красивые слова — не более того. Ни мне, ни Вам не может быть известно то, какой код должен пониматься _большинством_ программистов — просто потому, что это потребует регулярного анализа того, какая квалификация сейчас у _большинства_ программистов. Я стараюсь ориентировать написание кода на программистов определенных _квалификаций_, а не исходя из количества программистов. При этом ожидаемый уровень квалификации определяется моими предположениями о том, что из себя представляют программисты, которые возможно будут иметь дело с моим кодом.

sc>Лучше медленне писать, но быстрее сопровождать, быстрее править баги и быстрее дописывать новую фунциональность
sc>Даже достаточно простой и понятный код со временем может очень усложниться. После того, как над ним поработают несколько программистов подряд в течение нескольких лет. Так что лишние "кучеряшки" в коде лишние
К чему это очевидные вещи тут писать? С этом кто-то спорил?

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

CC>Всего то?..
Было бы интересно узнать — как этот же вопрос решается у Вас.

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

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

LMA>>Странное требование — чтобы они могли его понимать. Зачем? Может стоит просто подумать о другой декомпозиции?
E>Например при его использовании и отладки базирующегося на нём кода...
Для этого достаточно знания интерфейса и того, чтобы к этому моменту он был оттестирован. Им нет смысла заходить внутрь моих функций, ведь даже если они передадут что-то не то в качестве аргументов моему коду — они получат "assert'ом по морде"
Необходимость заходить внутрь используемого кода говорит только о низком его качестве и объективно не нужна.

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

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

LMA>>Все верно, но это не значит, что он должен хорошо сопровождаться любым человеком. Если Ваш код не может сопровождать обезьяна, это же не значит, что его плохо сопровождать.
E>Не, ну если у вас и обезьяны доступ к коду имеют, то мне всё больше интересно где ты таки работаешь?
Не передергивай. Когда код отправляется заказчику — контроль над тем, кто его будет видеть теряется почти всегда.

E>Может быть ты таки пояснишь, начиная с какой квалификации программиста конструкции вроде "delete x, y, z" начинают облегчать понимание кода?
Этой ереси не утверждалось! Читай внимательнее.

E>Моей квалификации, например, хватило бы только на то, чтобы понять "Осторожно! Код писали люди с альтернативным подходом к программированию!!! Дальше может быть любое г.!!!!".
inductio incompleta

E>Правда мне пришлось сделать осмысленное усилие, когда я этот пример тут увидел. Вспомнить про операторы, про запятую и т. д.
Так иногда полезно азы вспомнить

E>Нормальный код на С++ я читаю не задумываясь о синтаксисе, примерно как текст по-русски или по-английски.
То есть "нормальным" ты считаешь тот, код, который ты читаешь с листа? Так у нас практически нет противоречий!

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

E>и что? delete x, y, z; стандарты какого проекта позволяют писать?
Формально — практически любого. Хотелось бы узнать: а как может формулироваться стандарт, запрещающий такое?

E>Я бы даже

delete p, p = 0;

писать не стал бы...
Ты считаешь, что это менее читабельно, чем

delete p;
p = 0;

?

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

E>Я, кажется, понял, в чём корень разногласий. Чем больше людей может легко понимать и поддерживать код, решающий какую-то конкретную задачу, тем качественнее этот код написан.
E>Конечно понятно, что более качественный код писать сложнее и дольше. В этом ничего удивительного нет. И при тарет ресурсов на разработку надо искать комперомисс между трудозатратами и качеством кода.
Именно. Только ты пропагандируешь теоретический максимум, а в реальном проекте идешь на компромисс; а я предлагаю для реального проекта оговорить компромисс в качестве стандарта, чтобы потом ни у кого не возникало соблазна ничем не обоснованную лажу выдавать за компромисс.

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

E>Кстати, не хочу тебя расстраивать, но в С++ приоритетов у операторов нет
Тождественных приоритету понятий достаточно.

E>Если тебе так не кажется, то можешь расставить приоритеты в этом вот выражении:

p, q ? p, q : p, q

А что тебе здесь не понятно: то, что "?:" имеет больший приоритет, чем ",", или что агрументами "?:" являются варажения?

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

LMA>Необходимость заходить внутрь используемого кода говорит только о низком его качестве и объективно не нужна.
IMHO, гордиться надо практическими результатами, а не абстрактной крутизной кода.
Ну а то, что ты совершенно не приспособлен к работе в команде ты меня убедил. Увы и ах, но я только убеждаюсь в том, что мой первоначальный диагноз был верным...

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

LMA>Не передергивай. Когда код отправляется заказчику — контроль над тем, кто его будет видеть теряется почти всегда.
Так значит то, что код преднамеренно запутан, для того, чтобы саппорт могли осуществлоять более дорогие программисты -- это саботаж интересов заказчика и есть!!!

E>>Может быть ты таки пояснишь, начиная с какой квалификации программиста конструкции вроде "delete x, y, z" начинают облегчать понимание кода?
LMA>Этой ереси не утверждалось! Читай внимательнее.
А я внимательно читал. Ты тут соловьём разливаешься, что не готов тратить усилия чтобы писать более понятный дня новичков код, и что надо писать delete x, y, z... Так что либо ты готов тратить усилия на более понятный для неновичков, либо вообще готов тратить усилия на то, чтобы код стал менее понятным для всех. Я думал о тебе хорошо, извини, ошибся.

E>>Моей квалификации, например, хватило бы только на то, чтобы понять "Осторожно! Код писали люди с альтернативным подходом к программированию!!! Дальше может быть любое г.!!!!".
LMA>inductio incompleta
Пока что ты меня всё более убеждаешь в этом

E>>Правда мне пришлось сделать осмысленное усилие, когда я этот пример тут увидел. Вспомнить про операторы, про запятую и т. д.
LMA>Так иногда полезно азы вспомнить
Но не в том случае, когда внезапно надо найти ошибку или добавить фичу в чужой, преднамеренно запутанный код

E>>Нормальный код на С++ я читаю не задумываясь о синтаксисе, примерно как текст по-русски или по-английски.
LMA>То есть "нормальным" ты считаешь тот, код, который ты читаешь с листа? Так у нас практически нет противоречий!
Нет. У нас есть противоречие. Очень существенное. Я считаю, что понятность и читабельность кода надо повышать всегда. А ты, насколько я понял, призываешь её в некоторых случаях преднамеренно понижать...

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

typedef char (&Yes)[1];
typedef char (&No)[2];

Объясните пожалуйста вот это посимвольно. Что-то я грузанулся...

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

LMA>Именно. Только ты пропагандируешь теоретический максимум, а в реальном проекте идешь на компромисс; а я предлагаю для реального проекта оговорить компромисс в качестве стандарта, чтобы потом ни у кого не возникало соблазна ничем не обоснованную лажу выдавать за компромисс.

Да? Ну так и поясни тогда "Кому конструкция delete x, y, z" облегчает жизнь? С точки зрения компилятора она бессмысленна. С точки зрения новичка она не понятно, с точки зрения не новичка она предумышленное запутываение кода. Так и при чём тут компромисс? Это компромисс между чем и чем?

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

E>>Если тебе так не кажется, то можешь расставить приоритеты в этом вот выражении:

p, q ? p, q : p, q

LMA>А что тебе здесь не понятно: то, что "?:" имеет больший приоритет, чем ",", или что агрументами "?:" являются варажения?

Мне-то как раз всё понятно. Но я и не утверждаю, что в С++ у операций есть приоритеты...
Если у "?:" приоритет выше, чем у "," то поясни пожалуйста, почему вторая запятая обрабатывается так, словно она имеет более высокий приоритет, чем "?:"

Кроме того, тема об упоминании проритетов в тексте стандарта тобой тоже не раскрыта...

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

E>IMHO, гордиться надо практическими результатами, а не абстрактной крутизной кода.
Вот именно. Пока я от тебя услышал только то, что ты пропагандируешь какие-то теоретические принципы, которых сам же не придерживаешься, обуславливая это компромиссом. Все компромиссы должны быть формализованы ДО, а не ПОСЛЕ. IMHO, компромиссы, о которых говоришь ты, — это все лишь отмазки, нужные для того, чтобы в любой момент можно было прикрыть себе задницу: для тех людей, кто пишет нереальные (учитывая ресурсы, время и качество) "стандарты" кодирования — тем, что они написали "правильные" стандарты, а для тех, кто таким "стандартам" вынужден следовать — необязательностью следованию стандартов (компромиссом). Могу даже предположить, что у вас видимо стандарты вполне себе похожи на некоторое из тех, которые я видел, включающие кроме всего прочего, _запреты_ на использование goto, глобальных переменных; или устанавливающие минимальный размер комментариев.

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

E>Так значит то, что код преднамеренно запутан, для того, чтобы саппорт могли осуществлоять более дорогие программисты -- это саботаж интересов заказчика и есть!!!
Не "запутан", а не разжеван. Если это приводит к экономии денег заказчика (т.к. производительность работы квалифицированных программистов возрастает) — это саботаж? Ну тогда — я сочувствую вашим заказчикам!

LMA>>Этой ереси не утверждалось! Читай внимательнее.
E>А я внимательно читал. Ты тут соловьём разливаешься, что не готов тратить усилия чтобы писать более понятный дня новичков код,
Если ты не видишь разницы, между тем, что я не готов специально снижать свою производительность в НЕКОТОРЫХ проетках (что и было бы саботажем, IMHO) и тем, что пишешь ты — с тобой разговаривать не о чем!

E>и что надо писать delete x, y, z...
Ты будешь удивлен, но МОЖНО и НАДО — это не одно и тоже!

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

E>>>Моей квалификации, например, хватило бы только на то, чтобы понять "Осторожно! Код писали люди с альтернативным подходом к программированию!!! Дальше может быть любое г.!!!!".
LMA>>inductio incompleta
E>Пока что ты меня всё более убеждаешь в этом
Как я уже писал, и в хорошем коде WTFs/min равным нулю не бывает, если конечно не свой собственный код человек смотрит (шучу). Я не вижу ничего криминального в том, что я в каком-то куске кода добавлю в свои ворота WTF (хотя, как я уже писал, уверен, что если смайлик поставлю — коллеги меня поймут), а взамен получу реальную пользу в виде доводов против того, чтобы _это_ критиковало мой код.

E>Но не в том случае, когда внезапно надо найти ошибку или добавить фичу в чужой, преднамеренно запутанный код
Так нужно такие вещи не глубоко в код прятать, а на самом видном месте (как я тоже уже писал), поэтому к такому, как ты пишешь это не приведет.

E>Нет. У нас есть противоречие. Очень существенное. Я считаю, что понятность и читабельность кода надо повышать всегда. А ты, насколько я понял, призываешь её в некоторых случаях преднамеренно понижать...
Только если на это есть существенная причина, которая с лихвой покроет недостатки такой шалости!

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

E>Да? Ну так и поясни тогда "Кому конструкция delete x, y, z" облегчает жизнь? С точки зрения компилятора она бессмысленна. С точки зрения новичка она не понятно, с точки зрения не новичка она предумышленное запутываение кода. Так и при чём тут компромисс? Это компромисс между чем и чем?
Прочти выше для чего я предлагал использовать такую конструкцию — для фейсконтроля. Если ты предложишь лучший способ достичь такой же цели — возможно, я соглашусь.

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

LMA> Тождественных приоритету понятий достаточно.

LMA>>А что тебе здесь не понятно: то, что "?:" имеет больший приоритет, чем ",", или что агрументами "?:" являются варажения?

E>Мне-то как раз всё понятно. Но я и не утверждаю, что в С++ у операций есть приоритеты...
Непонятно слово "тождественных"? (выделил жирным)

E>Если у "?:" приоритет выше, чем у "," то поясни пожалуйста, почему вторая запятая обрабатывается так, словно она имеет более высокий приоритет, чем "?:"
Я уже написал: "агрументами "?:" являются варажения?" (выделил жирным)

E>Кроме того, тема об упоминании проритетов в тексте стандарта тобой тоже не раскрыта...
Разжевать что именно тождественное есть в стандарте? Кстати, про это есть в книге Страуструпа "Дизайн и эволюция.."

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

LMA>Не "запутан", а не разжеван. Если это приводит к экономии денег заказчика (т.к. производительность работы квалифицированных программистов возрастает) — это саботаж? Ну тогда — я сочувствую вашим заказчикам!
Мне кажется или кто-то пропагандировал использование конструкции "delete x, y, z", с целью сделать код более непонятным для программистов низкой квалификации? При этом, насколько я понял, программистов, которым такая конструкция понимаени кода облегчает в природе не существует...
А заказчикам нашим сочувствовать не надо. Мы производим весьма успешные коробочные продукты, и библиотеки и SDK и в целом всем всё нравится.

LMA>Если ты не видишь разницы, между тем, что я не готов специально снижать свою производительность в НЕКОТОРЫХ проетках (что и было бы саботажем, IMHO) и тем, что пишешь ты — с тобой разговаривать не о чем!
А мне показалось, что ты готов специально тратить усилия (то есть таки снижать свою производительность) для того, чтобы затруднить поддержку кода слишком низкоквалифицированными (по твоему мнению, а не по мнению заказчика) специалистами. То есть ты тратишь оплаченное заказчиком твоё рабочее время на удорожание саппорта. Ну и что что ты это только "в некоторых проектах" делаешь?

LMA>Только если на это есть существенная причина, которая с лихвой покроет недостатки такой шалости!
И какова же эта существенная причина преднамаренно понижать качество кода? Твоя патологическая боязнь критики?

E>>и что надо писать delete x, y, z...
LMA>Ты будешь удивлен, но МОЖНО и НАДО — это не одно и тоже!
Я не удивлён. Тебя я понял так, что НАДО, а я, например, считаю, что НЕЛЬЗЯ...

LMA>Как я уже писал, и в хорошем коде WTFs/min равным нулю не бывает, если конечно не свой собственный код человек смотрит (шучу). Я не вижу ничего криминального в том, что я в каком-то куске кода добавлю в свои ворота WTF (хотя, как я уже писал, уверен, что если смайлик поставлю — коллеги меня поймут), а взамен получу реальную пользу в виде доводов против того, чтобы _это_ критиковало мой код.
У тебя как-то много оченьпривязанности к коду. Прямо как к поэме или к ребёнку. Какие-то обиды, цензы кто там что может или не может критиковать...
Обычно, когда критикуют, то приводят аргументы. И сразу ясно кто там чего стоит, и как критик и как автор.
Если даже очень неквалифицированный программист найдёт в твоём прекраснейшем коде ошибку или недочёт какой -- то это будет на благо проекту!!!
Цель ведь не код свой внедрить, а РЕШИТЬ ПОСТАВЛЕННУЮ ЗАДАЧУ...

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

LMA>Прочти выше для чего я предлагал использовать такую конструкцию — для фейсконтроля. Если ты предложишь лучший способ достичь такой же цели — возможно, я соглашусь.

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