PilasC++ - Lineamientos (estilo, herramientas...)

[Geo]

Actualización:
En este primer post colocaré los lineamientos que se han acordado, para que sea más fácil enterarse o recordarlos .

Identificadores

• Los nombres de identificadores se escriben usando palabras en español, en caso de necesitar la letra ñ, se debe buscar un sinónimo, de no encontrarse uno adecuado, sustituirla por... (nn o ni).

Espacios de nombres

• TODO el código que se desarrolle como parte del motor estará dentro del espacio de nombres Pilas, conforme avance el proyecto y crezca el código se decidirá si se usan divisiones.

Clases

• Las clases se nombran con mayúscula inicial, el resto minúsculas, sin usar decoradores, ejemplo: Clase.
• Utilizar siempre clases y nunca structs.
• Las funciones miembro se escriben todas con minúsculas, usando guión bajo (_) como separador entre palabras, ejemplo: Clase::funcion_miembro();
• Las variables miembro siguen una nomenclatura similar a las funciones, con la excepción de que al nombrarlas se preceden con m_, ejemplo: Clase::m_variable_miembro;
• Las funciones se nombran en infinitivo, excepto las que devuelven valores tipo bool, ejemplo:
  

  Código: Seleccionar todo

  void Actor::establecer_rotacion( float rotacion );
void Mono::gritar();
bool Actor::colisiona_con_punto( int x, int y );


  
  Esto permite identificar más fácilmente entre funciones que indican acciones y funciones que evalúan estados.
• Seguir la regla de const-correctness: todos aquellos métodos que no modifiquen al objeto deberán ser identificados como constantes, así como los parámetros de los métodos.
• Los archivos se nombran... (clase.h o Clase.h).
• Los guards de cabeceras... (CLASE_H o Clase_H

Otros

• Los corchetes que delimitan un bloque de código, se escriben en su propia línea y alineados al nombre de la función o instrucción que inicia el bloque.
• Utilizar enum y constantes en lugar de #define.
• Procurar no exceder 80 caracteres por línea al escribir código, tratando siempre de facilitar la lectura.
• Usar espacios en lugar de tabuladores para indentar código, siendo X espacios por nivel de indentación.
• Los operadores van separados un espacio de los identificadores que intervienen en la operación, el código colocado dentro de un paréntesis va distanciado de ellos por un espacio, se usa un espacio después de una coma, ejemplos:
  

  Código: Seleccionar todo

  x + y; // no x+y;
( int parametro1, int parametro2 ); // no (int param1,int param2);


• En el caso de funciones, el paréntesis que inicia la lista de parámetros va junto al nombre de la función, sin separación. No así para el caso de bucles, sentencias condicionales y demás, donde el paréntesis irá separado de la sentencia usando un espacio, ejemplo:
  

  Código: Seleccionar todo

  Clase::metodo( int parametro )
if ( condicion )


• Los modificadores (referencias y punteros), se colocan junto al identificador que indica el tipo de dato, no junto al nombre de la instancia que se está declarando. Ejemplo: Clase& objeto; en lugar de Clase &objeto;
  Si es necesario declarar varias referencias o punteros de un mismo tipo, hacerlo en líneas diferentes, es decir:
  

  Código: Seleccionar todo

  Clase* puntero1;
Clase* puntero2;


• Se usa cmake como herramienta para automatizar la construcción del código.

----------------------------------------------------------
Abro esta discusión para que definamos detalles del estilo de codificación de la versión C++ del motor, ya he mencionado que el código que empecé eran más bien pruebas conceptuales, pero viendo que ya hay código para contribuir, debemos dejar todo definido para que sea más sencillo continuar .

Empiezo con lo que estaba yo trabajando, pero según acordemos modifico para que todo quede en el primer post para fácil referencia. Además, creo debemos esperar a que se decida "oficialmente" si los identificadores irán en inglés o español.

Repito, esto es lo que yo estaba usando en mis pruebas:

Espacios de nombres
- TODO el código que se desarrolle como parte del motor estará dentro de un mismo espacio de nombres: Pilas.

Clases
- Nombres de identificadores en español, en el caso de una letra ñ sustituirla por dos n, así: tamaño => tamanno.
- Nombres de clases con mayúscula inicial, sin caracteres identificadores (del tipo CClase), ejemplo: Clase.
- Funciones miembro escritas todas con minúsculas, palabras separadas por guión bajo (_), ejemplo: Clase::funcion_miembro()
- Variables miembro, nomenclatura similar a las funciones miembro, anteponiendo al nombre los caracters m_, ejemplo: Clase::m_variable

Bien, a reserva de que deberíamos tratar de unificar con el estilo de la versión "principal" (en Python), y decidir "oficialmente" con respecto al español, veamos sus ideas para definir esto .
En cuanto a herramientas, Juanxo recomendó usar cmake en lugar de archivos Make "a mano" (¿o autotools?), aunque no lo he usado he estado leyendo que es bastante mejor que los otros métodos, así que a mi me parece bien . ¿Qué piensan los demás?

[Juanxo]

buenas a todos, ahí van mis ideas:

+1 a lo del espacio de nombres Pilas. Más adelante incluso podríamos subdividir si vemos que sale demasiado grande, en cosas como IA, escena, etc.

Clases:
- Utilizar siempre clases y nunca structs, ya que permiten lo mismo y C++ tiene como parte principal las clases (los structs son por compatibilidad con C)
- el tema de las ñ yo siempre lo he cambiado por ni, pero es un detalle sin importancia: tamaño -> tamanio
- +1 a lo de nombres de clases de Geo
- En los métodos difiero contigo Geo, ya que yo suelo usar todas letras minúsculas menos iniciales de palabras . Clase::funcionMiembro()
- Atributos yo suelo hacerlos como Geo, pero sin el guión bajo de por medio y el identificador mayúsculas, pero no es algo que me cueste acostumbrarme. Clase::mVariable
- Seguir la regla de const-correctness: todos aquellos métodos que no modifiquen al objeto deberán ser identificados como constantes, así como los parámetros de los métodos.
- Los nombres de los archivos tendrán el mismo nombre que la clase que implementan: class Player -> Player.h /Player.cpp
- Las estructuras de las clases serán: public, protected, private
- Las únicas funciones que implemento en la declaración son los constructores, siempre que sean mediante listas de inicialización: Clase(int valor) : m_atributo(valor) {}. El resto de funciones que quiera convertir a inline las implemento después de haber declarado la clase, o si es posible en un archivo .inl que incluyo al final de la cabecera
- Los guard de las cabeceras suelo definirlas con el mismo nombre que la clase, respetando las mayusculas y minúsculas: #ifndef Clase_H, en vez de #infdef CLASE_H

Varios:
- Por temas de facilidad de depuración, suelo usar Enums y constantes en vez de #define
- Trato de que las lineas no superen los 80 caracteres, por temas de visibilidad y por si se hace necesario imprimir código

Perdonar por el tono autoritario en alguna norma, pero es que así es como debe escribirse una norma xD. Por supuesto son todas subjetivas de ser discutidas.

En cuanto a lo de herramientas, lo bueno de CMake es que es independiente del IDE, lo que nos permite trabajar con el que más nos guste, y crea multitud de archivos de proyecto. Además, podemos automatizar para que con un pequeño script cree el archivo del proyecto (makefile o vsproject) para ejecutarlo cada vez que actualizamos el proyecto. Por cierto, tal y como esta planteado ahora, todo archivo que metáis en las carpetas de cabeceras y de códigos será automáticamente añadido al proyecto sin necesidad de nada nuevo

[Geo]

+1 a lo del espacio de nombres Pilas. Más adelante incluso podríamos subdividir si vemos que sale demasiado grande, en cosas como IA, escena, etc.
- Utilizar siempre clases y nunca structs, ya que permiten lo mismo y C++ tiene como parte principal las clases (los structs son por compatibilidad con C)
- +1 a lo de nombres de clases de Geo
- Seguir la regla de const-correctness: todos aquellos métodos que no modifiquen al objeto deberán ser identificados como constantes, así como los parámetros de los métodos.
- Las estructuras de las clases serán: public, protected, private

Varios:
- Por temas de facilidad de depuración, suelo usar Enums y constantes en vez de #define
- Trato de que las lineas no superen los 80 caracteres, por temas de visibilidad y por si se hace necesario imprimir código

A menos que alguien opine diferente, creo que esto se quedaría, y sobre el resto hay que llegar a un acuerdo, necesitamos opiones ¿carlostex?

- el tema de las ñ yo siempre lo he cambiado por ni, pero es un detalle sin importancia: tamaño -> tamanio

También lo he hecho, pero voto por nn, ¿quién define?

- En los métodos difiero contigo Geo, ya que yo suelo usar todas letras minúsculas menos iniciales de palabras . Clase::funcionMiembro()

Aquí traté de tener uniformidad con la versión Python, así es como los está manejando Hugo, suelo usar la forma que mencionas, pero también quiero probar esta .

- Atributos yo suelo hacerlos como Geo, pero sin el guión bajo de por medio y el identificador mayúsculas, pero no es algo que me cueste acostumbrarme. Clase::mVariable
- Los nombres de los archivos tendrán el mismo nombre que la clase que implementan: class Player -> Player.h /Player.cpp
- Las únicas funciones que implemento en la declaración son los constructores, siempre que sean mediante listas de inicialización: Clase(int valor) : m_atributo(valor) {}. El resto de funciones que quiera convertir a inline las implemento después de haber declarado la clase, o si es posible en un archivo .inl que incluyo al final de la cabecera
- Los guard de las cabeceras suelo definirlas con el mismo nombre que la clase, respetando las mayusculas y minúsculas: #ifndef Clase_H, en vez de #infdef CLASE_H

- Prefiero nombres de archivos todos en minúsculas.
- Pongo inline las funciones set/get establecer/obtener.
- Los guard los pongo todos en mayúsculas, sin decoradores, ejemplo #ifndef CLASE_H

Yo mantengo la idea de tener "cierta uniformidad" con la versión Python, pero estamos de acuerdo en que podemos adaptarnos, la idea es intentar que quede definido desde ahora¿Alguien más opina?

Olvidaba detalles sobre los nombres de funciones, pensando en que serán en español:
- Nombres de funciones en infinitivo excepto las que devuelven bool, ejemplos:
void Actor::establecer_rotacion( float rotacion );
void Mono::gritar();
bool Actor::colisiona_con_punto( int x, int y );

Perdonar por el tono autoritario en alguna norma, pero es que así es como debe escribirse una norma xD. Por supuesto son todas subjetivas de ser discutidas.

En cuanto a lo de herramientas, lo bueno de CMake es que es independiente del IDE, lo que nos permite trabajar con el que más nos guste, y crea multitud de archivos de proyecto. Además, podemos automatizar para que con un pequeño script cree el archivo del proyecto (makefile o vsproject) para ejecutarlo cada vez que actualizamos el proyecto. Por cierto, tal y como esta planteado ahora, todo archivo que metáis en las carpetas de cabeceras y de códigos será automáticamente añadido al proyecto sin necesidad de nada nuevo

Todavía tengo que probarlo .

[hugoruscitti]

- el tema de las ñ yo siempre lo he cambiado por ni, pero es un detalle sin importancia: tamaño -> tamanio

Una idea: ¿se podrían encontrar sinónimos no?. Se que es difícil pensarlos, pero creo
que en este caso están la "escala" y la "magnitud".

[Juanxo]

@Geo: esto es un tema de trabajo en equipo, así que ya que tu has aceptado algunas proposiciones mías, yo acepto las demás, solo un par de apuntes:
- No había caido en el tema de compatibilidad con la parte de Python. Me parece bien lo que comentas de mantener una misma línea, facilitando el cambio de un lenguaje a otro.
- En cuanto a lo de las funciones inline, yo no hablaba de eliminarlas, sino de simplemente declararlas en la cabecera e implementarlas al final del archivo .h, para que no estorbe y reste claridad.

Más cosas que se me han ocurrido:
- Llaves abren y cierran en nueva línea, y se sitúan a la altura del comienzo de la función. Ejemplo:
Mal

Código: Seleccionar todo

Clase::metodo(int parametro) {
}
Clase::metodo(int parametro)
      {
      }
Clase::metodo(int parametro)
{
    mAtributo = parametro;}
Bien
Clase::metodo(int parametro)
{
     mAtributo = parametro;
}


- Yo suelo establecer indentaciones de 2 blancos (no tabulaciones, ya que el tamaño de las tabulaciones difiere entre programas y SO). Muchos IDEs te permiten usar tabulador y ellos lo transforman directamente en el número de blancos definido
- Yo suelo separar los operadores, las comas, etc: Ejemplo: x + y en vez de x+y. (int param1, int param2) en vez de (int param1,int param2).
- Los paréntesis van junto al nombre de la funcion, pero se separa en el caso de bucles, condicionales y demás para distinguirlos de las funciones: Ejemplo Clase::metodo(int parametro) y if (condicion)
- Los modificadores de tipo (&, *) yo los suelo poner junto al tipo. Ejemplo: Clase& objeto, no Clase &objeto.

Creo que esto es casi todo lo que se me ocurre de momento. Sería bueno que los que vamos a participar (de momento estamos 3 o 4) comentasemos al respecto, ya que es tontería avanzar si vamos a tener que cambiarlo luego. A ver si podemos crear un pequeño documento de estilo cuando este todo acabado

[Geo]

- el tema de las ñ yo siempre lo he cambiado por ni, pero es un detalle sin importancia: tamaño -> tamanio

Una idea: ¿se podrían encontrar sinónimos no?. Se que es difícil pensarlos, pero creo
que en este caso están la "escala" y la "magnitud".

No lo había pensado, sería la mejor opción, de cualquier forma hay que saber qué poner en caso de que no se encuentre algo adecuado.

@Geo: esto es un tema de trabajo en equipo, así que ya que tu has aceptado algunas proposiciones mías, yo acepto las demás, solo un par de apuntes:
- No había caido en el tema de compatibilidad con la parte de Python. Me parece bien lo que comentas de mantener una misma línea, facilitando el cambio de un lenguaje a otro.
- En cuanto a lo de las funciones inline, yo no hablaba de eliminarlas, sino de simplemente declararlas en la cabecera e implementarlas al final del archivo .h, para que no estorbe y reste claridad.

Más cosas que se me han ocurrido:
- Llaves abren y cierran en nueva línea, y se sitúan a la altura del comienzo de la función. Ejemplo:

@Juanxo, normalmente abro las llaves en la misma línea que la función o sentencia que la necesita, pero me parece bien como propones.

- Yo suelo establecer indentaciones de 2 blancos (no tabulaciones, ya que el tamaño de las tabulaciones difiere entre programas y SO). Muchos IDEs te permiten usar tabulador y ellos lo transforman directamente en el número de blancos definido

Me parece bien, solo un detalle, las declaraciones public, private y protected ¿se indentan o no? Yo no suelo hacerlo.

- Yo suelo separar los operadores, las comas, etc: Ejemplo: x + y en vez de x+y. (int param1, int param2) en vez de (int param1,int param2).

Comparto la idea, yo lo extiendo a los paréntesis, ejemplo: ( int param1, int param2 ).

- Los paréntesis van junto al nombre de la funcion, pero se separa en el caso de bucles, condicionales y demás para distinguirlos de las funciones: Ejemplo Clase::metodo(int parametro) y if (condicion)
- Los modificadores de tipo (&, *) yo los suelo poner junto al tipo. Ejemplo: Clase& objeto, no Clase &objeto.

Lo hago igual y me parece correcto, solo definir qué hacer cuando se quieren declarar varios punteros o referencias de un mismo tipo, debería hacerse en nueva línea:

Código: Seleccionar todo

// Así:
Clase* puntero1;
Clase* puntero2;
// No así:
Clase *puntero1, *puntero2;


[Juanxo]

de acuerdo con todo.

Lo de los accesos (public, etc) yo suelo indentarlo, pero se cambia sin problemas.

Lo de poner espacios entre paréntesis, tambien lo hago, pero no queria parecer demasiado exagerado.

A ver si carlos se pasa y opina

[carlostex]

Estoy de acuerdo con todo lo que comentan, yo no suelo indentar private, public,etc. pero creo que se vería mejor indfentado.
Las llaves si acostumbro abrirlas y cerrarlas en nueva línea.
Cuando hay una llamada a una función o las declaración de una función es muy grande, hago un salto de linea para que todo se vea de arriba a abajo y no se tenga que ir moviendo de izquierda a derecha

[Geo]

Actualicé el primer post anotando los puntos que hemos acordado, quedando pendiente lo siguiente:

• nn o ni para sustituir la ñ.
• nombres de archivos, yo comenté que prefiero en minúsculas todo el nombre: clase.h
• sentencias para evitar doble inclusión de cabeceras (guard), yo prefiero todo en mayúsculas: #ifndef CLASE_H
• estamos de acuerdo en usar espacios y no tabuladores para indentar, pero en algún momento dos espacios me pueden parecer poco, preferiría tres o hasta cuatro.
• los modificadores public, private y protected, se indentarán, ¿pero también los miembros a los cuales modifican?

Espero sus comentarios.

[Juanxo]

* nn o ni para sustituir la ñ.

Me vale cualquiera, que carlos decida

* nombres de archivos, yo comenté que prefiero en minúsculas todo el nombre: clase.h

Me parece bien, ya que linux es sensible a mayusculas ademas.

* sentencias para evitar doble inclusión de cabeceras (guard), yo prefiero todo en mayúsculas: #ifndef CLASE_H

Todo mayuscula entonces.

* estamos de acuerdo en usar espacios y no tabuladores para indentar, pero en algún momento dos espacios me pueden parecer poco, preferiría tres o hasta cuatro.

El problema es que te quitas mucho espacio con cada indentación entonces. Prefiero 2.

* los modificadores public, private y protected, se indentarán, ¿pero también los miembros a los cuales modifican?

yo si los indento.

Un ejemplo mío para que veas como queda el tema de 2 blancos y todo indentado : http://pastebin.org/758133

Edito: ya tengo casi entero el documento de estilo, solo falta resolver estos detalles y que hugo me de permisos de escritura y lo subo. Además tengo un par de cambios hechos en el cmakelists

[carlostex]

Pues si me dan a alegir lo de la ñ me parece mas estetico usar 'ni'.
Pero por mi no hay problema entre las dos opciones.

Hacerca del cmakelists,tambien hice una modificación para que no se incluyera el archivo de prueba, lo puse en una carpeta aparte.
además le di instrucciones de instalación, pues no puedo correr la prueba a menos que libPilas.so se encuentre en /usr/lib.
ya probé ponerlo en la misma carpeta pero dice que no lo encuentra.

[Geo]

Entonces

• La ñ se sustituye por ni.
• Nombres de archivo todos en minúsculas.
• Instrucciones para evitar inclusión circular en cabeceras todas en mayúsculas del tipo CLASE_H.
• Indentación a dos espacios, se indentan los modificadores public, private y proteced de las clases, y también los miembros a los que modifican.

Muy bien, creo que ya estamos de acuerdo, conforme surjan detalles los discutimos aquí.

[Juanxo]

un par más de cuestiones a debatir:

* double? yo creo que para la precision que buscamos, con float nos sobra
* metemos todos los archivos de cabecera dentro de una misma carpeta Pilas? asi los include serán del tipo: #include <Pilas/actores.h>?
* al pasar código al español y aplicarle las reglas que tenemos, me he dado cuenta de que algunas cosas quedan algo raras: vease el caso de punto. En teoría debería ser una clase, y todos sus atributos llamarse m_*, pero al usar los atributos fuera de la clase, por ejemplo:

Código: Seleccionar todo

Punto a;
a.m_x = 10;


parece algo forzado no? como lo resolvemos

* Indices o iteradores? en teoría, los iteradores son más rapidos. En caso de iteradores, usaríamos typedef para ellos? "punto_iter" es mucho más claro para mi que "std::vector<Punto>::iterator"
* que pasa con las variables de una sola letra: vease el caso de A, B, C... en geometria.h. Usar a, b, c queda un poco feo no? tenemos 2 opciones: dejar A, B, C o cambiarlo por punto1, punto2, etc
* los condicionales, bucles y demás de una sola línea, les ponemos los corchetes?

[carlostex]

No queda muy bien eso de la m, por la razon de las letras, generalmente en las bibliotecas se maneja el atributo solo por el nombre, sobre los nombre
de las funciones de geometry.h, pues creo que asi lo ponen por que es la representacion mas facil cuando se usan matematicas, una solo leta representa un punto
dos letras seguidas representan una recta, creo que por eso esta escrito asi, ademas esas funciones estan ocultas al usuario, en lo personal que se quede como esta.

* metemos todos los archivos de cabecera dentro de una misma carpeta Pilas? asi los include serán del tipo: #include <Pilas/actores.h>?

la carpeta raiz ya se llama pilas y en esa esta include, cuando he visto fuentes siempre estan en la raiz la carpeta de cabezeras y en src las definiciones.

en los archivos de prueba esta como #include <actores.h> y en la compilacion se indica que se encuentra dentro de la carpeta usr/include/pilas.
Siempre prefiero usarlo asi, y pasarle la ubicación por el compilador, es cuestion de gusto, escribo menos en un include.

[Juanxo]

más que nada son temás pensando en el usuario, que es lo que cuenta en las librerias.

Por ejemplo: Ventana es una clase bastante común en juegos. Imaginate que en Pilas definimos el archivo ventana.h, con un guard llamado VENTANA_H y en el cpp incluye <ventana.h>
Si nosotros no tenemos nada para diferenciar el código de pilas del código del usuario, habrá problemas:

* que archivo incluye el compilador? (probablemente el primero definido en la ruta de busquedas de cabeceras)
* una de las dos clases queda sin declarar, por tener el mismo guard.

y no digas que es complicado que pase, porque en las librerías con gran cantidad de usuarios ( y la nuestra va a formar parte de ese grupo) esta clase de cosas pasan xD

Por eso he sugerido estos cambios, que estoy aplicando en la rama prueba para que veais como queda.

Lo de la carpeta, es lo que he sacado de otras bibliotecas. Si miras SFML por ejemplo, verás que dentro de include, tienen una carpeta SFML y dentro de esta todas las cabeceras, para que en el código se vea <SFML/loquesea.h>

En cuanto a lo de las m y demás opino como tú, el tema de usar "m_" es que hace más facil leer código y, aunque parezca una tontería, tu escribes m_ y el autocompletar te muestra una lista de los atributos xD. Alguna solución que apliquemos para todo, quizás la primera letra de los atributos en mayúscula (X, Atributo, Mi_casa)?

Como siempre, esto es un tema de todos, así que... lo que decida el pueblo!!

[Geo]

• Estoy de acuerdo con usar float, ya veremos el caso donde se requiera más "precisión".
• También me agrada la idea de tener todas las cabeceras dentro de una carpeta Pilas.
• Lo de la clase Punto, si estamos usando clases podemos usar funciones establecer/obtener.
• Para los vectores, soy "nuevo" con la biblioteca estándar de C++ (lo mío es C), este proyecto es parte de mi entrada "de lleno" a C++ , me siento cómodo usando índices porque siempre lo he hecho así , y aunque es hora de darle a los iteradores, creo que usar índices lo hace más sencillo para quienes empiezan. Si es con iteradores, creo que usar typedef iría bien, pero votaría por iterador_Punto.

• que pasa con las variables de una sola letra: vease el caso de A, B, C... en geometria.h. Usar a, b, c queda un poco feo no? tenemos 2 opciones: dejar A, B, C o cambiarlo por punto1, punto2, etc

  
  Voto por punto_1, punto_2 y punto_3 o punto_A, punto_B y punto_C.
• Opino que deberíamos usar corchetes para todos los bloques de código de condiciones y bucles aunque sean de una sola línea.

No queda muy bien eso de la m, por la razon de las letras, generalmente en las bibliotecas se maneja el atributo solo por el nombre, sobre los nombre
de las funciones de geometry.h, pues creo que asi lo ponen por que es la representacion mas facil cuando se usan matematicas, una solo leta representa un punto
dos letras seguidas representan una recta, creo que por eso esta escrito asi, ademas esas funciones estan ocultas al usuario, en lo personal que se quede como esta.

Pero solo para el caso de atributos que serán accedidos directamente, he visto en algunos casos que, si se va a acceder directamente a los miembros, se usa struct, mientras que en las clases solo se permite acceder a los miembros mediante funciones establecer/obtener.

[Juanxo]

secundo lo de clases para datos + operaciones y structs para solo datos (con algun operador, constructor y demas)

en cuanto a lo de los condicionales y las llaves, me baso en un estilo python para describir el codigo en estos casos:

Código: Seleccionar todo

if (x<c)
  cout<<"x es menor a c"<<endl
else
  cout << "" << endl;


[carlostex]

[list]

No queda muy bien eso de la m, por la razon de las letras, generalmente en las bibliotecas se maneja el atributo solo por el nombre, sobre los nombre
de las funciones de geometry.h, pues creo que asi lo ponen por que es la representacion mas facil cuando se usan matematicas, una solo leta representa un punto
dos letras seguidas representan una recta, creo que por eso esta escrito asi, ademas esas funciones estan ocultas al usuario, en lo personal que se quede como esta.

Pero solo para el caso de atributos que serán accedidos directamente, he visto en algunos casos que, si se va a acceder directamente a los miembros, se usa struct, mientras que en las clases solo se permite acceder a los miembros mediante funciones establecer/obtener.

tiene razón, si se usan estructuras como la de punto lo mejor es que sea punto.x, en el caso de clases no acceder a los atributos derectamente.

con respecto a lo de los corchetes acostumbro algo similar a lo de juan, no los uso, pero lo pongo en una sola linea, pero con cochetes se veria un poco feo en
varias lineas para algo sencillo como una comparación.

[Juanxo]

he estado revisando un poco el código que llevamos, y cada fichero sigue una regla en cuanto a los get/set xD:

set:
* poner_variable()
* establecer_variable()

get:
* obtener_variable()
* variable()

Mi preferencia: poner_variable y variable(). Esto ultimo queda bastante legible:

Código: Seleccionar todo

if (objeto.salta())


Otra cosa: yo soy partidario de poner el nombre de la variable en la cabecera de la función, aunque no sea estrictamente necesario, ya que si no tengo que adivinar para que sirve el parametro

[carlostex]

Si estuve cambiando los metodos get y set, por poner_variable y variable(), lo de la ubicación de las variables me parece bien