Qt Coding Style/es: Difference between revisions
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: | ||
{{ | {{LangSwitch}} | ||
[[Category:Developing_Qt::Guidelines]] | |||
[[ | 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 | |||
* Declarar cada variable en una | |||
* Evitar nombres cortos | |||
* | |||
* | |||
<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 | |||
* | * Evitar abreviaciones | ||
* Evitar | |||
<code> | <code> | ||
Line 50: | Line 45: | ||
</code> | </code> | ||
* | * 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 == | ||
* | * Utilizar líneas vacías para agrupar declaraciones relacionadas | ||
* Siempre | * Siempre utilizar solo una línea vacía | ||
* Siempre | * 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 | * 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 = " | const char * const y = "hola"; | ||
</code> | </code> | ||
* | * Rodear operadores binarios con espacios | ||
* | * No utilizar espacios despues de un cast | ||
* Evitar | * 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()); | ||
// | // 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> | ||
== | == 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: | ||
<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 | * 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); | |||
} | } | ||
Line 116: | Line 128: | ||
</code> | </code> | ||
* | * 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; + | 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: | * 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: | * 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()) | ||
qDebug("empty!"); | |||
else { | else { | ||
qDebug("%s", qPrintable(address)); | qDebug("%s", qPrintable(address)); | ||
Line 159: | Line 171: | ||
// Correcto | // Correcto | ||
if (address.isEmpty()) { | if (address.isEmpty()) { | ||
qDebug("empty!"); | |||
} else { | } else { | ||
qDebug("%s", qPrintable(address)); | qDebug("%s", qPrintable(address)); | ||
Line 181: | Line 193: | ||
</code> | </code> | ||
* | * 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 == | ||
* | |||
* Utilizar paréntesis para agrupar expresiones: | |||
<code> | <code> | ||
Line 208: | Line 221: | ||
</code> | </code> | ||
== | == Declaración de Switch == | ||
* | * Las etiquetas case deben estar en la misma columna que el switch | ||
* Cada | * 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; | |||
case Value2: | case Value2: | ||
case Value3: | |||
doSomethingElse(); | doSomethingElse(); | ||
Q_FALLTHROUGH(); | |||
default: | default: | ||
defaultHandling(); | defaultHandling(); | ||
Line 227: | Line 241: | ||
</code> | </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 == | |||
* Las comas van al final de | * 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> | |||
== 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
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));