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/21 20:30] – [Глобальные/Общие/Приватные файлы заголовков] valerius2k | ru:develop:guidelines [2018/08/17 14:43] (current) – [Присылая патчи с исправлениями (FIX THIS!!!)] valerius | ||
---|---|---|---|
Line 24: | Line 24: | ||
* [[http:// | * [[http:// | ||
- | Вы можете [[ru: | + | Вы можете [[ru: |
Перед сборкой проверьте файлы setvars-< | Перед сборкой проверьте файлы setvars-< | ||
Line 38: | Line 38: | ||
==== Дерево каталогов ==== | ==== Дерево каталогов ==== | ||
- | Посмотрите на код в SVN, для понимания принципа размещения файлов. Обратите внимание, | + | Посмотрите на код в Git-репозитории, для понимания принципа размещения файлов. Обратите внимание, |
==== Глобальные/ | ==== Глобальные/ | ||
- | Каждый уровень дерева | + | Каждый уровень дерева |
|// | |// | ||
|// | |// | ||
- | Каждая часть/ | + | Каждая часть/ |
<code c># | <code c># | ||
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~~ | ||