Правила оформления кода
-
Удобство одних иногда оборачивается неудобствами других, и это именно тот случай. Глупо только ради удобства части разрешать вещи, которые, будучи разрешёнными, уже приводили к бардаку.Сделаем мир лучше!
Предлагаю к правилам оформления кода, ещё и приплюсовать правила оформления комментариев на SVN. Пожелания, предложения?
(Потому что делать чендж лог по комментариям в СВН...кромешный...а правильный комментарий позволил бы делать автоматическое создание лога приемлемо для чтения...)
Можно использовать такой формат (подглядел у реактос):
[название программы]
- 1 изменение
- 2 изменение
- n изменение
(Потому что делать чендж лог по комментариям в СВН...кромешный...а правильный комментарий позволил бы делать автоматическое создание лога приемлемо для чтения...)
Можно использовать такой формат (подглядел у реактос):
[название программы]
- 1 изменение
- 2 изменение
- n изменение
Поддерживаю про правила оформления коммитов
И все-таки, почему использование отступа для локальных меток - это плохо? Улучшает же читаемость.
И все-таки, почему использование отступа для локальных меток - это плохо? Улучшает же читаемость.
Для меня наоборот затрудняет. Это шаг в сторону синтаксиса ЯВУ.
Для меня тоже ухудшает. Привык к тому, что метки не перекрываются со строчками кода, так проще их искать.
Mario
Какого ЯВУ ? И причём здесь выравнивание меток ?
В ЯВУ переходы преданы анафеме и встречаются по штуке на проект.
Mario
Какого ЯВУ ? И причём здесь выравнивание меток ?
В ЯВУ переходы преданы анафеме и встречаются по штуке на проект.
Мне не с чем было сравнить.
Пусть будет просто - неудобный для восприятия стиль.
Пусть будет просто - неудобный для восприятия стиль.
Я обновила список правил. Теперь прекоммитный хук проверяет, что все файлы .asm, .inc, .txt имеют кодировку UTF-8 и не содержат BOM. Хук, к сожалению, распространяется только на kernel/trunk.
Требование кодировки относится только к исходникам, скомпилированные файлы могут использовать всё, что им нравится. Для перекодирования в процессе компиляции я написала немного макросов в kernel/trunk/encoding.inc, они принимают на вход строку в UTF-8 и генерируют бинарник с этой же строкой в предписанной кодировке - cp866, latin1, cp850 в зависимости от макроса.
Требование кодировки относится только к исходникам, скомпилированные файлы могут использовать всё, что им нравится. Для перекодирования в процессе компиляции я написала немного макросов в 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).
sec_loader/trunk/parse_any.inc:327
Ну и интересно, как себя чувствует DOCPACK (точнее, TINYPAD).
in code we trust
Ревизия 3543 - tinypad из docpack - полёт нормальный.
Спасибо, я исправила.mike.dld wrote:sec_loader/trunk/loader.lst:908
sec_loader/trunk/parse_any.inc:327
Точно так же, как и раньше. Документация в ходе сборки конвертируется в cp866 - для docpack и дистрибутива - и cp1251.mike.dld wrote:Ну и интересно, как себя чувствует DOCPACK (точнее, TINYPAD).
Сделаем мир лучше!
Is possible to do the same with the programs?CleverMouse wrote:Я обновила список правил. Теперь прекоммитный хук проверяет, что все файлы .asm, .inc, .txt имеют кодировку UTF-8 и не содержат BOM. Хук, к сожалению, распространяется только на kernel/trunk.
Требование кодировки относится только к исходникам, скомпилированные файлы могут использовать всё, что им нравится. Для перекодирования в процессе компиляции я написала немного макросов в kernel/trunk/encoding.inc, они принимают на вход строку в UTF-8 и генерируют бинарник с этой же строкой в предписанной кодировке - cp866, latin1, cp850 в зависимости от макроса.
No. Only kernel. Otherwise, I will stop writing the code for the project.esevece wrote:Is possible to do the same with the programs?CleverMouse wrote:Я обновила список правил. Теперь прекоммитный хук проверяет, что все файлы .asm, .inc, .txt имеют кодировку UTF-8 и не содержат BOM. Хук, к сожалению, распространяется только на kernel/trunk.
Требование кодировки относится только к исходникам, скомпилированные файлы могут использовать всё, что им нравится. Для перекодирования в процессе компиляции я написала немного макросов в kernel/trunk/encoding.inc, они принимают на вход строку в UTF-8 и генерируют бинарник с этой же строкой в предписанной кодировке - cp866, latin1, cp850 в зависимости от макроса.
Всем чмоки в этом проекте! Засуньте эти 11 лет себе в жопу!
Он имел в виду, что он хочет, чтобы это было, а не спрашивает, как этим пользоваться. Почему исходники программ нельзя тоже перевести в UTF8, а при компиляции - перевести обратно?Mario_r4 wrote:No. Only kernel.esevece wrote:Is possible to do the same with the programs?
Who is online
Users browsing this forum: No registered users and 2 guests