testing_project/Documentation: dev_guide/c_style_guide — Russian @ Weblate: switch (suffix) { case 'G': case 'g': mem <<= 30; …

The translation is temporarily closed for contributions due to maintenance, please come back later.
The translation was automatically locked due to following alerts: Could not merge the repository.

Zen

Translation

English

Russian

Needs editing

Skip

	English	Russian	Actions
	C Style Guide	Руководство по написанию кода на C
	We use Git for revision control. The latest development is happening in the default branch (currently ``master``). Our git repository is hosted on GitHub, and can be checked out with ``git clone git://github.com/tarantool/tarantool.git`` (anonymous read-only access).	Для управления версиями мы используем Git. Разработки ведутся в ветке, используемой по умолчанию (сейчас ``master``). Наш Git-репозиторий находится на GitHub, его можно выгрузить с помощью ``git clone git://github.com/tarantool/tarantool.git`` (анонимный пользователь получит доступ только для чтения).
	If you have any questions about Tarantool internals, please post them on `StackOverflow <https://stackoverflow.com/questions/tagged/tarantool>`_ or ask Tarantool developers directly in `telegram <http://telegram.me/tarantool>`_.	Если у вас есть вопросы о внутреннем устройстве Tarantool, задайте их на `StackOverflow <https://stackoverflow.com/questions/tagged/tarantool>`_ или напрямую разработчикам Tarantool в `Telegram <http://telegram.me/tarantool>`_.
	General guidelines	Общие рекомендации
	The project's coding style is inspired by the `Linux kernel coding style <https://www.kernel.org/doc/html/v4.10/process/coding-style.html>`_.	Стиль разработки проекта основан на `стиле программирования ядра Linux <https://www.kernel.org/doc/html/v4.10/process/coding-style.html>`_.
	However, we have some additional guidelines, either unique to Tarantool or deviating from the Kernel guidelines. Below we rewrite the Linux kernel coding style according to the Tarantool's style features.	Кроме того, мы даем дополнительные рекомендации, которые либо специфичны для Tarantool, либо отличаются от рекомендаций по программированию ядра Linux. Ниже приведен стиль программирования ядра Linux, переработанный с учетом особенностей разработки Tarantool.
	Tarantool coding style	Стиль программирования Tarantool
	This is a short document describing the preferred coding style for the Tarantool developers and contributors. We insist on following these rules in order to make our code consistent and understandable to any developer.	В этом документе описан приоритетный стиль программирования Tarantool для разработчиков и участников сообщества. Мы настаиваем на соблюдении этих правил, чтобы наш код был последовательным и понятным любому разработчику.
	Chapter 1: Indentation	Глава 1: Отступы
	Tabs are 8 characters (8-width tabs, not 8 whitespaces), and thus indentations are also 8 characters. There are heretic movements that try to make indentations 4 (or even 2!) characters deep, and that is akin to trying to define the value of PI to be 3.	Табуляция составляет 8 символов (8 символов табуляции, а не 8 пробелов), то есть отступы будут также составлять 8 символов. Появляются отступники, которые призывают делать отступы в 4 (или даже 2!) символа, а это сродни попытке округлить число Пи до 3.
	Rationale: The whole idea behind indentation is to clearly define where a block of control starts and ends. Especially when you've been looking at your screen for 20 straight hours, you'll find it a lot easier to see how the indentation works if you have large indentations.	Обоснование: Основная идея отступов состоит в том, чтобы показать, где начинается и заканчивается логический блок кода. Особенно если вы смотрите на один и тот же код в течение 20 часов, трудно не заметить пользу больших отступов.
	Now, some people will claim that having 8-character indentations makes the code move too far to the right, and makes it hard to read on a 80-character terminal screen. The answer to that is that if you need more than 3 levels of indentation, you're screwed anyway, and should fix your program.	Некоторые могут возразить, что отступ в 8 символов делает код слишком широким, особенно на 80-знаковой строке терминала. Ответ: Если вам понадобилось более трех уровней отступа, вы что-то делаете неправильно, и вам следует переписать этот участок.
	8-char indents make things easier to read and have the added benefit of warning you when you're nesting your functions too deep. Heed that warning.	Отступы в 8 символов облегчают чтение кода. Кроме того, по ним можно понять, когда у вас становится слишком много вложенных функций.
	The preferred way to ease multiple indentation levels in a switch statement is to align the ``switch`` and its subordinate ``case`` labels in the same column instead of ``double-indenting`` the ``case`` labels. E.g.:	Лучше всего упростить несколько уровней отступов в операторе switch, выравнивая ``switch`` и его вспомогательные метки ``case`` в одном столбце вместо того, чтобы использовать двойные отступы для меток ``case``, например:
	switch (suffix) { case 'G': case 'g': mem <<= 30; break; case 'M': case 'm': mem <<= 20; break; case 'K': case 'k': mem <<= 10; /* fall through */ default: break; }	switch (suffix) { case 'G': case 'g': mem <<= 30; break; case 'M': case 'm': mem <<= 20; break; case 'K': case 'k': mem <<= 10; /* fall through */ default: break; }
	Don't put multiple statements on a single line unless you have something to hide:	Не размещайте несколько операторов на одной строке, если вам нечего скрывать:
	if (condition) do_this; do_something_everytime;	if (condition) do_this; do_something_everytime;
	Don't put multiple assignments on a single line either. Avoid tricky expressions.	И не размещайте несколько операторов присваивания на одной строке. Избегайте сложных выражений.
	Outside of comments and documentation, spaces are never used for indentation, and the above example is deliberately broken.	Пробелы используются только в комментариях и документации, но никогда — для отступов, и приведенный выше пример сломан намеренно.
	Get a decent editor and don't leave whitespace at the end of lines.	Найдите достойный редактор и не оставляйте пробелы в конце строки.
	Chapter 2: Breaking long lines and strings	Глава 2: Разрыв длинных строк
	Coding style is all about readability and maintainability using commonly available tools.	Смысл стиля программирования заключается в читаемости и удобстве сопровождения с использованием общедоступных средств.
	The limit on the length of lines is 80 columns and this is a strongly preferred limit. As for comments, the same limit of 80 columns is applied.	Длина строк ограничена 80 символами, и этому следует уделить особое внимание. Для комментариев установлен тот же лимит в 80 символов.
	Statements longer than 80 columns will be broken into sensible chunks, unless exceeding 80 columns significantly increases readability and does not hide information. Descendants are always substantially shorter than the parent and are placed substantially to the right. The same applies to function headers with a long argument list.	Операторы длиной более 80 символов будут разбиты на логические части. Можно сделать исключение, если это значительно повысит читаемость и не скроет информацию. Последующие части значительно короче основной и сильно смещены вправо. То же относится к заголовкам функций с длинным списком аргументов.
	Chapter 3: Placing Braces and Spaces	Глава 3: Фигурные скобки и пробелы
	The other issue that always comes up in C styling is the placement of braces. Unlike the indent size, there are few technical reasons to choose one placement strategy over the other, but the preferred way, as shown to us by the prophets Kernighan and Ritchie, is to put the opening brace last on the line, and put the closing brace first, thus:	Другая проблемой, которая всегда возникает в программировании на C, — размещение фигурных скобок. В отличие от отступов, есть несколько технических обоснований, чтобы выбрать один способ, а не другой, но всё же предпочтительно, как нам показали великие Керниган и Ричи, поместить открывающую скобку в конце строки, а закрывающую в начале новой строки:
	if (x is true) { we do y }	if (x is true) { we do y }
	This applies to all non-function statement blocks (if, switch, for, while, do). E.g.:	Это применимо ко всем блокам операторов без функций (if, switch, for, while, do), например:
	switch (action) { case KOBJ_ADD: return "add"; case KOBJ_REMOVE: return "remove"; case KOBJ_CHANGE: return "change"; default: return NULL; }	switch (action) { case KOBJ_ADD: return "add"; case KOBJ_REMOVE: return "remove"; case KOBJ_CHANGE: return "change"; default: return NULL; }
	However, there is one special case, namely functions: they have the opening brace at the beginning of the next line, thus:	И только в особенных случаях, а именно для функций, открывающая скобка размещается в начале следующей строки: