В java созданы все условия для того чтобы писать красивые связанные друг с другом комментарии: есть форматирование текста, возможность ссылаться на любой класс и метод, даже наследовать комментарии от родительских классов и интерфейсов и в конце концов тул, с помощью которого вы можете сгенерировать документацию к вашему коду!

У меня вопрос исключительно к тем участникам форума, которые не комментируют свой код, почему вы это делаете? Только честно!

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

Потому что,если я пишу по технологии которую я в момент написания -изучаю, я раз 5 переписываю код, и коментарить зная что счас будет сntr+a+del, нехоцца.. А то что знаешь уже на 5+, просто рука не поднимаецца, и зря .. когда смотришь то что было написанно хотябы месяца три-4 назад, уже начинаются вопросы .. а здесь я что хотел сделать.. Все ИМХО  

Это сообщение отредактировал(а) barin_Student - 2.4.2009, 14:56

Комментарии я пишу. но стараюсь, что бы их было меньше.

Код должен легко читаться и без комментариев 

Понятные названия пакетов
Понятные названия классов
Понятные названия переменных
Понятные названия методов.

Пишу. 
Раньше не писал, потому что это было не нужно.  
На работе всегда требуют, поэтому мое желание/нежелание не влияет.  Хотя писать комменты - это круто !   

Читаться то он будет легко, а вот что делает и КАК, какой алгоритм реализует эта связка с надцати классов, у каждого из которых по надцать методов - названия классов и методов не подскажут.

Через полгода другого проекта Вы сами не вспомните детали реализации собственного кода, почему здесь я сделал так, а вот здесь такую проверку, а там - другую.

Skynin, 



Вот как раз тут четкие названия пакетов, классов, методов  неплохо подскажут.  Хотя, я не говорю, что это всегда верно. Иногда очень даже нужно написать JavaDoc 

Просто я имел ввиду, что ИМХО не стоит комментировать ради того чтобы был комментарий.

Например, я не думаю, что метод подобный этому нуждается в комментариях




Вот когда реализуется что-то достаточно сложное то комментарии пишу, причем пишутся они сами собой. Просто как пояснения что и зачем.

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

Есть такая "модная" идеология.

Вопрос только - а насколько она распространена. Например - я так и не слышал чтобы у кого-то из знакомых программистов работали попарно. Как и многого другого описанного у Бека.

А от тех, кого считаю более опытными, слышал только фыркание, "ах эти разговоры о ХР... ну пусть говорят, не обращай внимание"

Не пишу по причине указанной barin_Student'ом. Но, когда приходит время вернуться к коду, само собой уже непонятному, разбираюсь в нем и вот тут уже пишу комментарии.   

Это оффтоп уже конечно 
Я работал в 3 разных конторах и везде проекты велись по XP/Scrum. В той, что сейчас работаю, XP это главный процесс - все проекты по нему ведутся. Парное программирование, test driven development, continuous integration, всякие принципы типа YAGNI или KISS, и д.р. - это все обыденная реальность для нас.  

Банальная лень   

Банально из-за нехватки времени. Когда проект горит, уже не до комментариев.

Грамотный синтаксис кода - это уже на половину сам-себе-комментарий.
На работе пишу комментарии к ключевым моментам, домашнии проекты не комментирую, ибо и так всё знаю, потому что писал  

Samotnik, Ты пишешь

Что означает - было не нужно, в чем была причина не нужности (напряжный график работы, лень ...) ?

Это сообщение отредактировал(а) Royan - 3.4.2009, 11:10

Всегда пишу
"Понятный код" отвечает на вопрос "как", но не отвечает на вопрос "почему". Вспомнить потом, почему тут сделано именно так - очень сложно. По идее, эти нюансы должно покрывать ТЗ, но оно далеко не всегда актуально и далеко не всегда в курсе местных тактических решений.