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

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


AA>>Из двух других примеров Романа
AA>>я решил (вполне ожидаемо), что мы обсуждаем С++.

E>IMHO обсуждаемые проблемы и идеи универсально применимы или непременимы в С/С++/С#...

Идеи — да. Реализация идей, как обычно, имеет кучу мест, где прячутся бесы. Я лишь имел в виду, что использование хвостовых запятых в перечислениях является нарушением текущего стандарта. Когда у нас код в первый раз переводился на GCC и когда начали строго следить за ворнингами, эти хвостовые запятые пришлось в коде явно вычищать. Собственно, этим опытом и делюсь. Если все это уже знают — сорри за флуд.

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

R>Ваш начальник был прав, непонятно только, почему он не смог объяснить вам причины.

Ну это было давно, но если не ошибаюсь главным аргументом было то, что конструктор якобы не должен бросать исключений.

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

I>Ну это было давно, но если не ошибаюсь главным аргументом было то, что конструктор якобы не должен бросать исключений.
Это заваит от того, в каком случае бросает исключение конструктор. Если часто, то н едолжен.
А ещё "давно" было много реализаций С++, на которых исключения действительно было лучше не бросать

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

AA>Настройки форматирования IDE могут быть дополнением к описанным правилом, но уж никак не заменой.

Любите сложности?

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

AA>Хм, то есть вместо того, чтобы простым текстом описать требования к форматирования, мы вводим требования к тому, какую IDE использует человек. Типа, демократия по-майкрософтовски? В сад. Я весь код в Vim пишу, кто-то у нас в команде Emacs использует, кто-то в редакторе Фара все пишет. Следовать правилам форматирования я нахожу весьма разумным, пересаживать всех на одну ИДЕ — нет. Настройки форматирования IDE могут быть дополнением к описанным правилом, но уж никак не заменой.
Следование выбору единой IDE скорее решение конкретного человека, чем приказное наставление: человек выбирает, или ему кроме того, что с него требуют выполнения поставленных задач, еще и выделять время на форматирование кода в соответствии со стандартом команды — или использовать инструмент, который сделает это в фоне за него. Вместо того, чтобы тратить время на ручное упорядочивание бардака в условиях предоставленной мнительной свободы, мне кажется, стоит тратить время на работу.

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

I>Ну это было давно, но если не ошибаюсь главным аргументом было то, что конструктор якобы не должен бросать исключений.
Мимо. Единственный способ отменить создание объекта (а это достаточно часто нужно, при формировании некорректных входных данных) — выбросить из конструктора исключение. Насколько понял, вы пишете на Java — посмотрите конструкторы классов JDK, практически каждый бросает исключение в соответствующем случае.

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

R>Здравствуйте, Alex Alexandrov, Вы писали:

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

Почему "ручное упорядочивание"? Есть масса способов сделать это автоматически. Возможностей Вима хватает с головой, да еще и остается. У Visual Studio возможности куда беднее. Есть, конечно, Visual Assist и прочие, но ведь их покупать надо.

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

C>>А документация пишется тут же — в исходном коде с помощью Doxygen/JavaDoc.
E>Кстати, в сложных, наукоёмких проектах такой подход совершенно не работает. В таких проектах документация -- довольно сложные и свосем предментыне статьи


К каждому методу??? Ой ли?

Может быть все же отдельная большая документация с подробными описаниями, которая все равно нужна, и общий reference по классам и методам, который как раз прекрасно генерится по JavaDoc?

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

N>>Зачем козе баян? При нормальном проектировании эти списки никто не хранит напрямую в коде, они подгружаются из ресурсных конфигов.

I>Верно. Но у такого подхода есть и недостатки. Например надо обрабатывать ситуацию, когда файл не найден. Или еще иногда нужно запретить пользователю изменять список. Не думаю, что предлагаемый тобой подход является предпочтительным в 100% всех случаев. Бывает, что предпочтительнее хранить список в исходном коде.

Еще можно хранить в ресурсном файле. Или заполнять список в коде и искать по нему потом...

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

а как записать подобное условие:

if( cond3 || (cond1 && cond2) || (cond4 && cond5 ) )

?
я правильно понимаю, что это должно быть записано так:

if( false 
    || cond3 
    || (true 
        && cond1 
        && cond2
       ) 
    || (true 
        && cond4 
        && cond5 
       ) 
   )

?

А не убьешься читать такую конструкцию?

З.Ы. я использую перенос длинных строк по && или || в if, но только если они получаются слишком длинные — чтобы удобнее воспринимать строку без скроллнга, или, иногда, если условие разбитое на строчки выглядит понятнее.
Но замусоривать лишними true/false и разбивать на строки даже короткие условия — это ужасная идея...

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

F>А не убьешься читать такую конструкцию?

Не надо убиваться, я ведь не утверждал, что if(false нужно использовать всегда.

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

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

E>Это заваит от того, в каком случае бросает исключение конструктор. Если часто, то н едолжен.
А если часто, но не конструктор, а Initialize?

E>А ещё "давно" было много реализаций С++, на которых исключения действительно было лучше не бросать
Это был VC++ 6.0.

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

R>Мимо. Единственный способ отменить создание объекта (а это достаточно часто нужно, при формировании некорректных входных данных) — выбросить из конструктора исключение. Насколько понял, вы пишете на Java — посмотрите конструкторы классов JDK, практически каждый бросает исключение в соответствующем случае.

Тогда это был C++. И почему-то было популярно создавать "пустой" объект и лишь затем заполнять его содержанием. Вот пример: CFileVersionInfo.

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

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

R>>Мимо. Единственный способ отменить создание объекта (а это достаточно часто нужно, при формировании некорректных входных данных) — выбросить из конструктора исключение. Насколько понял, вы пишете на Java — посмотрите конструкторы классов JDK, практически каждый бросает исключение в соответствующем случае.

I>Тогда это был C++. И почему-то было популярно создавать "пустой" объект и лишь затем заполнять его содержанием. Вот пример: CFileVersionInfo.

Это и сейчас "популярно" в том случае, если штатно предусматривается возможность создания группы объектов десериализацией потока. Тогда пустой конструктор создаёт "мёртвый", но готовый к принятию потокового представления объект.

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

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

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

CC>>Да замените себе diff утилиту на ту, которая будет подсвечивать не только измененные строки но и что именно в строках изменилось.

I>На какую?

tkdiff (кроссплатформенный, ибо Tk)

You will always get what you always got
  If you always do  what you always did

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

N>Это и сейчас "популярно" в том случае, если штатно предусматривается возможность создания группы объектов десериализацией потока. Тогда пустой конструктор создаёт "мёртвый", но готовый к принятию потокового представления объект.

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

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

C>>>А документация пишется тут же — в исходном коде с помощью Doxygen/JavaDoc.
E>>Кстати, в сложных, наукоёмких проектах такой подход совершенно не работает. В таких проектах документация -- довольно сложные и свосем предментыне статьи :)

F>К каждому методу??? Ой ли?
F>Может быть все же отдельная большая документация с подробными описаниями, которая все равно нужна, и общий reference по классам и методам, который как раз прекрасно генерится по JavaDoc?

Уж сколько раз твердили миру. В документации должно быть описано не то, что делает код (точнее, не только то), а зачем он там, какую проблему решает.

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

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

AA>Почему "ручное упорядочивание"? Есть масса способов сделать это автоматически. Возможностей Вима хватает с головой, да еще и остается. У Visual Studio возможности куда беднее. Есть, конечно, Visual Assist и прочие, но ведь их покупать надо.

Vim — это очень хороший текстовый редактор, но всё равно «d\t.pb\t(gse\t;» удобнее, чем «data.push_back(getSomeElement());».

P. S. Брам произносит его как «Фим».

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

RO>P. S. Брам произносит его как «Фим».

К голландском звук 'v' произносится как нечто среднее между нашим 'ф' и 'в'.

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

E>>Это заваит от того, в каком случае бросает исключение конструктор. Если часто, то н едолжен.
I>А если часто, но не конструктор, а Initialize?

Initialize, в отличии от конструктора, может вернуть результат.