Board.KolibriOS.org

Удобство одних иногда оборачивается неудобствами других, и это именно тот случай. Глупо только ради удобства части разрешать вещи, которые, будучи разрешёнными, уже приводили к бардаку.

Предлагаю к правилам оформления кода, ещё и приплюсовать правила оформления комментариев на SVN. Пожелания, предложения?

(Потому что делать чендж лог по комментариям в СВН...кромешный...а правильный комментарий позволил бы делать автоматическое создание лога приемлемо для чтения...)

Можно использовать такой формат (подглядел у реактос):

[название программы]
- 1 изменение
- 2 изменение
- n изменение

Поддерживаю про правила оформления коммитов
И все-таки, почему использование отступа для локальных меток - это плохо? Улучшает же читаемость.

Для меня наоборот затрудняет. Это шаг в сторону синтаксиса ЯВУ.

Для меня тоже ухудшает. Привык к тому, что метки не перекрываются со строчками кода, так проще их искать.

Mario
Какого ЯВУ ? И причём здесь выравнивание меток ?
В ЯВУ переходы преданы анафеме и встречаются по штуке на проект.

Мне не с чем было сравнить.
Пусть будет просто - неудобный для восприятия стиль.

Я обновила список правил. Теперь прекоммитный хук проверяет, что все файлы .asm, .inc, .txt имеют кодировку UTF-8 и не содержат BOM. Хук, к сожалению, распространяется только на kernel/trunk.
Требование кодировки относится только к исходникам, скомпилированные файлы могут использовать всё, что им нравится. Для перекодирования в процессе компиляции я написала немного макросов в kernel/trunk/encoding.inc, они принимают на вход строку в UTF-8 и генерируют бинарник с этой же строкой в предписанной кодировке - cp866, latin1, cp850 в зависимости от макроса.

Я думаю, что эту новость стоит указать в темах переводов.

То-то же я никак не пойму, что это PSPad стал показывать, что дока в UTF-8.

sec_loader/trunk/loader.lst:908
sec_loader/trunk/parse_any.inc:327

Ну и интересно, как себя чувствует DOCPACK (точнее, TINYPAD).

Ревизия 3543 - tinypad из docpack - полёт нормальный.

mike.dld wrote:sec_loader/trunk/loader.lst:908
sec_loader/trunk/parse_any.inc:327

Спасибо, я исправила.

mike.dld wrote:Ну и интересно, как себя чувствует DOCPACK (точнее, TINYPAD).

Точно так же, как и раньше. Документация в ходе сборки конвертируется в cp866 - для docpack и дистрибутива - и cp1251.

CleverMouse wrote:Я обновила список правил. Теперь прекоммитный хук проверяет, что все файлы .asm, .inc, .txt имеют кодировку UTF-8 и не содержат BOM. Хук, к сожалению, распространяется только на kernel/trunk.
Требование кодировки относится только к исходникам, скомпилированные файлы могут использовать всё, что им нравится. Для перекодирования в процессе компиляции я написала немного макросов в kernel/trunk/encoding.inc, они принимают на вход строку в UTF-8 и генерируют бинарник с этой же строкой в предписанной кодировке - cp866, latin1, cp850 в зависимости от макроса.

Is possible to do the same with the programs?

esevece wrote:

CleverMouse wrote:Я обновила список правил. Теперь прекоммитный хук проверяет, что все файлы .asm, .inc, .txt имеют кодировку UTF-8 и не содержат BOM. Хук, к сожалению, распространяется только на kernel/trunk.
Требование кодировки относится только к исходникам, скомпилированные файлы могут использовать всё, что им нравится. Для перекодирования в процессе компиляции я написала немного макросов в kernel/trunk/encoding.inc, они принимают на вход строку в UTF-8 и генерируют бинарник с этой же строкой в предписанной кодировке - cp866, latin1, cp850 в зависимости от макроса.

Is possible to do the same with the programs?

No. Only kernel. Otherwise, I will stop writing the code for the project.

Mario_r4 wrote:

esevece wrote:Is possible to do the same with the programs?

No. Only kernel.

Он имел в виду, что он хочет, чтобы это было, а не спрашивает, как этим пользоваться. Почему исходники программ нельзя тоже перевести в UTF8, а при компиляции - перевести обратно?