Crear guía de estilo de código

[edoren]

Recomiendo usar esta guía para manejo del código Google C++ Style Guide

[adrigm]

Pienso que la guía de estilo de Google es muy estricta para nuestro propósito. Optaría más por unas pequeñas directrices y gran uso del sentido común.

Podéis ir viendola aquí: https://github.com/genbetadev/Genbeta-Dev-Engine/wiki/Gu%C3%ADa-de-estilo-del-c%C3%B3digo

[DavidBM]

@adrigm Siempre me ha parecido mejor la identación con tabs. Cada uno puede configurar la cantidad de espacios que representa cada tab. Y si se ponen espacios algunos editores tiene problemas a la hora de intentar cambiar el ancho de la columna de identación.

En el resto, coincido contigo en poner algo más sencillo. Más que nada por que habrá gente que no tenga el ánimo de leerse algo como lo de Google.

[adrigm]

@DavidBM concuerdo contigo, se supone que se suelen usar espacios para conseguir que en todos los sitios se vea igual el código, pero los tabs dan más opciones de que cada uno lo adapte a su gusto.

Si nadie tiene objeción usaremos tabuladores.

[luis-martinez-herrera]

Creo que el uso de this daría una mejor comprensión del codigo

[adrigm]

@luismh, ¿Usar this-> siempre obligatoriamente en lugar de el prefijo m?

¿No haría las sentencias demasiado largas? Esto abierto a sugerencias en este tema ahora que estamos empezando, es un proyecto en comunidad. Espero opiniones.

[RdlP]

No es realmente necesario usar "this->" de hecho como bien dices haría el código más largo y siempre que se tenga en cuenta que cualquier variable que empieza por "m" es una variable miembro no habría ningún tipo de confusión. Lo que pasa que aquí cada uno programamos de una manera y por tanto son costumbres nuestras.

Yo personalmente siempre uso "this->" pero me adaptaré a lo que se decida.

[adrigm]

de acuerdo con @RdlP en que al final es cuestión de gustos.

Por ahora tenemos como ventaja para el prefijo mVariable que produce sentencias más cortas.

[luis-martinez-herrera]

Es verdad que es cuestión de gustos, aunque a mi parecer ayuda a entender rápidamente el código. En todo caso queda permitido o no su uso.

Y respecto a que se generan sentencias más cortas, 6 caracteres hace mucha diferencia?

[adrigm]

@luismh cuando se tienen varias variables miembros en la misma sentencia sí que crece bastante la línea. Mira esta línea de código:

this->setTextureRect(sf::IntRect(this->getTextureRect().left + this->getTextureRect().width, this->getTextureRect().top, - this->getTextureRect().width, this->getTextureRect().height));

Ahora comparemos con esta:

setTextureRect(sf::IntRect(getTextureRect().left + getTextureRect().width, getTextureRect().top, - getTextureRect().width, getTextureRect().height));

La de arriba puede que sea algo más clara que la de abajo, pero esta es más corta. ¿Que merece más la pena?

PD: EL editor las corta, pero van en una sola línea.

[adrigm]

La verdad es que viendo ahora ambas líneas juntas, tampoco es un gran significativo el ahorro de caracteres que se hace y eso que este es un caso extremo con hasta 6 this.

Además que el identificador mVariable sería para las variables miembro y no para los métos. Con this distinguiríamos perfectamente tanto los métodos como variables.

Mi voto va por el uso de this, también.

[DavidBM]

Yo personalmente uso this-> siempre. Así que mi voto va por usar this. Me parece una forma que no cuesta mucho y permite de un vistazo saber donde estás operando.

[rgcl]

Mi voto definitivamente es para el this->, no es necesario inventar artilugios artesanales al lenguaje (notación húngara) cuando el lenguaje tiene sus propios artilugios. En C++, this-> universalmente es this->. (Hola :)

[edoren]

De acuerdo con el uso de this->.

[adrigm]

Bueno veo que la mayoría está de acuerdo en el uso de this-> para las variables.

Planteo otra cuestión, ¿Debemos también añadirlo a los métodos?

[DavidBM]

Yo opino que sí. Usar this-> para referenciar a todo lo perteneciente a la clase.

[luis-martinez-herrera]

de acuerdo con @DavidBM

[rgcl]

de acuerdo con @luismh

[adrigm]

Usaremos this-> para todo entonces, decidido.

[zerazobz]

Esta cerrado, pero bueno yo tengo una consulta: En la Guía de estilo del código del 1er articulo: 'GDE: Estructura del proyecto'. Hay una regla que dice: using namespace esta totalmente prohibido

Quisiera saber porque esta prohibido, siempre he hecho c#(ASP MVC) y para mi es natural el usar los using. De todos modos no hay problema, pero desearia saber si la razon podria ser 'evitar conflictos entre diversos elementos de diferentes namespace's' o hay otra razon de peso?

Gracias.

[dsocolobsky]

Supongo que sera mas que nada por evitar conflictos, y con mas peso en un proyecto como este. Tarde o temprano, GDE va a tener alguna clase con el mismo nombre que SFML, por ejemplo, digamos que tenemos GDE::Texture y sf::Texture, con el fin de evitar conflictos y confusiones, es mucho mejor si utilizamos los namespaces de esa forma, y no incluyéndolos completamente.

[DavidBM]

El la wiki dice que se identa con 4 espacios. Pero creo que dijimos con tabs. Identamos con 4 espacios entonces?

[adrigm]

@zerazobz aparte de lo que comenta @dysoco, el uso de namespace facilita ver rápidamente a que biblioteca pertenece un elemento, ya que están vamos a usarlos correctamente.

@DavidBM con tabuladores, hay que corregir la guía de estilo

[ficion]

Perdón por lo de los tabuladores, es mi culpa. Cuando editaba el archivo leí "se identa con cuatro espacios" y pensé "entonces sin tabuladores".

[zerazobz]

@adrigm Otro duda que tengo es respecto a:

'El código dentro de las llaves de un namespace no se sangra como otro bloque.'

Supongo que es por practicidad y/o porque en un archivo solo existe una declaracion 'namespace'.

[adrigm]

@zerazobz Todos los archivos van a tener el namespace GDE, identar todo el código un nivel en todos los archivos creo que reste claridad.