От знакомого моего знакомого. Что тому написал его руководитель проекта/начальник. Не везет же бедолаге...
Хэль, это кстати к вопросу о том что рецензии не меняются
читать дальшеСлушай, повторяется древняя история, опять будешь семь раз править?
1. Разберись с пробелами и табуляцией и исправь выравнивание
2. В конструкциях if во многих местах нарушен coding style. Должно быть
if (condition) {
action
}
а у тебя идет
if (condition)
{
action
}
3. не надо было повально везде ставить perror_with_time. Разберись по смыслу, где это нужно, а где нет. Сообщения, которые выдаются при разборе опций при старте программы, не нуждаются в указании времени, потому что они выдаются сразу при старте программы. Место, где ты пишешь "listening on socket", не является ошибкой, это просто информационное сообщение. Оно не должно выводиться функцией perror_....
4. И потом, ты поменял часть fprintf при старте на perror_with_time, а часть оставил. Принципа, по которому ты выбирал, что менять, а что нет, я не уловил. От балды менял?
5. Функция perror_with_time определена с одним параметром. В некоторых местах ты ей передаешь два-три параметра. Не думаю, что это будет нормально работать.
Разберись с этим наконец нормально.
По поводу программы на Delphi. Сравни то, что ты мне отправил, с тем, что лежит в VSS, и учти следующие замечания:
1. Программируя на Паскале, мы стараемся избегать функций, которые имеют побочный эффект. ConnectingToFTP как раз функция, которая имеет побочный эффект (до нее соединение не было установлено, после нее установлено). В этих ситуациях лучше использовать процедуру с переменным параметром, который отображает результат выполнения операции (как сделано сейчас в VSS).
2. Почему ты для выдачи сообщений местами используешь ShowMessage, а местами MessageDlg?
3. В функции TransmitFile вызывается Sleep (3000). Это зачем?
4. В pgfm.pas в одном месте используется AssignFile (F, 'c:\TZ_46_48_64\pultinit.tmp');. Это неправильно. Я там поставил AssignFile (F, 'pultinit.tmp');, если не будет работать, надо будет разбираться.
5. Ты почему-то убрал большой кусок, который находится в предыдущей vss-ной версии в строчках 1616-1624. Там многое нужно.
6. В процедуре UpdateConnectionState для состояния ComPrepareGetCentraleState ты сделал какие-то действия, в случае, если UseLan. Но APDProtocolStartReceive в следующей строке делается всегда. Не думаю, что это правильно. Я там поставил else.
7. Возьми версию из vss и все проверь заново.
Пункты 1 и 2 - просто рабочие замечания в порядке обучения.
Пункты 5-6 - это просто п-ц. Это недопустимо! Пункт 4 тоже не блеск.
Про программу станции:
1. В pult1236.pas в состоянии ConnectionReceive case написан криво. Отдельно все обрабатывается для 64-й станции, отдельно для 48-й. Это неправильно. Отдельно должно происходить только заполнение ProgrammingBuffer, дальше у них все общее.
Оставь остальную деятельность и доделай falcom и программирование. Замечания по программе на Delphi я переделал сам и выложил все в vss, возьми последнюю версию. Все остальное у тебя и так есть.
Гм, а персонально для мну можно пункты кретинизма показать?
По поводу вызова функций с разным числом параметров - это либо проверяющий не нашел оверлоада либо тот кто писал накосячил. И это еще вопрос что именно выполняется.
По поводу вывода сообщений двумя разными функциями - у нас (нагло, да, и самонадеянно, но все же) возник вопрос, а представляет ли товарищ разницу между ShowMessage и MessageDlg;
По тем самым пунктам 5-6, опять-таки. Либо плющит одного, либо плющит другого.
//Строго говоря, это все довольно-таки относительно, и тем не менее - общий тон послания а так же сведения о самом его авторе подталкивают к тому, чтобы априори воспринимать написанное в глупую сторону
Ну тут я совсем не согласен. Этот пункт решается одной настройкой в IDE и все. Если человек этого сделать не соизволил - раздолбай
На счет остального - надо в код смотреть дабы оценить глупость придирок, ежели таковая имеецца.
Что до настроек в IDE - лично мне кажется что настройки тут не причем, это просто то место которое целиком зависит от вкуса
А скольким пробелам у тебя в ИДЕ равна одна табуляция? У меня например - четырем
Code conventions - страшная вещь, но помогает очень сильно.
PS: кста, а вот вы насколько часто редактируете чужие сорцы? Ну в смысле другого девелопера?
Перманентно редактируем. Правда, в основном междусобойные, но не только. Я уж не говорю про клятую богами 1C 8.
Ну и раньше приходилось в других конторах тем же заниматься частенько, особенно лазая по Конкорду. Тут вопрос такой: по идее почти к любому стилю писания приспособиться легко - лишь бы он _был_. Когда текст написан грамотно, мелочи вроде переноса скобок и наличия-отсутствия точек-с-запятой перед "}" - они за час копания усваиваются и не мешают. А вот если текст коряв, тогда кранты. Даже если табуляция и четыре символа.
Код становится неоднородным. Часть процедуры написана в одном стиле, а часть - в другом. И нафиг такой спагетти-код?
А когда текст у стороннего разработчика берется на доработку - так вообще надеяться на настолько четкое соответствие стилей неразумно. Индивидуальные особенности, они всегда будут, и это по большому счету хорошо! Так что главное - опять-таки - чтобы текст был красив, а приспособиться к нему всегда сумеешь.
Имхо, конечно.
Это ты говоришь о проектах мелко-среднего размеру со сроком разаработки в месяц-два. Или же средние без суппорта (то бишь отдали заказчику, получили деньги и никогда уже о проекте не вспоминаете. Про reusable code я тут тоже молчу
Когда же только разработка идет полгода (про QA cycle я вообще молчу), то там по неволе хочешь не хочешь, а дописывать что-то чужое надо будет.
Опять же новые люди в компании куда деваются? Им дают новые таски? Неа, ни в жисть. Им дают на доработку старое. Чтобы было время вкурить в материал, в стиль, в продукт, выяснить на что новичок способен.
Короче Code Conventions можно не применять только в очень статичных и небольших проектах.
Такие дела
Могу только сказать, что полностью перелопатить ту же стандартную конфигурацию 1С (а восьмерка это все же весьма мощная вещь, как ее не хай, и яркий пример именно процедурного а не объектного стиля... к сожалению) для наших нужд мы таки смогли.
Точнее, находимся в состоянии переделки, давно уже перешедшей в дописку, совмещенную с обычной работой конторы - уже больше полугода, и мешала там гораздо больше не стилистика написания кода а банально отсутствие комментариев и во многих участках весьма специфичное мышление разработчиков. Так что есть в мире вещи пострашнее расположения скобок.
Я пашу в крупном проекте - кодинг стайлинг наше фсе! Если достается кривой код после кого то - это ППЦ. Суппорт и доводка в длительных проектах может достатся каждому, выравнивания и оформление смонстряченного всегда смотрятся ревьювером, чтоб код выглядил в едином стиле и читабельно.
Но перед выбором код стаил или каменты - выбрал бы каменты
Я не спорю, что хороший стиль необходим. Я не уверен в такой уж глобальной необходимости его сверхстрогой унификации. По крайней мере, для меня никогда не было проблемой возиться с нормально оформленными чужими текстами - даже если они оформлены не так как я бы предпочел.