Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C++ > feedback on code design

Reply
Thread Tools

feedback on code design

 
 
nick_keighley_nospam@hotmail.com
Guest
Posts: n/a
 
      06-02-2012
On Saturday, June 2, 2012 12:14:48 PM UTC+1, Juha Nieminen wrote:
> http://www.velocityreviews.com/forums/(E-Mail Removed) wrote:


> > its also handy to label member variables in some way. I've seen
> >
> > _member, member_

>
> Personally I dislike those because they only add to the obfuscation of
> the code (especially when mixed with operators), and because the
> convention is single-purpose (ie. the same convention cannot be used
> to distinguish from class variables, local variables and variables
> inside namespaces, named or unnamed).


I tend to agree. I used to use member_ but I'm not so keen on it now. Other people find it obscure for instance.

Some people use this->member but I'm not keen on that either. I think I've seen myMember but again not one I like.
 
Reply With Quote
 
 
 
 
Ian Collins
Guest
Posts: n/a
 
      06-02-2012
On 06/ 3/12 02:18 AM, (E-Mail Removed) wrote:
> On Saturday, June 2, 2012 12:14:48 PM UTC+1, Juha Nieminen wrote:
>> (E-Mail Removed) wrote:

>
>>> its also handy to label member variables in some way. I've seen
>>>
>>> _member, member_

>>
>> Personally I dislike those because they only add to the obfuscation of
>> the code (especially when mixed with operators), and because the
>> convention is single-purpose (ie. the same convention cannot be used
>> to distinguish from class variables, local variables and variables
>> inside namespaces, named or unnamed).

>
> I tend to agree. I used to use member_ but I'm not so keen on it now. Other people find it obscure for instance.
>
> Some people use this->member but I'm not keen on that either. I think I've seen myMember but again not one I like.


I've never bothered with member variable decoration. It should be clear
from the context what is and what isn't a member. It's even easier
these days with highlighting editors.

--
Ian Collins
 
Reply With Quote
 
 
 
 
Juha Nieminen
Guest
Posts: n/a
 
      06-03-2012
Ian Collins <(E-Mail Removed)> wrote:
> I've never bothered with member variable decoration. It should be clear
> from the context what is and what isn't a member.


Maybe it should, but it that's quite an impossible demand to make in
all cases.

When you start mixing function-local variables, member variables, class
variables, compilation-unit-local variables and compile-time constants in
the same code, it quickly becomes confusing what is what, if you can't
distinguish it from their name.

The code may be very clear as you write it, and even the next day, but
return to the code some months or even years later, and you'll often notice
yourself repatedly thinking "where was this declared again? Was this a
member variable or what?" When you find yourself doing that, it's a clear
sign that you really need to start using a naming convention.

> It's even easier these days with highlighting editors.


The clarity of code should not depend on having an editor clarifying it
for you.
 
Reply With Quote
 
Ian Collins
Guest
Posts: n/a
 
      06-03-2012
On 06/ 3/12 07:12 PM, Juha Nieminen wrote:
> Ian Collins<(E-Mail Removed)> wrote:
>> I've never bothered with member variable decoration. It should be clear
>> from the context what is and what isn't a member.

>
> Maybe it should, but it that's quite an impossible demand to make in
> all cases.
>
> When you start mixing function-local variables, member variables, class
> variables, compilation-unit-local variables and compile-time constants in
> the same code, it quickly becomes confusing what is what, if you can't
> distinguish it from their name.


In my opinion if it does, you are doing something wrong.

> The code may be very clear as you write it, and even the next day, but
> return to the code some months or even years later, and you'll often notice
> yourself repatedly thinking "where was this declared again? Was this a
> member variable or what?" When you find yourself doing that, it's a clear
> sign that you really need to start using a naming convention.


Well I haven't yet after 20 odd years of C++!

--
Ian Collins
 
Reply With Quote
 
Tobias Müller
Guest
Posts: n/a
 
      06-03-2012
Juha Nieminen <(E-Mail Removed)> wrote:
> (E-Mail Removed) wrote:
>> its also handy to label member variables in some way. I've seen
>>
>> _member, member_

>
> Personally I dislike those because they only add to the obfuscation of
> the code (especially when mixed with operators), and because the
> convention is single-purpose (ie. the same convention cannot be used
> to distinguish from class variables, local variables and variables
> inside namespaces, named or unnamed).


At work we use:

m_member;
g_global; // also inside namespaces
s_static;
local;

Tobi
 
Reply With Quote
 
Bo Persson
Guest
Posts: n/a
 
      06-03-2012
Juha Nieminen skrev 2012-06-03 09:12:
> Ian Collins<(E-Mail Removed)> wrote:
>> I've never bothered with member variable decoration. It should be clear
>> from the context what is and what isn't a member.

>
> Maybe it should, but it that's quite an impossible demand to make in
> all cases.
>
> When you start mixing function-local variables, member variables, class
> variables, compilation-unit-local variables and compile-time constants in
> the same code, it quickly becomes confusing what is what, if you can't
> distinguish it from their name.


The you should consider naming the non-members specially, because THEY
are the odd case. Using members is normal, and doesn't need to be
specifically marked.


Bo Persson

 
Reply With Quote
 
Jorgen Grahn
Guest
Posts: n/a
 
      06-05-2012
On Fri, 2012-06-01, Ian Collins wrote:
> On 06/ 2/12 11:38 AM, (E-Mail Removed) wrote:
>> Thanks all, i received a good feedback and im willing to start re-
>> designing this piece of code. There is things that i didnt know and i
>> just read some of them.
>> Ill start with the design of the constructor and the initialization
>> list, here is one of my questions:
>> i read its good all variables to be in the initialization list, but,
>> for example, 'lenofFile' i have to use the function
>> 'CountLinesOfFile(...) to initialize 'lenofFile to it. Can i use
>> functions inside it and is it good? (I didnt saw any initialization
>> list do show this, but i read just few tutorials).

>
> Another guideline - avoid abbreviations - lengthOfFile is better.


It's also a name on the wrong abstraction level. It seemed at a quick
glance not to be the length of some file, but the number of words (or
lines?) in "words.txt" -- probably the length of the program's
dictionary. How about "dictionary_size" (or "dictionarySize")?

Or better yet wrap it into a class of its own so it just becomes
a size or size() member of the dictionary.

Good names help you think about the code in terms of the design you
chose. Bad names hinder that thinking.

/Jorgen

--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .
 
Reply With Quote
 
Jorgen Grahn
Guest
Posts: n/a
 
      06-05-2012
On Sun, 2012-06-03, Bo Persson wrote:
> Juha Nieminen skrev 2012-06-03 09:12:
>> Ian Collins<(E-Mail Removed)> wrote:
>>> I've never bothered with member variable decoration. It should be clear
>>> from the context what is and what isn't a member.

>>
>> Maybe it should, but it that's quite an impossible demand to make in
>> all cases.
>>
>> When you start mixing function-local variables, member variables, class
>> variables, compilation-unit-local variables and compile-time constants in
>> the same code, it quickly becomes confusing what is what, if you can't
>> distinguish it from their name.

>
> The you should consider naming the non-members specially, because THEY
> are the odd case. Using members is normal, and doesn't need to be
> specifically marked.


Members /and arguments/ are normal. That's where I see a problem at
least; I want both to have short and elegant names like "length",
"other" or whatever, and then I get into the problem Nieminen
describes.

I can live with length_ and other_, so that's what I use. But I'm
aware that there's no consensus.

/Jorgen

--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .
 
Reply With Quote
 
krastavicakrastavica@abv.bg
Guest
Posts: n/a
 
      06-05-2012
I read its bad to use conio.h, and i use getch() from that header. If
i have a new project that needs such function, is it good i to write
it on my own? What would the mass of programmers do?
 
Reply With Quote
 
Pavel
Guest
Posts: n/a
 
      06-06-2012
Bo Persson wrote:
> Juha Nieminen skrev 2012-06-03 09:12:
>> Ian Collins<(E-Mail Removed)> wrote:
>>> I've never bothered with member variable decoration. It should be clear
>>> from the context what is and what isn't a member.

>>
>> Maybe it should, but it that's quite an impossible demand to make in
>> all cases.
>>
>> When you start mixing function-local variables, member variables, class
>> variables, compilation-unit-local variables and compile-time constants in
>> the same code, it quickly becomes confusing what is what, if you can't
>> distinguish it from their name.

>
> The you should consider naming the non-members specially, because THEY are the
> odd case. Using members is normal, and doesn't need to be specifically marked.
>
>
> Bo Persson
>


Do you really feel that special marking on 'normal' names somehow denigrates
them and that on 'odd' names somehow "deservedly punishes" them?

IMHO people prefer to decorate members for practical rather than educational
reasons: no one likes extra typing so only the names whose definitions are
difficult to spot have to be marked as if saying: don't strain your eyes looking
for my definition here, I am a member, I am defined not here but in the class
definition.

I have seen lots of conventions requiring declaration of every name, from very
respectable teams and firms. Hungarian notation, aThing for parameters vs
theThing for members are the two coming to mind right off. None stuck for long.

Members' decorations (sometimes only private members') seem to be staying around
for longest; I use trailing underscore for privates, feel more or less
comfortable reading m_members, myMembers etc. but myThing occasionally has
conflicting connotations (think myTurn); thing_ usually doesn't; m_thing does
not either but it is more difficult to type and takes more space.

As for members' 'normalcy'.. how are local variables or parameter names not more
normal than members? From good software design perspective, of the three
(locals, parameters and members) a member adds more dependency to the code than
the other two so if anything, of these three the member is the oddest (and the
local var is the most normal). Although frankly I have never before thought of
variables this way ('normal' vs 'odd').

Just a thought,
-Pavel
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Re: feedback on code design Tobias Müller C++ 0 06-03-2012 08:44 AM
Feedback on my design and how to use DCI Design Pattern? josh Ruby 5 12-27-2011 10:31 AM
Feedback from feedback on MCP questions Matt Adamson Microsoft Certification 0 04-27-2009 11:13 AM
Feedback appreciated for a new design I am working on. Chaddy2222 HTML 15 06-06-2006 04:38 AM
Attn: Application Architects... Design Question... please give me your feedback... alien2_51 ASP .Net 8 07-16-2003 09:18 PM



Advertisments