бытие определяет сознание. жаль, что только один вариант ответа.
а что насчет смешения стилей? часто в одном проекте используются библиотеки с разными принципами именования. пример - MFC и STL. какой стиль выбрать? что делать (и нужно ли), что бы код смотрелся единообразно?

  Был у нас один "программист" (сейчас уже уволился), который на полном серьёзе (не прикалываясь) писал такое:

В общем, крайности всегда плохо. И совсем без комментариев нельзя, и перегружать код лишними комментариями - тоже вредно.

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

Разумеется, я не такие комментарии имела в виду. За такое нужно сразу убивать. Самодокументированность - это четкая логическая структура, ясные имена переменных и необходимый минимум комментариев.
. 
Я под этим понимаю описание классов и их функций. Типа функция XXX класса YYY делает то-то. Как отдельный документ. Считаю, что это лишняя трата времени - и того, кто пишет, и того, кто читает. Такого рода информация нужна только разработчикам, а они могут и код посмотреть (уж точно актуальную инфу получат). А если код в этом смысле написан плохо, то разумнее потратить время на его улучшение, чем не его же описание.
Разумеется, если продукт - не библиотека, предназначенная для внешнего распространения.

borisbn

У нас не до такой степени, но все же комментарии, чаще встречающиеся в нашем кода



Это сообщение отредактировал(а) azesmcar - 21.7.2011, 20:38

borisbn,
azesmcar
Ктото из вас написал что коментарии нужны в самых сложных местах, тоже с этим согласен, в остальном должны быть интуитивно понятные названия методов и переменных.
А так, как я понял, стиль формируется в зависимости от конкретной команды и тимлидера(в соответствии с его стилем обычно пишут)
Поэтому считаю позицию Earnest верной по созданию дока со стилем.

ни тот, ни тот, а как раз Earnest:


Это сообщение отредактировал(а) borisbn - 21.7.2011, 22:38

мне очень не нравится Google's C++ style guide.
совсем случайно наткнулся на эту тему: http://stackoverflow.com/questions/5695082...nce-in-industry
радует что не мне одному он кажется нелепым. особенно запрет использовать исключения и обильно шаблоны...  

с позиции Сишника (мне не нравятся все эти ваши примочки), я считаю, что это вполне оправданно.. код упрощается, значит меньше ошибок.. по поводу исключений, так там с примером показанно какие косяки с этим могут быть..

Код упрощается? При неиспользовании исключений? Да ладно! Букв становится больше - ошибки-то все равно обрабатывать нужно. А больше букв - больше возможностей случайно напортачить.
Косяки могут возникнуть какие угодно и где угодно. Все зависит от квалификации кодеров. Нет способа защититься от кривых рук, кроме превентивного отстрела. Но как распознать кривые руки еще до того, как они успели нанести ущерб - вот вопрос...  

нет, при неиспользовании Си++
А здесь пошли на компромис, между чистым Си и Си++, код стал проще - меньше ошибок, со стороны "криворуких" кодеров..
криворуких взял в кавычки, так как сам язык к этому распологает, это кстати попытка сделать из них пряморуких.. 

да ну ладно ;)
тебе уже не раз примеры приводили, что с++ код проще. главное иметь прямой моцг.


не-не-не! причина в моцге!

Добавлено через 4 минуты и 28 секунд
вот тебе еще парочка.
банальное получение списка элементов на ФС в текущем каталоге.
1.

http://liveworkspace.org/code/840584682a73...df6c8cd75a70848

2.

http://liveworkspace.org/code/a137f45778dc...002ba5aeda118bd

3.

http://liveworkspace.org/code/457efd76e5d4...38034951d1668eb


покажи Си`шный эквивалент ;)

Добавлено через 8 минут и 26 секунд
вдобавок: с++, с++су рознь.
ибо даже в Qt("Си с классами" (с) я) это сделано криво.


вот и пойми кто тут не прямой)

Ничо подобного! Причина как раз в его отсутствии!  

Это из области мифологии, к сожалению... Если у человека нет нужной хромосомы, то как задачу не упрощай - все равно найдет возможность сделать глупость. 
Нельзя упрощать до бесконечности - на упрощение\ разбиение придется потратить больше времени, чем на решение задачи самому. Так что смысла никакого, кроме 100% занятности населения.  
Понятно, у Гуглов может быть свое мнение на этот счет, и они имеют на это право. Как и мы.

Добавлено через 2 минуты и 50 секунд

Да, кстати еще один аргумент в пользу шаблонов и всяких бустов. Если умудрился написать подобное выражение так, что оно скомпилировалось, то очень много шансов за то, что оно работает правильно. Простой код таких "гарантий" не дает.  

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

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

на Си я код напишу, сразу как появится время..

fish9370, естественно, что это уже оффтоп.
но тем не менее...


в простом коде(самописном), как показывает практика, больше шансов нагородить ошибок, как ты недавно заметил в теме где ты написал функцию strcmp().


ну вот видишь... а ты про кривизну рук ;)


не исключено! но плюс в том, что эти подводные камни отловятся раньше, т.к. этот код юзаю не я один. в смысле boost использую не только я. и это все к тому, что: не нужно городить то, что давно нагорожено.


в реальных проекта, как правило, наказывают за рукоблудие. по причинам написанным выше.


к примеру: http://www.boost.org/users/uses_shrink.html

Добавлено через 5 минут
а вообще, я знаю очень мало проектов на плюсах, написанных не теми кто учился программировать по доке Qt, не использующих boost.
сейчас, благо, boost.type_traits и boost.thread перешли в стандарт. это уже в некоторой степени позволяет отвязаться от boost. но все равно многого не хватает:
asio.
mpl.
fusion.
function_types.
filesystem.
iostreams.
e.t.c...