Qt Coding Style/es: Difference between revisions

From Qt Wiki
Jump to navigation Jump to search
mNo edit summary
(Update from english version)
 
(2 intermediate revisions by 2 users not shown)
Line 1: Line 1:
{{Cleanup | reason=Auto-imported from ExpressionEngine.}}
{{LangSwitch}}


'''Spanish''' [[Qt_Coding_Style|English]] [[Qt_Coding_Style_Russian|Русский]] [[Qt_Coding_Style_Japanese|日本語]]
[[Category:Developing_Qt::Guidelines]]


[[Category:Developing_Qt::Guidelines]][[Category:Spanish]]
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.


= Guia de estilo de código Qt =
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.


Este es un resumen de las practicas de codificación que usamos al escribir el código de Qt.
== Indentación ==


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.
* 4 espacios por indentación
* Espacios, no tabs!


== Sangrado (Indentación) ==
== Declaración de variables ==


* Usar 4 espacios para sangrar
* Declarar cada variable en una línea distinta
* Espacios, no tabulaciones!
* 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
== Declarando variables ==
* Solo declarar una variable hasta cuando será utilizada
 
* Declarar cada variable en una linea separada
* Evitar nombres cortos siempre que sea posible (ej. "a", "rbarr", "nughdeget")
* Se recomiendan nombres de variables de un solo carácter solamente para usar en contadores y dónde el propósito de la variable es obvio.
* Esperar hasta que sea necesario para declarar una variable


<code>
<code>
Line 35: Line 32:
</code>
</code>


 
* Variables y funciones comienzan con una letra minúscula. Cada palabra consecutiva en el nombre de la variable comienza con una letra mayúscula
* 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.
* Evitar abreviaciones
 
* Evitar la abreviaturas


<code>
<code>
Line 50: Line 45:
</code>
</code>


* Los nombres de las Clases siempre comienzan con una letra mayúscula. Clases publicas comienzan con una 'Q' (QRgb). Las funciones públicas a menudo comienzan con una 'q' (qRgb).
* 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 ==
== Espacios en blanco ==


* Usar líneas en blanco para agrupar declaraciones
* Utilizar líneas vacías para agrupar declaraciones relacionadas
* Siempre usar una línea en blanco
* Siempre utilizar solo una línea vacía
* Siempre usar un espacio en blanco después de un carácter, y antes de un corchete
* Siempre utilizar un espacio en blanco despues de una palabra clave y antes de un paréntesis redondo:


<code>
<code>
Line 68: Line 64:
</code>
</code>


* Para punteros o referencias, siempre usar un espacio en blanco entre el '*' o '&', pero no usarlos entre '*' o '&' y el nombre de la variable
* 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:


<code>
<code>
  char *x;
  char *x;
  const QString &myString;
  const QString &myString;
  const char * const y = "hello";
  const char * const y = "hola";
</code>
</code>


* Envuelva los operadores binarios con espacios
* Rodear operadores binarios con espacios
* Ningún espacio después de un "cast"
* No utilizar espacios despues de un cast
* Evitar los "cast" como en C, en la medida de lo posible
* Evitar cast con estilo de "C" cuando es posible


<code>
<code>
Line 84: Line 80:
  char* blockOfMemory = (char* ) malloc(data.size());
  char* blockOfMemory = (char* ) malloc(data.size());


  // Correcto
  // Correct
  char *blockOfMemory = reinterpret_cast<char*>(malloc(data.size()));
  char *blockOfMemory = reinterpret_cast<char *>(malloc(data.size()));
</code>
 
* 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:
 
<code>
// Incorrecto
if (foo) bar();
 
// Correct
if (foo)
    bar();
</code>
</code>


== Llaves ==
== Paréntesis ==


* Como regla básica, el corchete izquierdo debe estar en la misma linea de inicio de la declaración:
* 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:


<code>
<code>
  // Incorrecto
  // Incorrecto
  if (codec)
  if (codec)
{
}
else
  {
  {
  }
  }
Line 100: Line 111:
  // Correcto
  // Correcto
  if (codec) {
  if (codec) {
} else {
  }
  }
</code>
</code>


* Las implementaciones de funciones y las declaraciones de clase siempre tendrán el corchete izquierdo en una nueva línea:
* 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:


<code>
<code>
  static void foo(int g)
  static void foo(int g)
  {
  {
qDebug("foo: %i", g);
    qDebug("foo: %i", g);
  }
  }


Line 116: Line 128:
</code>
</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.
* Utilizar paréntesis de llave solo cuando el cuerpo de una declaración de condición contiene mas de una línea:


<code>
<code>
Line 124: Line 136:
  }
  }


  for (int i = 0; i < 10; +''i) {
  for (int i = 0; i < 10; ++i) {
     qDebug("%i", i);
     qDebug("%i", i);
  }
  }
Line 132: Line 144:
     return false;
     return false;


  for (int i = 0; i < 10;i)
  for (int i = 0; i < 10; ++i)
     qDebug("%i", i);
     qDebug("%i", i);
</code>
</code>


* Excepción 1: Use llaves a si la declaración padre abarca muchas lineas
* Excepción 1: Utilizar paréntesis también si la declaración padre cubre varias líneas:
 
<code>
<code>
  // Correcto
  // Correcto
Line 146: Line 157:
</code>
</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.
* 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>
<code>
  // Incorrecto
  // Incorrecto
  if (address.isEmpty())
  if (address.isEmpty())
     return false;
     qDebug("empty!");
  else {
  else {
     qDebug("%s", qPrintable(address));
     qDebug("%s", qPrintable(address));
Line 159: Line 171:
  // Correcto
  // Correcto
  if (address.isEmpty()) {
  if (address.isEmpty()) {
     return false;
     qDebug("empty!");
  } else {
  } else {
     qDebug("%s", qPrintable(address));
     qDebug("%s", qPrintable(address));
Line 181: Line 193:
</code>
</code>


* Use llaves cuando el cuerpo de una sentencia condicional este vacía
* Utilizar parentesis de llave cuando el cuerpo de la declaración de un condicional está vacío.


<code>
<code>
Line 191: Line 203:
</code>
</code>


== Paréntesis ==
== Paréntesis ==
* Use paréntesis para agrupar expresiones:
 
* Utilizar paréntesis para agrupar expresiones:


<code>
<code>
Line 208: Line 221:
</code>
</code>


== Declaraciones Switch ==
== Declaración de Switch ==


* El case debe estar en la misma columna que el switch
* Las etiquetas case deben estar en la misma columna que el switch
* Cada declaración case debe tener un break (o return) al final o un comentario que indique porque intencionalmente no hay un break
* 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>
<code>
Line 217: Line 230:
  case Value1:
  case Value1:
   doSomething();
   doSomething();
  break;
  break;
  case Value2:
  case Value2:
case Value3:
   doSomethingElse();
   doSomethingElse();
   // fall through
   Q_FALLTHROUGH();
  default:
  default:
   defaultHandling();
   defaultHandling();
Line 227: Line 241:
</code>
</code>


== Saltos de linea ==
== 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.


* Limite el largo de las lineas a 100 caracteres, inserte saltos de linea si son necesarios
== Quiebres de 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.
* 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>
<code>
// Incorrecto
if (longExpression +
    otherLongExpression +
    otherOtherLongExpression) {
}
  // Correcto
  // Correcto
  if (longExpression
  if (longExpression
Line 239: Line 278:
     + otherOtherLongExpression) {
     + otherOtherLongExpression) {
  }
  }
</code>


// Incorrecto
== Excepciones generales ==
if (longExpression +
    otherLongExpression +
    otherOtherLongExpression) {
}
</code>


== Herencia y la keyword `virtual` ==
* Cuando se siga alguna regla y haga que el código se vea mal, existe total libertad para romper dicha regla


* Cuando reimplemente un método virtual, ''no'' ponga la keyword `virtual` en el archivo header.
== 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>


== Excepción general ==
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));