Цитата:
Сообщение от
ZVV
Если старый код точно никому больше не нужен
каковы критерии нужности и точности?
Цитата:
Сообщение от
ZVV
(сохраните где-нить в архиве на всякий пожарный)
интересно узнать как у Вас спроектировано и как организовано администрирование ресурса с архивами?
Цитата:
Сообщение от
ZVV
то лучше всего сделать иерархию классов, чем цепочку if-ов, я думаю...
прошу пояснить что такое иерархия классов
Цитата:
Сообщение от
sukhanchik
А когда таких "модификаций" будет пару-тройку раз в одном месте кода - то у Вас комментариев будет больше чем кода и разобраться в нем совершенно новому человеку будет уже нереально.
смотря что комментировать. если мы переводим с х++ на русский или английский что тут делается это перебор. если мы метим то, что добавили с целью дальнейшего сопровождения, не понимаю в чем проблема будет у нового человека? наймите более толкового нового человека.
когда комментариев будет больше чем кода
Цитата:
Сообщение от
sukhanchik
Первое желание, которое возникнет - стереть все комментарии.
а еще кучу ненужных классов, отчетов.
Цитата:
Сообщение от
sukhanchik
Поэтому тут - палка о двух концах. На одной чаше весов - разовое удобство переноса модификации для себя, на другой многократные попытки исследования кода для других.
чесно говоря, второго конца палки не увидел. оба мотива в одну чашу попадают.
Цитата:
Сообщение от
sukhanchik
Поэтому - как разработчик - могу посоветовать НЕ комментировать свои модификации, стирать старый код и писать свой поверх. Единственный комментарий, который можно оставить - это у класса/формы/отчета в ClassDeclaration. Остальное - вполне можно видеть путем сравнения слоев (в крайнем случае сравнения со старым слоем).
ну ну. разработчик разработчику рознь. если разработка ведется поставщиком (типовое решение) или консультантом (вертикально-горизонтальное решение), удаление комментариев рекомендовано (technet) после завершения разработки. если модификации ведутся пользователем системы самостоятельно, то процесс модификации перманентен, в этом случае даже релиз выпустить сложно. и имею ввиду именно этот случай.
Цитата:
Сообщение от
sukhanchik
В противном случае - все надо стереть и оставить только одну свою метку.
«Преждевременная оптимизация – корень всех зол», – Дональд Кнут (Donald Knuth).
Цитата:
Сообщение от
sukhanchik
Не надо забывать, что за комментариями в коде надо "ухаживать", чтобы они не устаревали и оставались актуальными.
поливать и подсыпать песочек
извините, но ассоциации. можно немного уточню цитатой с майкрософт?
Цитата:
Сообщение от
[url
http://msdn.microsoft.com]Хорошим[/url] стилем программирования считается начинать все процедуры с краткого комментария, описывающего функциональные характеристики процедуры (то, что она делает). Это необходимо для вашего собственного удобства и удобства того, кто читает этот код. Следует отличать детали реализации (как процедура работает) от комментариев, описывающих функциональные характеристики. Если в комментарий включены детали реализации, их следует обновлять при редактировании кода.
таким образом, комментарии в начале метода (заголовке класса) полезны, а поясняющие код полезны разве что при обучении, или чего то очень специфичного.
Цитата:
Сообщение от
sukhanchik
Посмотрим на наш любимый Микрософт. Сравните кол-во комментариев в коде в 3-шке и в 4-ке - В 4-ке много потерли комментариев.
а не показатель, так как написано выше - цели разные.
Цитата:
Сообщение от
sukhanchik
мне хотелось сделать упор в первую очередь на то, что чем меньше лишних "букав" тем лучше читаемость кода.
цель не превратить код в бульварное чтиво, а соблюсти работоспособность при переносе с версии на версию. возможно, при накате следующего сервис пака Ваша модификация не нужна будет. без комментария проанализировать сложнее в плане временных затрат.
используем следующий вид комментирования
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
при создании своего объекта так же, только коммент в методе classDeclaration.
комментировать
плюсы:
1) при сборке проекта экономлю время. все модификации вижу проще. т.е. без функции сравнения. при конфликтах, могу легко понять под какой проект были модификации. вижу "свежесть" кода. т.е. обращаю внимание только на то что было изменено. взаимный контроль логики выполнения остальными программистами. проще выполнить аудит, и как следствие повышается самодисциплина программистов.
2) при переходе на новую версию. модификации проще отличить от просто старой версии базового кода (хотя на мой взгляд, вместо слова "проще", уместно использовать слово "возможно").
3) так как среда ориентирована на объекты, и один и тот же объект может наследоваться, при модификации знаю, на каком функционале "аукнется" новая модификация, и что после модификации следует протестировать.
4) и еще один субъективный плюс. так как система с очень сложной логикой, ошибка в логике может принести убытки бизнесу
не комментировать
плюсы:
1) код красивый (это для эстетов)
больше не вижу. покажите если есть...
2) проще писать (хотя дело привычки. я бы сказал что если не вставлял ранее, то с личной организацией придется побороться)
возможно я консервативен, и в пятерке появилось средство управления версиями, но я вижу эту систему как дополнение, но не как замену вышеизложенному. дополнение хорошо тем, что позволяет на одном приложении исключить конфликты при изменения одного объекта разными людьми (в прежних версиях реализовано через блокировку объекта). Но самое главное что понравилось – это мониторинг изменения структуры объектов (например таблиц). Раньше приходилось вести учет отдельно. если разработка ведется на разных приложениях, изменения и комментарии при возвращения объекта в репозитарий будут утеряны (или разработку вести на подключенном к интернету месте)