Documentation/translations/sp_SP/process/4.Coding.rst

File Facts

System

Linux kernel

Corpus path

Documentation/translations/sp_SP/process/4.Coding.rst

Extension

.rst

Size

26094 bytes

Lines

472

Domain

Support Tooling And Documentation

Bucket

Documentation

Inferred role

Support Tooling And Documentation: documentation

Status

atlas-only

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.

Dependency Surface

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

Detected Declarations

• No top-level syscall, struct, function, initcall, or export declaration detected by the generator.

Annotated Snippet

.. include:: ../disclaimer-sp.rst

:Original: Documentation/process/4.Coding.rst
:Translator: Carlos Bilbao <carlos.bilbao.osdev@gmail.com> and Avadhut Naik <avadhut.naik@amd.com>

.. _sp_development_coding:

Conseguir el código correcto
============================

Si bien hay mucho que decir a favor de un proceso de diseño sólido y
orientado a la comunidad, la prueba de cualquier proyecto de desarrollo del
kernel está en el código resultante. Es el código lo que será examinado por
otros desarrolladores y lo que será incluido (o no) en el árbol principal.
Por lo tanto, es la calidad de este código lo que determinará el éxito
final del proyecto.

Esta sección examinará el proceso de programación. Comenzaremos observando
algunas de las maneras en que los desarrolladores del kernel pueden cometer
errores. Luego, el enfoque se dirigirá hacia hacer las cosas bien y las
herramientas que pueden ayudar en dicha búsqueda.

Problemas
---------

Estilo de programación
**********************

El kernel ha tenido durante mucho tiempo un estilo de programación
estándar, descrito en la documentación del kernel en
`Documentation/process/coding-style.rst`. Durante gran parte de ese tiempo,
las políticas descritas en ese archivo se tomaban como, en el mejor de los
casos, orientativas. Como resultado, hay una cantidad considerable de
código en el kernel que no cumple con las pautas de estilo de programación.
La presencia de ese código lleva a dos peligros independientes para los
desarrolladores del kernel.

El primero de estos es creer que los estándares de programación del kernel
no importan y no se aplican. La realidad es que agregar nuevo código al
kernel es muy difícil si ese código no está escrito de acuerdo con el
estándar; muchos desarrolladores solicitarán que el código sea reformateado
antes de revisarlo. Una base de código tan grande como el kernel requiere
cierta uniformidad para que los desarrolladores puedan comprender
rápidamente cualquier parte de él. Así que ya no hay lugar para el código
con formato extraño.

Ocasionalmente, el estilo de programación del kernel entrará en conflicto
con el estilo obligatorio de un empleador. En tales casos, el estilo del
kernel tendrá que prevalecer antes de que el código pueda ser fusionado.
Incluir código en el kernel significa renunciar a cierto grado de control
de varias maneras, incluida la forma en que se formatea el código.

La otra trampa es asumir que el código que ya está en el kernel necesita
urgentemente correcciones de estilo de programación. Los desarrolladores
pueden comenzar a generar parches de reformateo como una forma de
familiarizarse con el proceso o como una forma de incluir su nombre en los
registros de cambios del kernel, o ambos. Pero las correcciones puramente
de estilo de programación son vistas como ruido por la comunidad de
desarrollo; tienden a recibir una recepción adversa. Por lo tanto, este
tipo de parche es mejor evitarlo. Es natural corregir el estilo de una
parte del código mientras se trabaja en él por otras razones, pero los
cambios de estilo de programación no deben hacerse por sí mismos.

El documento de estilo de programación tampoco debe leerse como una ley
absoluta que nunca puede transgredirse. Si hay una buena razón para ir en
contra del estilo (una línea que se vuelve mucho menos legible si se divide
para ajustarse al límite de 80 columnas, por ejemplo), perfecto.

Tenga en cuenta que también puedes usar la herramienta `clang-format` para
ayudarle con estas reglas, para reformatear rápidamente partes de su código

Annotation

• Atlas domain: Support Tooling And Documentation / Documentation.
• Implementation status: atlas-only.

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.