Qt Coding Style/es: Difference between revisions

From Qt Wiki
Jump to navigation Jump to search
No edit summary
 
(Update from english version)
 
(8 intermediate revisions by 3 users not shown)
Line 1: Line 1:
'''Spanish''' [[Qt Coding Style|English]] [[Qt Coding Style Russian|Русский]] [[Qt Coding Style Japanese|日本語]]
{{LangSwitch}}


=Guia de estilo de código Qt=
[[Category:Developing_Qt::Guidelines]]


Este es un resumen de las practicas de codificación que usamos al escribir el código de Qt.
Esta es una revisión a bajo nivel de las convenciones de escritura de programación utilizando Qt.
Ir a [[Coding Conventions]] para las convenciones de alto nivel.


Los datos han sido recogidos de diferentes fuentes relacionas con Qt, foros de discusión, discusiones de correo electrónico y mediante la colaboración de los desarrolladores.
Los datos han sido recopilados desde las fuentes de Qt, foros de discusión, discusiones por email y a través de colaboraciones de los desarrolladores.


==Sangrado (Indentación)==
== Indentación ==


* Usar 4 espacios para sangrar
* 4 espacios por indentación
* Espacios, no tabulaciones!
* Espacios, no tabs!


==Declarando variables==
== Declaración de variables ==


* Declarar cada variable en una linea separada
* Declarar cada variable en una línea distinta
* Evitar nombres cortos siempre que sea posible (ej. “a”, “rbarr”, “nughdeget”)
* Evitar nombres sin sentido y cortos (ejemplo: "a", "rbarr", "nughdeget")
* Se recomiendan nombres de variables de un solo caracter solamente para usar en contadores y dónde el propósito de la variable es obvio.
* Nombres de variables de solo un carácter serán aceptado solo para contadores y variables temporales, donde el propósito de la variable es obvio
* Esperar hasta que sea necesario para declarar una variable
* Solo declarar una variable hasta cuando será utilizada


* El nombre de las variables y las funciones comienza con una letra minúsculas. Las siguientes palabras en el nombre de la variable empiezan con una letra mayúscula.
<code>
// Incorrecto
int a, b;
char *c, *d;


* Evitar la abreviaturas
// Correcto
int height;
int width;
char *nameOfThis;
char *nameOfThat;
</code>


* Los nombres de las Clases siempre comienzan con una letra mayuscular. Clases publicas comienzan con una ‘Q’ (QRgb). Las funciones publicas a menudo comienzan con una ‘q’ (qRgb).
* Variables y funciones comienzan con una letra minúscula. Cada palabra consecutiva en el nombre de la variable comienza con una letra mayúscula
* Evitar abreviaciones


==Espacios en blanco==
<code>
// Incorrecto
short Cntr;
char ITEM_DELIM = ' ';


* Usar lineas en blanco para agrupar declaraciones
// Correcto
* Siempre usar una linea en blanco
short counter;
* Siempre usar un espacio en blanco despues de un carácter, y antes de un corchete
char itemDelimiter = ' ';
</code>


* Para punteros o referencias, siempre usar un espacio en blanco entre el ‘\*’ o ‘&amp;’, pero no usarlos entre ‘\*’ o ‘&amp;’ y el nombre de la variable
* Las clases siempre comienzan con mayúscula. Las clases públicas comienzan con una 'Q' (QRgb) seguida de una letra en mayúscula. Las funciones públicas habitualmente comienzan con una 'q' (qRgb).
* Los acrónimos utilizan camel-case (ejemplo: QXmlStreamReader, no QXMLStreamReader).


* Envuelva los operadores binarios con espacios
== Espacios en blanco ==
* Ningún espacio después de un “cast”
* Evitar los “cast” como en C, en la medida de lo posible


==Llaves==
* Utilizar líneas vacías para agrupar declaraciones relacionadas
* Siempre utilizar solo una línea vacía
* Siempre utilizar un espacio en blanco despues de una palabra clave y antes de un paréntesis redondo:


* Como regla básica, el corchete izquierdo debe estar en la misma linea de inicio de la declaración:
<code>
// Incorrecto
if(foo){
}


* Las implementaciones de funciones y las declaraciones de clase siempre tendrán el corchete izquierdo en una nueva línea:
// Correcto
if (foo) {
}
</code>


* Usar llaves cuando el cuerpo de una declaración condicional contenga mas de una linea, y también si una declaración de una simple linea es algo compleja.
* Para punteros o referencias, siempre utilizar un solo espacio en blano entre el tipo y el '*' o '&', pero sin espacios entre '*' o '&' y el nombre de la variable:


* Excepción 1: Use llaves a si la declaración padre abarca muchas lineas
<code>
char *x;
const QString &myString;
const char * const y = "hola";
</code>


* Excepción 2: Use llaves también en bloques if-then-else, donde el código ‘if’ o el código ‘else’ ocupen varias lineas.
* Rodear operadores binarios con espacios
* No utilizar espacios despues de un cast
* Evitar cast con estilo de "C" cuando es posible


* Use llaves cuando el cuerpo de una sentencia condicional este vacía
<code>
// Incorrecto
char* blockOfMemory = (char* ) malloc(data.size());


==Paréntesis==
// Correct
char *blockOfMemory = reinterpret_cast<char *>(malloc(data.size()));
</code>


* Use paréntesis para agrupar expresiones:
* No escribir multiples declaraciones en una línea
* Por extensión, utilizar una nueva línea para el cuerpo de una declaración de flujo de control:


==Declaraciones Switch==
<code>
// Incorrecto
if (foo) bar();


* El case debe estar en la misma columna que el switch
// Correct
* Cada declaración case debe tener un break (o return) al final o un comentario que indique porque intencionalmente no hay un break
if (foo)
    bar();
</code>


==Saltos de linea==
== Paréntesis ==


* Limite el largo de las lineas a 100 caracteres, inserte saltos de linea si son necesarios
* Utilizar llaves adjuntas: La llave the abre va en la misma línea que la declaración. Si la llave que cierra es seguida por otra palabra clave, se incluye en la misma línea:


* Las comas van al final de una línea quebrada, los operadores deben empezar al principio de la nueva línea. Un operador al final de la línea no es fácil de ver si el editor es demasiado estrecho.
<code>
// Incorrecto
if (codec)
{
}
else
{
}


==Herencia y la keyword `virtual`==
// Correcto
if (codec) {
} else {
}
</code>


* Cuando reimplemente un método virtual, ''no'' ponga la keyword `virtual` en el archivo header.
* Excepción: Las implementaciones de funciones (no lambdas) y las declaraciones de clases  siempre deben tener la llave izquierda al comienzo de una línea:


==Excepción general==
<code>
static void foo(int g)
{
    qDebug("foo: %i", g);
}


* Siéntase libre de romper una regla si esta hace que su código se vea mal.
class Moo
{
};
</code>


===Categories:===
* Utilizar paréntesis de llave solo cuando el cuerpo de una declaración de condición contiene mas de una línea:


* [[:Category:Developing Qt|Developing_Qt]]
<code>
** [[:Category:Developing Qt::Guidelines|Guidelines]]
// Incorrecto
* [[:Category:Spanish|Spanish]]
if (address.isEmpty()) {
    return false;
}
 
for (int i = 0; i < 10; ++i) {
    qDebug("%i", i);
}
 
// Correcto
if (address.isEmpty())
    return false;
 
for (int i = 0; i < 10; ++i)
    qDebug("%i", i);
</code>
 
* Excepción 1: Utilizar paréntesis también si la declaración padre cubre varias líneas:
<code>
// Correcto
if (address.isEmpty() || !isValid()
    || !codec) {
    return false;
}
</code>
 
* Excepción 2: Simetria de paréntesis: Utilizar paréntesis también en bloques if-then-else
donde el código de if o de else considera varias líneas:
 
<code>
// Incorrecto
if (address.isEmpty())
    qDebug("empty!");
else {
    qDebug("%s", qPrintable(address));
    it;
}
 
// Correcto
if (address.isEmpty()) {
    qDebug("empty!");
} else {
    qDebug("%s", qPrintable(address));
    it;
}
 
// Incorrecto
if (a)
    ...
else
    if (b)
        ...
 
// Correcto
if (a) {
    ...
} else {
    if (b)
        ...
}
</code>
 
* Utilizar parentesis de llave cuando el cuerpo de la declaración de un condicional está vacío.
 
<code>
// Incorrecto
while (a);
 
// Correcto
while (a) {}
</code>
 
== Paréntesis  ==
 
* Utilizar paréntesis para agrupar expresiones:
 
<code>
// Incorrecto
if (a && b || c)
 
// Correcto
if ((a && b) || c)
 
// Incorrecto
a + b & c
 
// Correcto
(a + b) & c
</code>
 
== Declaración de Switch ==
 
* Las etiquetas case deben estar en la misma columna que el switch
* Cada case debe tener un break (o return) al final o utilizar <kbd>Q_FALLTHROUGH()</kbd> para indicar que no hay intencionalmente un break, a menos que otro case comience inmediatamente
 
<code>
switch (myEnum) {
case Value1:
  doSomething();
  break;
case Value2:
case Value3:
  doSomethingElse();
  Q_FALLTHROUGH();
default:
  defaultHandling();
  break;
}
</code>
 
== Declaración de saltos (break, continue, return, y goto) ==
 
* No escribir 'else' despues de declaraciones de salto:
 
<code>
// Incorrecto
if (thisOrThat)
    return;
else
    somethingElse();
 
// Correcto
if (thisOrThat)
    return;
somethingElse();
</code>
 
* Excepción: Si el código simétrico, el uso de'else' está permitido para visualizar dicha simetria.
 
== Quiebres de línea ==
 
* Mantener líneas con menos de 100 caracteres; el quebrado es posible si es necesario
** Líneas de comentarios/apidoc deben tener menos de 80 columnas de texto. Adjustar a los alrededores, e intentar continuar el flujo del texto para evitar párrafos "jagged".
* Las comas van al final de las líneas quebradas; los operadores comienzan al inicio de las líneas nuevas. Un operador al final de la línea es fácil de ignorar si el editor es muy estrecho.
 
<code>
// Incorrecto
if (longExpression +
    otherLongExpression +
    otherOtherLongExpression) {
}
 
// Correcto
if (longExpression
    + otherLongExpression
    + otherOtherLongExpression) {
}
</code>
 
== Excepciones generales ==
 
* Cuando se siga alguna regla y haga que el código se vea mal, existe total libertad para romper dicha regla
 
== Estilo artístico ==
El siguiente 'snippet' puede utilizarse para darle un nuevo formato artístico al código:<code>
--style=kr
--indent=spaces=4
--align-pointer=name
--align-reference=name
--convert-tabs
--attach-namespaces
--max-code-length=100
--max-instatement-indent=120
--pad-header
--pad-oper
</code>
 
Notar que "unlimited" --max-instatement-indent es utilizado solo  porque astyle no es suficientemente inteligente para agrupar el primer argumento si las líneas siguientes necesitan limitaciones de indentación. Se le recomienda limitar manualmente in-statement-indent a aproximadamente 50 columnas:
<code>
    int foo = some_really_long_function_name(and_another_one_to_drive_the_point_home(
            first_argument, second_argument, third_arugment));
</code>

Latest revision as of 09:18, 6 February 2018

En Ar Bg De El Es Fa Fi Fr Hi Hu It Ja Kn Ko Ms Nl Pl Pt Ru Sq Th Tr Uk Zh

Esta es una revisión a bajo nivel de las convenciones de escritura de programación utilizando Qt. Ir a Coding Conventions para las convenciones de alto nivel.

Los datos han sido recopilados desde las fuentes de Qt, foros de discusión, discusiones por email y a través de colaboraciones de los desarrolladores.

Indentación

  • 4 espacios por indentación
  • Espacios, no tabs!

Declaración de variables

  • Declarar cada variable en una línea distinta
  • Evitar nombres sin sentido y cortos (ejemplo: "a", "rbarr", "nughdeget")
  • Nombres de variables de solo un carácter serán aceptado solo para contadores y variables temporales, donde el propósito de la variable es obvio
  • Solo declarar una variable hasta cuando será utilizada
 // Incorrecto
 int a, b;
 char *c, *d;

 // Correcto
 int height;
 int width;
 char *nameOfThis;
 char *nameOfThat;
  • Variables y funciones comienzan con una letra minúscula. Cada palabra consecutiva en el nombre de la variable comienza con una letra mayúscula
  • Evitar abreviaciones
 // Incorrecto
 short Cntr;
 char ITEM_DELIM = ' ';

 // Correcto
 short counter;
 char itemDelimiter = ' ';
  • Las clases siempre comienzan con mayúscula. Las clases públicas comienzan con una 'Q' (QRgb) seguida de una letra en mayúscula. Las funciones públicas habitualmente comienzan con una 'q' (qRgb).
  • Los acrónimos utilizan camel-case (ejemplo: QXmlStreamReader, no QXMLStreamReader).

Espacios en blanco

  • Utilizar líneas vacías para agrupar declaraciones relacionadas
  • Siempre utilizar solo una línea vacía
  • Siempre utilizar un espacio en blanco despues de una palabra clave y antes de un paréntesis redondo:
 // Incorrecto
 if(foo){
 }

 // Correcto
 if (foo) {
 }
  • Para punteros o referencias, siempre utilizar un solo espacio en blano entre el tipo y el '*' o '&', pero sin espacios entre '*' o '&' y el nombre de la variable:
 char *x;
 const QString &myString;
 const char * const y = "hola";
  • Rodear operadores binarios con espacios
  • No utilizar espacios despues de un cast
  • Evitar cast con estilo de "C" cuando es posible
 // Incorrecto
 char* blockOfMemory = (char* ) malloc(data.size());

 // Correct
 char *blockOfMemory = reinterpret_cast<char *>(malloc(data.size()));
  • No escribir multiples declaraciones en una línea
  • Por extensión, utilizar una nueva línea para el cuerpo de una declaración de flujo de control:
 // Incorrecto
 if (foo) bar();

 // Correct
 if (foo)
     bar();

Paréntesis

  • Utilizar llaves adjuntas: La llave the abre va en la misma línea que la declaración. Si la llave que cierra es seguida por otra palabra clave, se incluye en la misma línea:
 // Incorrecto
 if (codec)
 {
 }
 else
 {
 }

 // Correcto
 if (codec) {
 } else {
 }
  • Excepción: Las implementaciones de funciones (no lambdas) y las declaraciones de clases siempre deben tener la llave izquierda al comienzo de una línea:
 static void foo(int g)
 {
     qDebug("foo: %i", g);
 }

 class Moo
 {
 };
  • Utilizar paréntesis de llave solo cuando el cuerpo de una declaración de condición contiene mas de una línea:
 // Incorrecto
 if (address.isEmpty()) {
     return false;
 }

 for (int i = 0; i < 10; ++i) {
     qDebug("%i", i);
 }

 // Correcto
 if (address.isEmpty())
     return false;

 for (int i = 0; i < 10; ++i)
     qDebug("%i", i);
  • Excepción 1: Utilizar paréntesis también si la declaración padre cubre varias líneas:
 // Correcto
 if (address.isEmpty() || !isValid()
     || !codec) {
     return false;
 }
  • Excepción 2: Simetria de paréntesis: Utilizar paréntesis también en bloques if-then-else
donde el código de if o de else considera varias líneas:
 // Incorrecto
 if (address.isEmpty())
     qDebug("empty!");
 else {
     qDebug("%s", qPrintable(address));
     it;
 }

 // Correcto
 if (address.isEmpty()) {
     qDebug("empty!");
 } else {
     qDebug("%s", qPrintable(address));
     it;
 }

 // Incorrecto
 if (a)
     ...
 else
     if (b)
         ...

 // Correcto
 if (a) {
     ...
 } else {
     if (b)
         ...
 }
  • Utilizar parentesis de llave cuando el cuerpo de la declaración de un condicional está vacío.
 // Incorrecto
 while (a);

 // Correcto
 while (a) {}

Paréntesis

  • Utilizar paréntesis para agrupar expresiones:
 // Incorrecto
 if (a && b || c)

 // Correcto
 if ((a && b) || c)

 // Incorrecto
 a + b & c

 // Correcto
 (a + b) & c

Declaración de Switch

  • Las etiquetas case deben estar en la misma columna que el switch
  • Cada case debe tener un break (o return) al final o utilizar Q_FALLTHROUGH() para indicar que no hay intencionalmente un break, a menos que otro case comience inmediatamente
 switch (myEnum) {
 case Value1:
   doSomething();
   break;
 case Value2:
 case Value3:
   doSomethingElse();
   Q_FALLTHROUGH();
 default:
   defaultHandling();
   break;
 }

Declaración de saltos (break, continue, return, y goto)

  • No escribir 'else' despues de declaraciones de salto:
 // Incorrecto
 if (thisOrThat)
     return;
 else
     somethingElse();

 // Correcto
 if (thisOrThat)
     return;
 somethingElse();
  • Excepción: Si el código simétrico, el uso de'else' está permitido para visualizar dicha simetria.

Quiebres de línea

  • Mantener líneas con menos de 100 caracteres; el quebrado es posible si es necesario
    • Líneas de comentarios/apidoc deben tener menos de 80 columnas de texto. Adjustar a los alrededores, e intentar continuar el flujo del texto para evitar párrafos "jagged".
  • Las comas van al final de las líneas quebradas; los operadores comienzan al inicio de las líneas nuevas. Un operador al final de la línea es fácil de ignorar si el editor es muy estrecho.
 // Incorrecto
 if (longExpression +
     otherLongExpression +
     otherOtherLongExpression) {
 }

 // Correcto
 if (longExpression
     + otherLongExpression
     + otherOtherLongExpression) {
 }

Excepciones generales

  • Cuando se siga alguna regla y haga que el código se vea mal, existe total libertad para romper dicha regla

Estilo artístico

El siguiente 'snippet' puede utilizarse para darle un nuevo formato artístico al código:

--style=kr 
--indent=spaces=4 
--align-pointer=name 
--align-reference=name 
--convert-tabs 
--attach-namespaces
--max-code-length=100 
--max-instatement-indent=120 
--pad-header
--pad-oper

Notar que "unlimited" --max-instatement-indent es utilizado solo porque astyle no es suficientemente inteligente para agrupar el primer argumento si las líneas siguientes necesitan limitaciones de indentación. Se le recomienda limitar manualmente in-statement-indent a aproximadamente 50 columnas:

    int foo = some_really_long_function_name(and_another_one_to_drive_the_point_home(
            first_argument, second_argument, third_arugment));