How do you guys name the parameters of constructing methods?

Discussion in 'C++' started by xz, Dec 18, 2007.

  1. xz

    xz Guest

    For example, I have a Class Date with internal variable year, month
    and day.
    In Java I would write:

    class Date{
    int year;
    int month;
    int day;
    Date(int year, int month, int day) {
    this.year = year;
    this.month = month;
    this.day;
    }
    }

    That is, simply name every parameter as what it is and use this.*
    within the method body to differentiate the class variables and the
    parameters.

    However, in C++ it seems I cannot do this. In this particular
    example, probably I can write:

    Date::Date(int y, int m, int d): year(y), month(m), day(d) {
    }

    However, the letters "y", "m" or "d" are not that informative. Thus I
    don't really like this naming style.
    Is there a better way to do this?
    What would you guys use to replace "y", "m" and "d" in this case?
     
    xz, Dec 18, 2007
    #1
    1. Advertisements

  2. xz

    Salt_Peter Guest

    There is no right way, its a question of style.

    class Date
    {
    int m_year; // members
    int m_month;
    int m_day;
    public:
    Date() : m_year(2000), m_month(1), m_day(1)
    { }
    Date(int year, int month, int day): m_year(year),
    m_month(month),
    m_day(day)
    { }
    };

    or use year_ and year but prefereably not _year
     
    Salt_Peter, Dec 18, 2007
    #2
    1. Advertisements

  3. In C++ you'd do

    class Date {
    int year;
    int month;
    int day;
    public: // you probably meant that
    Date(int year, int month, int day)
    : year(year), month(month), day(day) {}
    };
    Same with C++. You need 'this->' to differenciate.
    Is that so? Post the complete compilable code and the error message
    you get.
    See above.
    I've seen (and used) the convention to follow the argument names with
    an underscore:

    Date(int year_, int month_, int day_)
    : year(year_), month(month_), day(day_) {}

    Or (I know some cringe at a mere sight of it) just name your members
    with a prefix (like 'm_'), arguments and local variables - without
    prefices. It's easy to discern what is a member and what isn't.


    V
     
    Victor Bazarov, Dec 18, 2007
    #3
  4. xz

    xz Guest

    Now I know what was wrong. "this" in C++ is pointer instead of
    reference so that you have to use "this->" instead of "this."
    thanks!
     
    xz, Dec 18, 2007
    #4
  5. xz

    Rolf Magnus Guest

    And I've seen (and used) the convention to do exactly that with the member
    variables instead of the parameters.
    Another possibility is to name the parameters different in the header than
    in the implementation, i.e.:

    // header
    class Date
    {
    public:
    Date(int year, int month, int day);
    };

    // implementation
    Date::Date(int y, int m, int d)
    : year(y), month(m), day(d)
    {
    }
     
    Rolf Magnus, Dec 18, 2007
    #5
  6. xz

    Jim Langston Guest

    You can do it that way if you use an initialization list.

    class Date
    {
    public:
    Date( int year, int month, int day ): year(year), month(month), day(day)
    {}
    private:
    int year;
    int month;
    int day;
    };

    Personally, however, I would do it this way:

    class Date
    {
    public:
    Date( int Year, int Month, int Day ): Year_( Year ), Month_( Month ),
    Day_( Day ) {}
    int Year() { return Year_; }
    void Year( int Year ) { Year_ = Year; }
    int Month() { return Month_; }
    void Month( int Month ) { Month_ = Month; }
    int Day() { return Day_; }
    void Day( int Day ) { Day_ = Day; }
    };

    Some poople don't like the use of any time of prefix or suffix but
    differentiate with use of capital letters or not. Personally, I think the
    use of a suffix of _ is more clear.

    [SNIP]
     
    Jim Langston, Dec 19, 2007
    #6
  7. xz

    Kira Yamato Guest

    I see no problem with your parameter-naming style at all. In fact,
    that is what I would do too.

    There is no superfluous and ugly prefixes or subfixes. Your only
    complain is the single-letter variable names. However, for local
    variables in a short function, short variable names are preferred.
    Afterall, how many local variables or how confusing can 50 lines of
    code be?
     
    Kira Yamato, Dec 19, 2007
    #7
  8. xz

    Andre Kostur Guest

    I've been using a 'p_' prefix to the parameters:

    Date(int p_year, int p_month, int p_day)
    : year(p_year), month(p_month), day(p_day) {}

    Gives you a nice reminder that you're dealing with the parameter, and not
    the member variable. Although I only add the p_ when there is a name
    "conflict".
     
    Andre Kostur, Dec 19, 2007
    #8
  9. Or misguides an uninvolved guy looking at your code (ie, me) to think
    that it represents a pointer :) I think "m_" is more widely
    recognized.
     
    Ioannis Gyftos, Dec 19, 2007
    #9
  10. xz

    Kira Yamato Guest

    Or maybe we should just do away with prefixes and suffixes, and just
    use italic or bold or even colors.

    Oh wait, I think some IDE's may actually do this already. :)
     
    Kira Yamato, Dec 19, 2007
    #10
  11. xz

    James Kanze Guest

    Not much better. Names should be meaningful. What does _ mean?
    I don't like that either.

    I don't think that there is one univeral convention that covers
    everything. If the class is really just a structure with
    constructors (but public data members), I'll use the same name
    for the parameters and the members. If the class is mutable, it
    would make sense (both in C++ and in Java) to name the
    parameters "initialYear", etc. If the data members are private,
    prefixing them with my works well for me. (Again, this
    convention applies to Java as well as to C++.) Other conditions
    are also possible. Just don't start or end names with an
    underscore---it's too ugly.
     
    James Kanze, Dec 19, 2007
    #11
  12. xz a écrit :
    You could use type naming:

    struct Day
    {
    int value;

    Day(int day):value(day){}
    };

    struct Month
    {
    int value;

    Month(int month):value(month){}
    };


    struct Year
    {
    int value;

    Year(int year):value(year){}
    };


    class Date{
    int year;
    int month;
    int day;

    public:
    Date(const Year& y, const Month& m, const Day& d):
    year(y.value),month(m.value),day(d.value){}
    };

    And then
    Date today(Year(2007),Month(12),Day(19));
    or
    Date tomorrow(2007,12,20);

    That way, the declaration is meaningful. If you want to add security,
    you can still make the constructor explicit in order to force the form
    used for 'today'.

    Michael
     
    Michael DOUBEZ, Dec 19, 2007
    #12
  13. xz

    Kira Yamato Guest

    Good idea.

    You can even add more constructors for Month like
    explicity Month(const string &m);
    so that you can declare
    Date today(Year(2007), Month("December"), Day(19));
    too.

    So, essentially, you let the *type* say what the variable is so that
    the name of the variable becomes less of a matter. This works
    particularly well for local variables in small functions.
     
    Kira Yamato, Dec 19, 2007
    #13
  14. Kira Yamato a écrit :

    This work very well if you want to ensure you parameters are given in
    the right order for some tricky functions.

    Relevant example is with using memcpy(). Instead of defining:
    void *memcpy (void *dest, const void *src, size_t n);

    You define:
    struct DestPtr
    {
    void* value;
    explicit DestPtr(void* v):value(v){}
    };
    struct SrcPtr
    {
    void* value;
    explicit SrcPtr(void* v):value(v){}
    };

    and then
    inline
    void* memcpy_secure(const DestPtr& dest, const SrcPtr& src,size_t n)
    {
    return memcpy(dest.value,src.value,n);
    }

    So that if you mix parameters (to take an example from the air, you
    change from a call to bcopy to a call to memcpy):

    memcpy_secure(SrcPtr(foo),DestPtr(bar),42);

    You get an error instead of spending hours trying to locate a stupid
    hard-to-find bug that may corrupt your stack among other things.

    Michael
     
    Michael DOUBEZ, Dec 19, 2007
    #14
  15. xz

    Default User Guest


    My company's model coding standard requires that:

    Rule 45a - A class data member shall have a trailing underscore.
    Placing an underscore at the end of a class attribute allows you to
    easily determine where all the class attributes are being used in the
    code. In the example below, including the underscore makes it easier
    to understand the code in the contructor's initializer list.

    [example skipped]






    Brian
     
    Default User, Dec 19, 2007
    #15
  16. xz

    peter koch Guest

    I like that rule and use it myself. As does James Kanze, I believe
    that the trailing underscore is just to ugly.

    /Peter
     
    peter koch, Dec 19, 2007
    #16
  17. xz

    Default User Guest

    Matter of opnion. Personally, I don't mind the trailing underscore, but
    that leading p_ is horrible. In fact, anything attached to the front of
    a variable is, to my mind, a means of reducing readability.





    Brian
     
    Default User, Dec 19, 2007
    #17
  18. xz

    James Kanze Guest

    It's not just a problem of esthetics. An underscore is not
    particularly visible, and a trailing (or leading) underscore is
    even less visible. If the name is the last symbol on the line,
    it can easily be overlooked.

    There's also the problem of how you pronounce it.
    It depends on the rest of the convention. To start with, of
    course, standard English usage is to put the modifier before
    what it modifies, so you will almost always have something
    "attached" to the front of a variable name (since variable names
    should be qualified nouns). Something like "currentState",
    rather than just "State" (which would be the name of the type).
    I don't think that this is what you're talking about, however,
    but used rigorously, it probably would obliviate the need for
    any other indicators. In practice, I've found that some sort of
    convention helps for member variables (and only member
    variables). I use "my" (and "our" for static members) because
    they *are* qualifiers. But if a client prefers m_ (and s_), it
    doesn't bother me too much---since I just treat it as a special
    spelling of "my" and "our", and pronounce it like that in my
    head:).
     
    James Kanze, Dec 20, 2007
    #18
  19. xz

    Default User Guest

    That's your opinion. I don't have that problem.
    When it's necessary to disambiguate a variable in conversation, we find
    a way. It rarely comes up.




    Brian
     
    Default User, Dec 20, 2007
    #19
  20. xz

    James Kanze Guest

    It's not really just an opinion; it's base on sound typological
    principles. How serious the problem is will depend on the fonts
    you are using. If the font displays the underscore three points
    thick, for example, it's certainly not going to be overlooked.
    Most fonts, at least most fonts I use, display it as a very,
    very fine line well below the baseline. Where it isn't readily
    apparent. (At least one font I've used put it so far below the
    baseline that it merged with the top of capital letters on the
    line below.) This is consistent with it's usual uses:
    underlining text, or replacing a space in a context where a
    space would be illegal.
    One can always find a way.
    You don't discuss your code enough with collegues:).

    Ideally, you shoud be able to discuss code over the telephone
    with no need of meta information, just by applying the coding
    guidelines to the pronounced symbol names. It is a ideal that
    is, admittedly, rarely fully met---in particular, typenames and
    variable names often only differ by the capitalization of their
    first letter. (This violates another rule: that the edit
    distance between any two symbols should be at least 2, so that a
    single typo won't result in one symbol being interpreted as
    another. This is perhaps less critical when one of the symbols
    is a type name, and the other not, because such
    misinterpretations will almost certainly cause a compiler error
    anyway.)
     
    James Kanze, Dec 21, 2007
    #20
    1. Advertisements

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.