Differences
This shows you the differences between two versions of the page.
Both sides previous revisionPrevious revisionNext revision | Previous revision | ||
ru:develop:guidelines [2014/06/12 16:27] – [Инструменты разработки] valerius2k | ru:develop:guidelines [2018/08/17 14:43] (current) – [Присылая патчи с исправлениями (FIX THIS!!!)] valerius | ||
---|---|---|---|
Line 18: | Line 18: | ||
==== Получение и сборка исходных кодов ==== | ==== Получение и сборка исходных кодов ==== | ||
- | Сначала, | + | Сначала, |
* [[http:// | * [[http:// | ||
Line 24: | Line 24: | ||
* [[http:// | * [[http:// | ||
- | Вы можете [[ru: | + | Вы можете [[ru: |
Перед сборкой проверьте файлы setvars-< | Перед сборкой проверьте файлы setvars-< | ||
Line 34: | Line 34: | ||
< | < | ||
- | Для более подробногй информации о системе сборки см. документ [[en: | + | Для более подробной информации о системе сборки см. документ [[en:develop: |
==== Дерево каталогов ==== | ==== Дерево каталогов ==== | ||
- | Посмотрите на код в SVN, для понимания принципа размещения файлов. Обратите внимание, | + | Посмотрите на код в Git-репозитории, для понимания принципа размещения файлов. Обратите внимание, |
- | ==== Global/Shared/Private Headers | + | ==== Глобальные/Общие/Приватные файлы заголовков |
- | Each level of the SVN tree contains two standard directories: < | + | Каждый уровень дерева исходных текстов содержит два стандартных каталога: < |
- | |// | + | |// |
- | |// | + | |// |
- | Each levels/part of the OS should have a specific prefix that allows a developer to easily find what part of the OS a header/library file belongs to. For example code shared by the whole tree should be included with: | + | Каждая часть/уровень ОС должен иметь отдельный префикс, |
<code c># | <code c># | ||
- | and code shared by all commandline tools should include: | + | и код общий для утилит командной строки должен вклюачть: |
<code c># | <code c># | ||
- | Try to create as few shared code headers as possible. Each “shared” | + | Старайтесь создавать чем меньше общих заголовочных файлов, |
- | Example of use of common files: | + | Пример использования общих файлов: |
<code c>// Use the normal OS/2 INCL_ since our toolkit is the OS/2 toolkit | <code c>// Use the normal OS/2 INCL_ since our toolkit is the OS/2 toolkit | ||
Line 74: | Line 74: | ||
</ | </ | ||
- | ==== Documentation | + | ==== Документация |
- | * Private code (not shared with other code) should be documented only in the source. | + | * Приватный код |
- | * Shared code (shared with code at the same level or at all levels) should be documented in source and in a “building and developing” document. | + | * Разделяемый код |
- | * The API of the OS and the tools documentation should NOT be documented in the source tree but in the toolkit and release tree. | + | * ОС API и документация к утилитам тулкита НЕ должна находиться в дереве исходников, |
- | * Source code should be documented in the source file (not the header files). | + | * Исходный код должен быть документирован в нем самом |
- | * Each function should be prefixed with a description of what it does, what parameters it uses (in and out) and any external references it uses. | + | * Каждая функция должна предваряться специальным комментарием с описанием того, что она делает, |
- | * Place comments in the source that helps the reader to understand the logic and don't overdo it. | + | * Размещайте комментарии в исходном коде таким образом, |
- | ==== When Developing | + | ==== В процессе разработки |
- | * Use static linking, do not use dynamic libraries | + | * Используйте статическую линковку, не используйте динамических библиотек |
- | * Use the makefiles provided with the source tree, don' | + | * Пользуйтесь мейкфайлами из дерева исходников, не изобретайте свои собственные |
- | * Currently | + | * На текущий момент разработка |
- | * We use SVN to share code among developers. | + | * Мы используем Git для совместной разработки. |
- | * We use Doxygen | + | * Мы пользуемся |
- | ==== Submitting a Patch (FIX THIS!!!) ==== | + | ==== Присылая патчи с исправлениями |
- | * Make sure your changes follow the coding guidelines above. | + | * Убедитесь, |
- | * Make sure you are using the current versions of the sources so that the resulting diffs are comparing your changes with the head of the source tree. | + | * Убедитесь, |
- | * Create your patch either by using cvs diff -u (if you are using CVS) or diff -u original-file changed-file (if you are using a source archive - you can also create differences for the whole directory contents using diff -r) In the latter case include the old code first, the new code last – in the patch anything you added will be prefixed with a +. | + | * Создавайте ваш патч используя git diff если вы используете Git) или |
- | * Remove all/any lines that reference files without changes. | + | * Удаляйте из патча все несущественные строки. |
- | * Send the patch file as an attachment in your email. Do not paste the patch directly into the email body. | + | * Присылайте патчи в виде прикрепленного к письму файла. Не вставляйте его прямо в тело письма. |
- | * Maintainers will often reply in response to your patch, pointing out things to fix up, etc. before a patch can be checked in. Please always follow the maintainer suggestions closely and respond by sending a new corrected patch. Please do not expect the maintainers to rework your changes, you want to be able to claim all the credit for your great patches! | + | * Мейнтейнеры могут ответить вам на ваш патч, указав необходимые исправления, и др. перед тем, как патч будет принят. Всегда внимательно относитесь к замечаниям мейнтейнера и в ответ присылайте исправенные патчи. Пожалуйста, |
~~DISCUSSION~~ | ~~DISCUSSION~~ | ||