![]() |
#12 |
Участник
|
каковы критерии нужности и точности?
интересно узнать как у Вас спроектировано и как организовано администрирование ресурса с архивами? прошу пояснить что такое иерархия классов Цитата:
когда комментариев будет больше чем кода а еще кучу ненужных классов, отчетов. Цитата:
Цитата:
Сообщение от sukhanchik
![]() Поэтому - как разработчик - могу посоветовать НЕ комментировать свои модификации, стирать старый код и писать свой поверх. Единственный комментарий, который можно оставить - это у класса/формы/отчета в ClassDeclaration. Остальное - вполне можно видеть путем сравнения слоев (в крайнем случае сравнения со старым слоем).
Цитата:
Цитата:
![]() Цитата:
Сообщение от [url
http://msdn.microsoft.com]Хорошим[/url] стилем программирования считается начинать все процедуры с краткого комментария, описывающего функциональные характеристики процедуры (то, что она делает). Это необходимо для вашего собственного удобства и удобства того, кто читает этот код. Следует отличать детали реализации (как процедура работает) от комментариев, описывающих функциональные характеристики. Если в комментарий включены детали реализации, их следует обновлять при редактировании кода.
Цитата:
Цитата:
используем следующий вид комментирования UserId = текущий пользователь Date = текущая дата Time = текущее время CompanyId = код компании (префикс наших объектов) VerId = версия и сп под которую делалась модификация ProjectId = код проекта, под которую делались изменения для ProjectId дополнительно ведется общий реестр с описанием проектов. проект кодируется так: UserId_YYMMDD_[КраткоеНазвание] вся строка комментария формируется автоматом (подправили для этих целей класс EditorScripts), при выборе в контекстном меню редактора соответствующей команды. при модификации кода, как правило, если весь блок помещается на экране, то так: X++: // UserId on Date at Time, CompanyId VerId ProjectId --> // e.gotoCol(1); e.gotoCol(2); // UserId on Date at Time, CompanyId VerId ProjectId <-- X++: // e.gotoCol(1); // UserId on Date at Time, CompanyId VerId ProjectId --> e.gotoCol(2); // UserId on Date at Time, CompanyId VerId ProjectId <-- X++: // UserId on Date at Time, CompanyId VerId ProjectId --> e.gotoCol(1); X++: e.gotoCol(2); // UserId on Date at Time, CompanyId VerId ProjectId <-- X++: // Restruct by UserId on Date at Time, CompanyId VerId ProjectId public void sendTo_printer(Editor e) { Args a = new Args(); Object report; ; a.name(reportstr(SysPrintCode)); ... // Old way //public void sendTo_printer(Editor e) //{ // Args a = new Args(); // Object report; // ; // // a.name(reportstr(SysPrintCode)); ... X++: // Created on UserId on Date at Time, CompanyId VerId ProjectId комментировать плюсы: 1) при сборке проекта экономлю время. все модификации вижу проще. т.е. без функции сравнения. при конфликтах, могу легко понять под какой проект были модификации. вижу "свежесть" кода. т.е. обращаю внимание только на то что было изменено. взаимный контроль логики выполнения остальными программистами. проще выполнить аудит, и как следствие повышается самодисциплина программистов. 2) при переходе на новую версию. модификации проще отличить от просто старой версии базового кода (хотя на мой взгляд, вместо слова "проще", уместно использовать слово "возможно"). 3) так как среда ориентирована на объекты, и один и тот же объект может наследоваться, при модификации знаю, на каком функционале "аукнется" новая модификация, и что после модификации следует протестировать. 4) и еще один субъективный плюс. так как система с очень сложной логикой, ошибка в логике может принести убытки бизнесу не комментировать плюсы: 1) код красивый (это для эстетов) ![]() больше не вижу. покажите если есть... 2) проще писать (хотя дело привычки. я бы сказал что если не вставлял ранее, то с личной организацией придется побороться) возможно я консервативен, и в пятерке появилось средство управления версиями, но я вижу эту систему как дополнение, но не как замену вышеизложенному. дополнение хорошо тем, что позволяет на одном приложении исключить конфликты при изменения одного объекта разными людьми (в прежних версиях реализовано через блокировку объекта). Но самое главное что понравилось – это мониторинг изменения структуры объектов (например таблиц). Раньше приходилось вести учет отдельно. если разработка ведется на разных приложениях, изменения и комментарии при возвращения объекта в репозитарий будут утеряны (или разработку вести на подключенном к интернету месте)
__________________
Дом поросенка должен быть крепостью. (Наф-Наф, полн. собр. соч., т.5, стр. 286) Последний раз редактировалось mit; 18.08.2009 в 10:18. |
|