Вы загрузили старую ревизию документа. Сохранив её, вы создадите новую текущую версию с этим содержимым.

Выбор медиафайла

Если вы читаете эту статью, я надеюсь, что вы знаете что такое пул-реквест (pull-request) и как его сделать. Здесь пойдет речь о требованиям к исходному коду. Все пул-реквесты должны пройти ревью, на котором оценивается качество кода, его стиль, форматирование и соответствие всей остальной кодовой базе. При этом степень внимательности и дотошности этого ревью будет сильно зависит от того что это за изменения и на что они влияют. Вот примерная иерархия: - Исправления опечаток в названиях переменных, функций (принимаются быстро с огромной благодарностью, накосячить в таких исправлениях сложно) - Исправления опечаток в названиях классов, интерфейсов, юнитов (принимаются быстро с огромной благодарностью, главное ничего не забыть и не добавить лишних изменений) - Добавление комментариев в код (комментарии должны быть по делу, они должны описывать не что происходит, а почему именно это) - Добавление и исправление юнит-тестов (принимаются быстро с огромной благодарностью) - Исправление ошибок в коде в пределах одного юнита (крайне желательно указание инцидента в багтрекере, чем более локальное изменение тем лучше) - Добавление новых экспротов, импортов и тд. (такие изменения, если они не добавляют новых интерфейсов и зависимостей будут приниматься без особых претензий, большую часть кода, который не хочется приводить под стандарты САС.Планеты, можно расположить в отдельном юните в папке Includes как это сделано для SAS4WinCE, YaMobileCache, LibBMP и тд) - Добавление новых элементов в графический интерфейс, параметров в окно настроек (такие изменения, если они не добавляют новых интерфейсов и зависимостей будут приниматься без особых претензий, крайне желательно не менять существующее поведение без веских аргументов для этого) - Изменения в поведении основных подсистем, конвейеров подготовки отображаемой карты и тд. (нужно быть готовым обосновать необходимость изменений и почему именно так, код должен строго соответствовать по форматированию и стилю остальному коду) - Изменения существующих интерфейсов и добавление новых (нужно быть готовым обосновать необходимость изменений и почему именно так, код должен строго соответствовать по форматированию и стилю остальному коду, возможны претензии к именованию интерфейсов и их методов и тд.) Общий итог - чем локальнее изменение, тем проще ему будет пройти ревью. Файлы с интерфейсами i_*.pas - изменять в последнюю очередь и быть готовым доказывать необходимость их изменения для достижения поставленной цели и необходимость этой цели вообще. Причем крайне желательно это делать еще в багтрекере в подтвержденной хотелке до отправки пул-реквеста.

Пожалуйста, введите код подтверждения, чтобы доказать, что вы не робот: Please keep this field empty:

Сводка изменений