25.06.2009, 18:29 | #1 |
Участник
|
А в ваших разработках тоже не принято ставить комментарии?
Столкнулся с непонятной для меня ситуацией - уже пару недель занимаюсь разработкой на Х++, но меня до сих пор удивляет отсутствие даже самых простых комментарий в коде. Возможно это так только у меня в системе. Чем это объясняется? В книгах по программированию чётко написано, что код без комментариев - это код, которого не было.
|
|
25.06.2009, 18:31 | #2 |
Ищущий знания...
|
Цитата:
Сообщение от ski
Столкнулся с непонятной для меня ситуацией - уже пару недель занимаюсь разработкой на Х++, но меня до сих пор удивляет отсутствие даже самых простых комментарий в коде. Возможно это так только у меня в системе. Чем это объясняется? В книгах по программированию чётко написано, что код без комментариев - это код, которого не было.
Т.е. программист заходит, что то меняет, подпроживает и все без коментов?
__________________
"Страх перед возможностью ошибки не должен отвращать нас от поисков истины." (с) С Уважением, Елизаров Артем |
|
25.06.2009, 19:04 | #3 |
Участник
|
Комментарии могут быть в Аксапте двух видов.
Первый - если кто-то меняет стандартный функционал и оставляет комментарий, когда, кем и для какой задачи код был изменен. Это делают все, чей код я когда-либо видел в системе. Второй - это коментарии, как данный написаный код работатет и что в итоге получается. Таких комментариев очень мало (практически нет) в оригинальной аксапте (версия 3.0, до покупки ее Микрософтов), достаточно много в коде, написаном для версии 4.0 и 2009 (например AIF даже иногда избыточно прокомментирован). Разработчики на партнере / клиенте обычно выбирают сами, будут ли добавлять такие комментарии. Я, например, делаю это очень редко. В то же время некоторые мои коллеги комментирую свой код заметно подробнее. Но у нас, например, нет никаких внутренних документов, регламентирующих должен ли я писать комментарии, как работает мой код. Т.е. я пишу комментарии только вида // XXXX, Мой код начался, -> ... // XXXX, Мой код закончился -> |
|
|
За это сообщение автора поблагодарили: ski (1). |
25.06.2009, 19:13 | #4 |
Ищущий знания...
|
На мой взгляд, подробные комментарии в коде нужно писать в случае сложной\запутанной логики выполнения. В будущем будет удобнее читать код и самому и остальным
А в случае простых доработок можно обойтись и просто идентификацией (когда, кем, для какой задачи сделано)
__________________
"Страх перед возможностью ошибки не должен отвращать нас от поисков истины." (с) С Уважением, Елизаров Артем |
|
25.06.2009, 19:36 | #5 |
Участник
|
Цитата:
Первый - если кто-то меняет стандартный функционал и оставляет комментарий, когда, кем и для какой задачи код был изменен. Это делают все, чей код я когда-либо видел в системе.
|
|
25.06.2009, 20:43 | #6 |
Moderator
|
Комментарий в коде нужен тогда, когда без него назначение кода не очевидно и не прозрачно. Кода, назначение которого не очевидно, следует избегать и комментарий здесь не лучшее, а наверное, и самое худшее решение.
|
|
|
За это сообщение автора поблагодарили: mazzy (2), AlexSD (2). |
25.06.2009, 22:25 | #7 |
Участник
|
Мое мнение таково: комментирование модификаций стандартного функционала просто необходимо, так как в отличие от технической документации, комментарии хранятся непосредственно в коде, не "утежеляя" его. Также комментирование кода является показателем профессионализма разработчика, наличие понятия и знания оформления программного кода, согласно ГОСТам. Такой подход способствует структуризации кода, повышает его читабильность и быстроту разбора "полетов". Вообще, уважаемые, не скупитись хотя-бы на комментарии для самих себя (пройдет пара лет и даже автору будет сложно без технической документации вспомнить то, что он когда-то реализовывал). А так осталяйте комментарии как наследие своим приемникам, таким образом Вы способствуете поддержке и развитию Ваших-же разработок. Умение и способность делиться знаниями - высший уровень мастерства и благоразумия. По себе знаю, что техническая документация емеет свойство теряться. Если нет специально выделенного человека ведущего учет всех модификаций и ТЗ на них, все версии и доработки модификаций, тогда надежда на Вас самих. Представьте, как сложно будет перенести модифицированную функциональность, к примеру, при переходе на новую версию MS AX, если ее практически не выявить, не имея на нее описания или ТЗ, не находя в коде комментариев и меток. А потом как замечательно, когда с течением времени Вы благодаря оставленным комментариям решаетесь усовершенствовать или перекписать прошлую реализацию функионала с преминением Ваших новых знаний.
|
|
25.06.2009, 22:30 | #8 |
Участник
|
Цитата:
Сообщение от ski
Действительно, только такие комментарии и используются. Просто я считаю, что этого не достаточно. Т.к. я только начал изучать АХ и сидеть разбираться в совершенно новом коде без комментариев достаточно тяжело. Я думаю, что всем было бы легче, если бы хоть в начале метода объяснялось, что хотят получить в итоге.
так вот, давным давно разработчики аксапты из даамгаарда исповедовали принцип самокомментирующегося кода (см. книги фаулера про рефакторинг) - это когда названия переменных/методов раскрывают суть выполняемых действий, а длина каждого метода невелика и выполняемые действия очевидны. причем этот принцип исповедовали слишком дословно. комментарии были. но их действительно было очень мало, только по делу. но в ходе развития, из-за того, что надо обеспечивать совместимость и на уровне названий методов, принцип самодокументирующегося кода не удалось выдержать. сейчас есть классы и методы, названия которых не соответствуют тем действиям, которые реально выполняются. сейчас есть методы-портянки на мамндацать страниц (например, широко известный в узких кругах метод SettleNow). Поэтому сейчас майкрософт обильно комментирует новые методы. Но при этом зачастую впадает в другую крайность - комментариев много и они бестолковые. вот-вот. ап-солютно согласен. |
|
25.06.2009, 23:02 | #9 |
Участник
|
Цитата:
Сообщение от mazzy
давным давно разработчики аксапты из даамгаарда исповедовали принцип самокомментирующегося кода (см. книги фаулера про рефакторинг) - это когда названия переменных/методов раскрывают суть выполняемых действий, а длина каждого метода невелика и выполняемые действия очевидны. но в ходе развития, из-за того, что надо обеспечивать совместимость и на уровне названий методов, принцип самодокументирующегося кода не удалось выдержать. сейчас есть классы и методы, названия которых не соответствуют тем действиям, которые реально выполняются. сейчас есть методы-портянки на мамндацать страниц (например, широко известный в узких кругах метод SettleNow).
Это мы сейчас про что говорим, про курсовую работу по информатике или про ERP-систему? Оно, конечно, здорово писать такой код, где имена говорят сами за себя, а методы содержат лишь дюжину-другую строк, но если модифицировать код системы не за счет бесконечных условных ветвлений в одних и тех же методах, а за счет использования ООП, то зачастую получаются классы-наследники, где перекрыты отдельные методы, обычно параметрические, или до/после вызова super() есть какой-то кусочек кода. Так вот, если не помнить наизусть, как работает родительский класс (а у меня лично иерархии наследования достигают подчас 4-х уровней, считая после RunBaseBatch), то код становится ну совсем непрозрачным, а предположения, в нем используемые, - совсем неочевидными. И в такой ситуации комментарий вида "эта переменная уже инициализирована там-то" спустя полгода-год позволяют намного быстрее разобраться в собственном же коде, не говоря даже про чужой. |
|
|
За это сообщение автора поблагодарили: denny (1), oip (1). |
25.06.2009, 23:22 | #10 |
Moderator
|
Цитата:
Ой, неужели сопоставление было написано уже после того, как Дамгаард продался Навижену?
Цитата:
Оно, конечно, здорово писать такой код, где имена говорят сами за себя, а методы содержат лишь дюжину-другую строк, но если модифицировать код системы не за счет бесконечных условных ветвлений в одних и тех же методах, а за счет использования ООП, то зачастую получаются классы-наследники, где перекрыты отдельные методы, обычно параметрические, или до/после вызова super() есть какой-то кусочек кода.
Цитата:
Так вот, если не помнить наизусть, как работает родительский класс (а у меня лично иерархии наследования достигают подчас 4-х уровней, считая после RunBaseBatch), то код становится ну совсем непрозрачным, а предположения, в нем используемые, - совсем неочевидными. И в такой ситуации комментарий вида "эта переменная уже инициализирована там-то" спустя полгода-год позволяют намного быстрее разобраться в собственном же коде, не говоря даже про чужой.
Кроме того, почему то никто не упоминал, что комментарии имеют обыкновение устаревать по мере изменения кода, а устаревший комментарий хуже, чем отсутствующий. Пойду даже дальше и признаюсь, что я считаю нецелесообразным даже помечать модифицированный код в стиле X++: <-- -- > Для решения подобных задач предназначены cvs - системы и, если я ничего не пропустил, со своей задачей они пока справляются. |
|
|
За это сообщение автора поблагодарили: Maxim Gorbunov (4), EVGL (3), petr (2). |
26.06.2009, 01:04 | #11 |
Участник
|
Цитата:
но таким страшным он стал не сразу. |
|
26.06.2009, 03:35 | #12 |
Участник
|
|
|
26.06.2009, 10:42 | #13 |
Участник
|
Цитата:
Обычно этот метод когда требуется модификация, приходится изучать чуть ли не с нуля, несмотря на то, что я там уже наставил своих комментариев. Как раз случай, когда из-за ошибок дизайна комментарии слабо помогают. А подход к комментариям у меня еще со времен изучения Дейкстры не изменился:
PS: естественно, не Дейкстры, а Кнута. Дейкстра это был мой кошмар при сдаче зачета по алгоритмам. Последний раз редактировалось Raven Melancholic; 26.06.2009 в 11:02. Причина: Память подвела |
|
26.06.2009, 14:01 | #14 |
NavAx
|
Согласен с gl00mie, что в плане работы с наследованием и прозрачности данного кода в Аксапте плохо, да и вообще в данном подходе. Так что вкупе с соображениями относительной "видимости" кода, видимо, этим и вызваны подобные монстры типа LedgerJournalEngine. Честно говоря, сам зачастую колеблюсь в вариантах реализации - написать некий единый класс с методами if тип одно - вызываем метод один, если тип - другое, вызываем метод 2 и т.д, либо же создать дерево классов-наследников. Кстати, прослеживающаяся тенденция к последовательному приближению к классическим принципам ООП с ростом версий Аскапты есть. И SettleNow - один из самых примечательных примеров (скажу, как знаток оного метода еще с 2.5 ). В 4ке и тем более, в 2009, довольно много классов было перестроено в подобном стиле. Но, увы - средства работы с подобными иерархиями классов остались на том же уровне.
Чего стоило бы хотя бы в функции контекстного меню "Просмотр определения" при наличии построенных перекрестных ссылок, вываливать список классов-предков и/или классов-наследников текущего (если они есть), в которых перекрыт данный метод с возможностью выбора, куда переходить. В общем, каменный век. Я сейчас столкнулся с таким набором классов порядка 15 штук, глубиной наследования ~4, так что наболело. Написано в лучшем стиле ООП, но более-менее целостное впечатление удалось получить далеко не сразу (кстати, в процессе выполнения/отладки самое оно смотреть как работает). Вообще, скажу я вам, проблемы с ООП в Аксапте две. 1. Неразвитость инструментальных средств разработки. 2. Сложность соблюдения концепций в контексте существующего кода. По второму пункту я имею в виду, что если уж в стандарте, к примеру, напрогано таким образом, что требование изолированности и статичности интерфейсов и реализаций объектов не соблюдается (т.е. если одна переменная инициализируется в одном месте, другая - в другом,в третьем и иногда в четвертом), хотя можно было бы упорядочить и как-то собрать, то соблюдать формальные требования так сказать Best Practices ООП становится слишком затратно по потерям времени и усилий, и, по сути, никому не нужно, кроме самих разработчиков. Что же касается комментариев - я сторонник некоего баланса между самодокументирующимся кодом и, в сложных методах/классах - заголовка с описанным общим алгоритмом работы метода и по ходу кода, ссылками на пункты из этого описания. Ну, и опять же, в "тонких" местах, где надо обратить внимание на некую особенность реализации - комментарий тоже считаю обязательным. И в "авторских" комментариях считаю нужным коротко описывать суть проекта-модификации.
__________________
Жизнь прекрасна! Если, конечно, правильно подобрать антидепрессанты... Последний раз редактировалось Maximin; 26.06.2009 в 14:09. |
|