Documentation/translations/sp_SP/process/coding-style.rst

File Facts

System

Linux kernel

Corpus path

Documentation/translations/sp_SP/process/coding-style.rst

Extension

.rst

Size

49904 bytes

Lines

1316

Domain

Support Tooling And Documentation

Bucket

Documentation

Inferred role

Support Tooling And Documentation: exported/initcall integration point

Status

integration implementation candidate

Why This File Exists

Repository support layer: documentation, build tooling, samples, user-space helper tools, generated initramfs support, licenses, and validation utilities.

• Repository support layer: documentation, build tooling, samples, user-space helper tools, generated initramfs support, licenses, and validation utilities.
• Exports symbols or registers init work; inspect boot/module ordering and who consumes the exported contract.
• Allocates kernel memory; connect allocation flags and lifetime to context constraints.
• Defines or uses C structs; map object ownership, embedded links, reference counts, and lock ownership.

Dependency Surface

• No C-style include directives detected by the generator.

Detected Declarations

• function funcion
• function texto
• function fun
• export sistema_corriendo

Annotated Snippet

if (condition1) {
			while (loop1) {
				...
			}
			result = 1;
			goto out_free_buffer;
		}
		...
	out_free_buffer:
		kfree(buffer);
		return result;
	}

Un tipo común de error a tener en cuenta es "un error de error" que es algo
así:

.. code-block:: c

	err:
		kfree(foo->bar);
		kfree(foo);
		return ret;

El error en este código es que en algunas rutas de salida, ``foo`` es NULL.
Normalmente la solución para esto es dividirlo en dos etiquetas de error
``err_free_bar:`` y ``err_free_foo:``:

.. code-block:: c

	err_free_bar:
		kfree(foo->bar);
	err_free_foo:
		kfree(foo);
		return ret;

Idealmente, debería simular errores para probar todas las rutas de salida.


8) Comentarios
--------------

Los comentarios son buenos, pero también existe el peligro de comentar
demasiado. NUNCA trate de explicar CÓMO funciona su código en un
comentario: es mucho mejor escribir el código para que el
**funcionamiento** sea obvio y es una pérdida de tiempo explicar código mal
escrito.

Generalmente, desea que sus comentarios digan QUÉ hace su código, no CÓMO.
Además, trate de evitar poner comentarios dentro del cuerpo de una función:
si la función es tan compleja que necesita comentar por separado partes de
esta, probablemente debería volver al capítulo 6 una temporada. Puede
hacer pequeños comentarios para notar o advertir sobre algo particularmente
inteligente (o feo), pero trate de evitar el exceso. En su lugar, ponga los
comentarios al principio de la función, diga a la gente lo que hace y
posiblemente POR QUÉ hace esto.

Al comentar las funciones de la API del kernel, utilice el formato
kernel-doc. Consulte los archivos en :ref:`Documentation/doc-guide/ <doc_guide>`
y ``tools/docs/kernel-doc`` para más detalles.

El estilo preferido para comentarios largos (de varias líneas) es:

.. code-block:: c

	/*
	* Este es el estilo preferido para comentarios
	* multilínea en el código fuente del kernel Linux.
	* Por favor, utilícelo constantemente.
	*
	* Descripción: Una columna de asteriscos en el lado izquierdo,

Annotation

• Detected declarations: `function funcion`, `function texto`, `function fun`, `export sistema_corriendo`.
• Atlas domain: Support Tooling And Documentation / Documentation.
• Implementation status: integration implementation candidate.

Implementation Notes

• This generated page is the file-by-file coverage layer; curated subsystem chapters should link here when they synthesize a multi-file control flow.
• Core OS pages should be promoted from atlas-only to deep-reviewed when they explain data structures, invariants, locking, lifecycle, and C implementation snippets.
• Driver-family pages are intentionally pattern-oriented unless they are part of the selected PCIe/NVMe representative device path.