2009-04-21 6 views
5

Soy un programador de C++ bastante nuevo y me gustaría escuchar los argumentos a favor y en contra de los parámetros de nomenclatura dentro de la declaración de clase.C++ Style Convention: nombres de parámetros dentro de la declaración de clase


He aquí un ejemplo:

Student.h

#ifndef STUDENT_H_ 
#define STUDENT_H_ 

#include <string> 

using namespace std; 

class Student 
{ 
    private: 
     string name; 
     unsigned int age; 
     float height, GPA; 

    public: 
     Student(string, unsigned int, float, float); 

     void setAge(unsigned int); 
}; 

#endif /*STUDENT_H_*/ 

vs

#ifndef STUDENT_H_ 
#define STUDENT_H_ 

#include <string> 

class Student 
{ 
    private: 
     string name; 
     unsigned int age; 
     float height, GPA; 

    public: 
     Student(string name, unsigned int age, float height, float GPA); 

     void setAge(unsigned int age); 
}; 

#endif /*STUDENT_H_*/ 

Student.cpp

#include "Student.h" 

Student::Student( string name, 
      unsigned int age, 
      float height, 
      float GPA) : 

      name(name), 
      age(age), 
      height(height), 
      GPA(GPA) {} 

void Student::setAge(unsigned int age) { this -> age = age; } 

No puedo decidir. Por un lado, creo que es redundante nombrar las variables tanto en la declaración (.h) como en la definición (.cpp). Especialmente porque tiene que preocuparse de actualizar los nombres en ambos lugares para que coincidan. Por otro lado, sin nombres, a menudo puede ser confuso determinar a qué variables corresponden los parámetros simplemente mirando la declaración.

Entonces, ¿qué piensas?

+0

simplemente use 'int' y' double', no 'unsigned int' y' float'. En el caso de 'unsigned int', quizás intente documentar una restricción de valor, pero en lugar de aplicar C++, proporciona una gran cantidad de trampas, es decir, sin ganancia, pero con mucho dolor innecesario. Por lo general, solo use tipos sin signo cuando trabaje con el nivel de bit, o cuando lo fuercen las funciones de la biblioteca. En el caso de 'float' quizás esté intentando guardar memoria. Eso está mal orientado a menos que tenga miles de millones de estudiantes. :-) Saludos y hth. –

+0

@Alf P. Steinbach: ¿Qué trampas? ¿Por qué doble cuando el flotador es suficiente? Elaborar. –

Respuesta

19

Es mucho mejor usar los nombres de los parámetros en la declaración, y usar buenos nombres de parámetros. De esta forma, sirven como documentación de funciones. De lo contrario, tendrá que escribir comentarios adicionales en su encabezado, y siempre es mejor usar buenos nombres de parámetros/variables que usar comentarios.

Excepción: cuando una función debe tener una firma determinada por motivos externos, pero los parámetros no se utilizan realmente. En este caso, tampoco debe nombrarlos en la implementación.

+3

Excepción: cuando los parámetros son obvios o los tipos son autodocumentados, por ejemplo, 'Point3D (T, T, T)' y 'Pair (Key, Value)' son abundantemente claros. –

4

Pon los nombres en ambos lugares, la claridad es la recompensa que obtienes por la tarea de mantener las firmas en dos lugares.

1

Incluso si es redundante, me parece que es mejor tener nombres de parámetros en ambos lugares. Esto se debe normalmente a que cambiar el nombre de un parámetro a menudo tiene consecuencias semánticas. Perderlo en el encabezado ayuda a arruinar la documentación (que es donde tiendo a poner la mayoría de los comentarios, es decir, las especificaciones API) y perderlo en la implementación me ayuda a olvidar por qué ese parámetro en particular tiene un nombre tan extraño.

La única vez que renuncio a un nombre de parámetro es cuando tengo que implementar una devolución de llamada de biblioteca de un tercero y no estoy usando uno de los parámetros. Incluso entonces lo haría:

my_callback(int idx, Context* /*ctx*/) { ... 

para que yo sepa bien la firma.

-1

Sí, no es necesario nombrar los parámetros en el archivo .h. Se supone que un archivo de encabezado representa una interfaz, por lo que no necesita tener detalles innecesarios.

HTH

+0

Parece que el consenso sobre la pregunta que enlazó es no usar un guión bajo para las variables miembro, que yo no. Si bien algunas personas pueden encontrarlo molestamente prolijo, tiendo a usar la palabra clave "this" como en el ejemplo que publiqué anteriormente. No estoy seguro de lo que intentabas ilustrar con ese enlace. – Scott

+0

Verdadero - y "flotar, flotar" NO es la interfaz. "altura flotante, GPA flotante" es la interfaz real. – MSalters

+0

Disculpa, he eliminado el enlace de subrayado.Fue pensado para otra persona :-) @MSalters: acepto que los nombres de los parámetros agreguen el significado que proporciona una interfaz, pero en mi opinión depender de esa no es la manera ideal. ¿Qué sucede si alguien los renombra de manera diferente en el encabezado y luego en el impl. archivo. Será más confuso. Desde una perspectiva de mantenimiento, creo que es útil dejar los nombres fuera del encabezado. – Abhay

3

Intellisense/autocompletar/lo que sea similar se encuentra en entornos de desarrollo por lo general sólo ve la declaración y sólo se mostrará como autocompletar. Entonces, si no declaras los nombres en la declaración, los usuarios no los verán en autocompletar a menos que vayan y lean la fuente.Eso es quizás tolerable, pero no muy conveniente.

+0

Oh, por supuesto, pongo los nombres en la declaración. Tal vez mi publicación no fue lo suficientemente clara, pero estaba tratando de obtener razones a favor o en contra * adicionalmente * poner nombres en el encabezado. – Scott

+0

¡Uy! Rasca eso. Leí "definición" en lugar de "declaración" en su respuesta. Gracias por la información. – Scott

0

Si alguna vez libera su código como librray, con el archivo .h asociado, sus usuarios nunca verán la definición, solo la declaración, agregando una carga adicional de documentación sobre usted.

0

Por un lado, siento que es redundante para nombrar las variables en tanto en la declaración (.h) y el definición (.cpp). Especialmente desde tiene que preocuparse de actualizar los nombres en ambos lugares para que coincidan con .

No necesita los nombres para que coincida con literalmente. El archivo de encabezado, que especifica la interfaz, funciona un poco como un contrato imperfecto (imperfecto porque no contiene condiciones previas y posteriores, a menos que se anoten en los comentarios) y una "guía de llamadas". La persona que llama de la clase querrá saber qué parámetros son, en el 99% de los casos. Al menos para que sepa lo que está pasando. Por lo tanto, debe elegir un nombre de parámetro que tenga sentido para la persona que llama. Esto no necesita ser idéntico al nombre en el cpp. Sin embargo, esto no importa mucho, porque estoy acostumbrado a copiar/pasar las firmas de funciones del .h al .cpp en primer lugar. Para mí, la programación en C++ implica esta parte manual.

Por otro lado, sin nombres, que puede a menudo ser confuso para determinar qué variables los parámetros corresponden con sólo mirar la declaración .

Esa es la buena mano.

0

Supongo que depende de qué tan descriptivos sean sus tipos de variables. Si su firma del método contiene los tipos utilizados para fines múltiples, entonces es útil:

double calculateTax(int, string); 

si los tipos son descriptivos, a continuación, incluyendo los nombres es redundante.

Money calculateTax(Order, State); 

Preferiría no mantener los nombres en dos archivos.

Cuestiones relacionadas