Qt wiki will be updated on October 12th 2023 starting at 11:30 AM (EEST) and the maintenance will last around 2-3 hours. During the maintenance the site will be unavailable.

Qt Coding Style/es

From Qt Wiki
< Qt Coding Style
Revision as of 09:18, 6 February 2018 by CristianMaureiraFredes (talk | contribs) (Update from english version)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigation Jump to search

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));