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


AA>>Это нелегальный C++ код.
RO>Причем здесь C++?!
+1
Насколько я понимаю, первоначально обсуждался C#. Но и в С/С++ есть схожие обстоятельства...
Так что то, что это "не легальный С++" код, тоже не совсем не в тему сообщение IMHO

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

[skipped]
Странные какие-то проблемы... ваша IDE не умеет автоматически форматировать текст кода?

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

I>По поводу "друг друга мучить". Я бы не мучился, а подчинился. Как подчинился когда-то одному далеко не глупому начальнику, объяснявшему мне, что не стоит делать всю работу по созданию объекта в конструкторе, а стоит мол в конструкторе делать необходимый минимум, а все остальное перенести в специальную функцию Initialize или вроде того. Ну вот он тоже считал свой способ единственно верным. Может сейчас самому смешно.
А что в этом смешного?
Ваш начальник был прав, непонятно только, почему он не смог объяснить вам причины.

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

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

RO>>>Аналогично:

RO>>>

RO>>>enum SomeEnum
RO>>>{
RO>>>    value1,
RO>>>    value2, // <-- лопата
RO>>>};
RO>>>

AA>>Это нелегальный C++ код.

RO>Причем здесь C++?!

Хм, а почему не? Ты привел 3 примера, помеченных тагами "c" (заметь не c#). Второй пример использует boost::format. Третий — тоже явно на C++ похож. Явных указаний о языке ты не даешь. Здравая логика подсказала мне, что ты имеешь в виду C++ во всех трех случаях.

Просвети тогда, каким должен был быть ход моей мысли на самом деле?

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

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


AA>>>Это нелегальный C++ код.
RO>>Причем здесь C++?!
E>+1
E>Насколько я понимаю, первоначально обсуждался C#. Но и в С/С++ есть схожие обстоятельства...
E>Так что то, что это "не легальный С++" код, тоже не совсем не в тему сообщение IMHO

Из двух других примеров Романа

RO>

RO>std::cout
RO>    << "hello"
RO>    << boost::format("%3% - %1% = %2%")
RO>        % something
RO>        % somethingElse()
RO>        % yetAnotherExpression
RO>    << "world"
RO>;
RO>

RO>

RO>Query q("SELECT * FROM table WHERE x = ? AND y = ?")
RO>    (getSomeX())
RO>    (42)
RO>;
RO>

я решил (вполне ожидаемо), что мы обсуждаем С++.

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

RO>>>>

RO>>>>enum SomeEnum
RO>>>>{
RO>>>>    value1,
RO>>>>    value2, // <-- лопата
RO>>>>};
RO>>>>

AA>>>Это нелегальный C++ код.

RO>>Причем здесь C++?!

AA>Хм, а почему не? Ты привел 3 примера, помеченных тагами "c" (заметь не c#). Второй пример использует boost::format. Третий — тоже явно на C++ похож. Явных указаний о языке ты не даешь. Здравая логика подсказала мне, что ты имеешь в виду C++ во всех трех случаях.

AA>Просвети тогда, каким должен был быть ход моей мысли на самом деле?

:-)

Этот код соответствует стандарту C99 и (наверное) будет соответствовать C++09.

В любом случае, мы не обсуждаем конкретный язык, а только стиль, который подходит почти к любому языку программирования (кроме Python :-).

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

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

AA>>>>Это нелегальный C++ код.

RO>>>Причем здесь C++?!

AA>>Хм, а почему не? Ты привел 3 примера, помеченных тагами "c" (заметь не c#). Второй пример использует boost::format. Третий — тоже явно на C++ похож. Явных указаний о языке ты не даешь. Здравая логика подсказала мне, что ты имеешь в виду C++ во всех трех случаях.

AA>>Просвети тогда, каким должен был быть ход моей мысли на самом деле?

RO>

RO>Этот код соответствует стандарту C99 и (наверное) будет соответствовать C++09.

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

ОК, просто как человек, постоянно проверяющий код, который пишет команда, я по привычке обращаю внимание на "непортабельные" места. И сразу хочется написать комментарий, чтобы сэкономить кому-нибудь пару минут при компиляции другими компиляторами. Может, и это сообщение прочитает кто-нибудь и запомнить, что пока в коде C++ лучше не ставить "хвостовую" запятую в перечислениях, дабы не плодить ворнинги...

Кстати, в Питоне хвостовые запятые разрешены синтаксисом. И мне это нравится.

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

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

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


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

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

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

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

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

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

Тем хуже загрязнять комменты ненужным кодом...

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

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

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

C>>А документация пишется тут же — в исходном коде с помощью Doxygen/JavaDoc.
E>Тем хуже загрязнять комменты ненужным кодом...
Это почему? Для реализации — вполне нормально. Документируется интерфейс и важные для его пользователя детали. Внутренний код документировать обычно не обязательно — его проще и удобнее просто посмотреть.

Да, и к общей архитектурной документации это не относится — она вообще идёт отдельно и к коду не привязана.

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

E>В смысле? Если програмист изобразит что-то типа того, что обсуждается в этой ветке, то как автоформат текста мне поможет?
E>Я уж не говорю о том, что часто читаю код подчинённых не в IDE...
Речь о том, что вместо того, чтобы инспектировать код подчиненных на наличие нестандартного стиля форматирования, можно просто контролировать использование единой настройки автоформатирования, которую также хранить в системе контроля версий.

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

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

Код инспектируется не заради проверки форматирования. А заради контроля и для дальнейшего развития. Просто когда в коде есть "художества" это затрудняет работу с ним.

Как наличие конструкции вроде

if( false
    || cond1
    || cond2
) {
}

может быть скомпенсированно настройками автоформатера я не понимаю.
Ещё я не понимаю сути проблемы. Какие проблемы всем соблюдать стандарт кодирования? Если ты не в состоянии обеспечить даже такую ерунду, как отступы, то как ты вообще можешь работать в команде?

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

C>Это почему? Для реализации — вполне нормально. Документируется интерфейс и важные для его пользователя детали. Внутренний код документировать обычно не обязательно — его проще и удобнее просто посмотреть.
Ну, то есть тебе кажется нормальным, например, если в комментах к интерфейсу будут закомментированные ошмётки четырёх предыдущих его версий?

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

E>Код инспектируется не заради проверки форматирования. А заради контроля и для дальнейшего развития. Просто когда в коде есть "художества" это затрудняет работу с ним.
Эти художества может инспектировать и не допускать алгоритм.

E>Как наличие конструкции вроде

if( false
E>    || cond1
E>    || cond2
E>) {
E>}

может быть скомпенсированно настройками автоформатера я не понимаю.
Ничего не надо компенсировать: когда программист жмет Save, код автоматически форматируется в соответствии с принятом в команде стилем. Конкретно у меня Resharper в Visual Studio или встроенный форматтер в Eclipse JDT в данном случае выстроит предикаты в одну строку и сделает перенос, только если строка превысит 78 символов. Это было настроено один раз, закинуто в SVN, указано всем пользоваться этой настройкой — и забыто.

E>Ещё я не понимаю сути проблемы. Какие проблемы всем соблюдать стандарт кодирования? Если ты не в состоянии обеспечить даже такую ерунду, как отступы, то как ты вообще можешь работать в команде?
Во-во, не понимаю ваши проблемы в упор.

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

C>>Это почему? Для реализации — вполне нормально. Документируется интерфейс и важные для его пользователя детали. Внутренний код документировать обычно не обязательно — его проще и удобнее просто посмотреть.
E>Ну, то есть тебе кажется нормальным, например, если в комментах к интерфейсу будут закомментированные ошмётки четырёх предыдущих его версий?
В Doxygen комментах — вряд ли. А вот в теле — вполне нормально.

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

R>Эти художества может инспектировать и не допускать алгоритм.
Какая разница кто их будет инспектировать?
Тут же обсуждается их целесообразность? IMHO они не целесообразны.
А кто будет контролировать -- алгоритм или сами разработчики вопрос не особо важный.
IMHO нет никакого смысла в доп. формализации этих всех дел. Сил тратится много, а толку мало. Если кто-то хочет тратить силы на борьбу с системой, а не на конструктивную деятельность, то нафига бы он нужен?

R>Ничего не надо компенсировать: когда программист жмет Save, код автоматически форматируется в соответствии с принятом в команде стилем. Конкретно у меня Resharper в Visual Studio или встроенный форматтер в Eclipse JDT в данном случае выстроит предикаты в одну строку и сделает перенос, только если строка превысит 78 символов. Это было настроено один раз, закинуто в SVN, указано всем пользоваться этой настройкой — и забыто.
Так можно жить. Но можно и так, что код форматируют люди, в процессе разработки.
Правда у нас используют настройки редактора по автоформатированию, но не все. Главное -- приемлемый результат.

R>Во-во, не понимаю ваши проблемы в упор.
А у нас нет проблем. Просто все стандарты кодирования соблюдают и всё

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

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

E>>В смысле? Если програмист изобразит что-то типа того, что обсуждается в этой ветке, то как автоформат текста мне поможет?
E>>Я уж не говорю о том, что часто читаю код подчинённых не в IDE...
R>Речь о том, что вместо того, чтобы инспектировать код подчиненных на наличие нестандартного стиля форматирования, можно просто контролировать использование единой настройки автоформатирования, которую также хранить в системе контроля версий.

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