Курсы создания компьютерных игр на C/C++ ( Часть 2 )
Для самых-самых начинающих программистов :] Часть 1 - http://pikabu.ru/story/_3430226
![Курсы создания компьютерных игр на C/C++ ( Часть 2 ) Для самых-самых начинающих программистов :] Часть 1 - <a href="http://pikabu.ru/story/kursyi_sozdaniya_kompyuternyikh_igr_na_cc__chast_1__3430226">http://pikabu.ru/story/_3430226</a>](https://cs5.pikabu.ru/post_img/big/2015/06/19/4/1434691737_1084318426.jpg)
раскрыть ветку (12)
раскрыть ветку (11)
Я на техника инф систем учусь, нас просто учили листингом осознавать, ибо так реально проще ориентироваться в конспектах, тут ты читаешь и видишь что к кому относится. Плюс комменты в коде добавить было бы не лишним для тех, кто понял слабо)
Вроде For(i=0;i<=4;i++) // цикл и т.д.
раскрыть ветку (10)
раскрыть ветку (3)
ну, это ж для новичков.
потому уже, в самом проекте, нужно будет писать, что "это цикл, в котором няпка убивает тяпку, поа у няпки не сломалось оружие и/или пока тяпка не сдохнет"
раскрыть ветку (2)
В ответе ниже написали, что такие комментарии - как
стикеры с названиями очевидных вещей - на холодильник "холодильник", на булку хлеба "хлеб", жене на лоб "жена"
Если так писать комментарии - то будет что-то типа
answer := 42; // Присваивание
print (answer); // Вывод на печать
Комментарии должны в краткой форме описывать смысл действия, производимого определенным куском из нескольких строк кода. А не капитанить смысл каждой строки. В крайнем случае - если используется какая-то нетривиальная функция или конструкция.
раскрыть ветку (1)
блин.
те, кто вообще в первый раз ЭТО видят, они как Фукс в "Приключениях капитана Врунгеля" мультовом -
"я забыл где паруса,
я забыл где паруса?..
- даму треф ищиииите!"
человек ничего не понимает. откуда он знает, что происходит там-то или там-то?
соответственно, в самых первых и простых прогах, по идее, комментарии показывают, что означает тот или иной оператор в тексте. логично, или я не прав?
не, такие комментарии не нужны. тут и ежу понятно что это цикл, а если не понятно то лишний повод подучить конструкции языка. комментарии в коде это зло в большинстве случаев, потому что код меняется, а вот актуальность комментариев не всегда поддерживается. потом приходит новый программист и вместо того чтобы прочесть код он натыкается на устаревший комментарий и такой "ясно-понятно" хотя ничего ему не понятно, потому что комментарий наврал. Комментарии делают в тех местах кода где не понятна причина именно такой реализации, может это обход костыля 3rd party библиотеки или еще чего-то нестандартного, где нужно пояснить какую-то очень важную часть, без знания которой можно натворить таких делов, что огого!
Приведу пример. ваш комментарий "//цикл" это как ходить по дому и клеить стикеры с названиями очевидных вещей - на холодильник "холодильник", на булку хлеба "хлеб", жене на лоб "жена". А вот если например в холодильнике стоят две одинаковые бутылки - одна с водкой а другая с уксусом (такое было во времена ссср, унификация, все дела. у меня батя с утреца разок перепутал :) ), то тут комментарий о том что "вот это уксус! опасно! не пить! водка в другой" к месту.
Надеюсь понятно объяснил.
раскрыть ветку (5)
Ооо) Это вечный спор)
Я вам что скажу.
Сейчас закончил принимать проект, писавшийся 3 людьми в течении 7 лет. В нем нет комментариев. Документации по нему тоже нет. Людей-мейнтейнеров растеряли + они иностранцы. С одним я успел потереть за жизнь пару дней. Конечно, нюансов море и обговорить все было не реально. Фактически, код не всегда может самодокументироваться в достаточной мере, как у нас - модульное приложение на WPF + PRIZM (ну вы понимаете, да? декларативщина и байндинги, которые не отыскать через 'Find usage...") с адом дочерних сборок, куча интерфейсов и абстракций над абстракциями. Очевидное было не всегда очевидно, специалисты тратили ценное время.
Вывод: писать комментарии (XML для C#, JavaDoc, и прочие документирующие для Doc-o-matic и аналогов), юнит-тесты - очень рекомендуется!
Избыток информации всегда лучше ее недостатка.
раскрыть ветку (2)
так же и говорю, комментировать нужно не очевидные вещи. другое дело когда код линеен (ну почти) то есть достаточно прост. Конечно когда тебя кидают на проект, который ты не знаешь, то ты готов материть всех и вся. Но это подло, я думаю, с точки зрения руководства. Чтобы перевести кого-то на проект, нужно делать это заранее. Конечно, есть форс-мажорные ситуации, когда вся команда, например, увольняется (интересно почему вся команда?) и срочно нужен человек чтобы продолжить проект, но если есть мысли выгнать всю(!) команду, то нужно делать это как можно плавнее, ну то есть подкинуть в проект человека чтобы принял дела хотя бы частично. ну это мое мнение, наверное это в идеальном мире. Но если я соберусь уходить из компании, я обязательно за несколько месяцев буду переводить человека на мое место, ну это если конечно не случится какой-то форс-мажор, потому что как бы есть кастомеры, интересы компании, как-то дорожишь проектом.
P.S. Их реально расстреляли?
раскрыть ветку (1)
У нас такая специфика - инновации. То есть проект может быть "заморожен" на неопределенный срок. Естественно, за 7 лет
положение дел может измениться не раз, и не два. Вот, крайний чувак из команды собрался увольняться - начали хэндовер проекта делать. Но сказ о том, что для среднего разработчика адекватную документацию и пусть даже немного капитанские (для разработчика "в теме" ) документирующие комментарии воспринимать всегда легче, чем даже самый самоописывающийся код.
Растеряли) У нас зачастую проекты раздают "по супер-способностям" специалистам разных областей (кто-то химию знает, кто-то роботов собирать мечтал, кого-то базы данных влекут и т.п.), из-за чего работа выходит солная или небольшими группами, а проекты - чуть ли не именными. Но иногда люди находят что-то лучше, уезжают в другие страны, дауншифтят в фермеры... Да мало ли по каким причинам люди меняют работодателей?)
ЗЫ
Конечно, все это ИМХО. Если есть крупный проект с большим количеством активных разработчиков, где можно запросто выделять менторов для новичков - ради Бога, качественная документация здесь не нужна.
Начнём с того, что мы говорим не о студентах, которые изучают язык, не о школьниках из школы с физмат уклоном с доп знаниями по информатике. Мы говорим о людях, которые о программировании обычно слышали из фильмов про кулхацкеров. Соответственно среди них есть те, до кого с первого раза в теории не доходит и надо увидеть на практике что есть цикл, почему собстна в C нет такой фигни как в паскале begin/end, почему вместо них {/} и что же значит это чёртово return(0). Мы говорим о тех, кто только начинает. Ставить ли комменты - решайте сами, но тем, кто здесь, они лишними не будут.
раскрыть ветку (1)
Во-первых, тем кому это не надо, этим и заниматься не будет, а тот кто будет думаю заинтересуется мнением человека, который в этой сфере работает.
Во-вторых, обычно, как говорили ниже, переменные и прочее задают осмысленными именами, а не просто ААА, bbb и прочее, чтобы потом прочитать было просто и смысл был понятен, а пояснять конструкции языка в коде комментариями это бред. это нужно только для тех кто будет сдувать эту программу и пересдавать как свою, потому что, как правило, они нихрена не смыслят и без этого преподу слова сказать не смогут.
Ну и в-третьих, если мы говорим о лекциях или о таких вот туториллах, то лучше пояснить такие конструкции текстом до или после приведения некого кода, а не в листинге.
Могу еще добавить, что комментарии нужны для тех или иных функций, как описание. некоторые среды программирования (в том числе и Visual Studio на котором и писал по всей видимости автор) поддерживают такие вот summary для функций, они полезны потому что при использовании функции среда программирования (некоторые из них) выведет тебе подсказку с текстом этого комментария. вот такие комментарии еще уместны, как документация к функции (или к членам классов, самим классам, да простят меня разработчики, сидящие на пикабу, за такую простоту).