Overview
Examples
Screenshots
Comparisons
Applications
Download
Documentation
Tutorials
Bazaar
Status & Roadmap
FAQ
Authors & License
Forums
Funding Ultimate++
Search on this site
Search in forums












SourceForge.net Logo
Home » U++ Library support » U++ Library : Other (not classified elsewhere) » User lists of "bad" naming of classes, functions etc in U++...
User lists of "bad" naming of classes, functions etc in U++... [message #1574] Thu, 09 March 2006 03:50 Go to next message
fudadmin is currently offline  fudadmin
Messages: 1321
Registered: November 2005
Location: Kaunas, Lithuania
Ultimate Contributor
Administrator
User lists of "bad" naming of classes, functions etc in U++...

If you are not happy with naming of classes, functions, variables etc. in U++, start your own reply and edit it constatly.
1 reply per user!!! No discussions!!! Discuss them separately (outside this)!! Only give a suggestion(s) and reason(s)

[Updated on: Tue, 17 November 2009 10:27] by Moderator

Report message to a moderator

Arijus' list of "renames" [message #1575 is a reply to message #1574] Thu, 09 March 2006 03:51 Go to previous messageGo to next message
fudadmin is currently offline  fudadmin
Messages: 1321
Registered: November 2005
Location: Kaunas, Lithuania
Ultimate Contributor
Administrator
1. Display class -> Displaytor (because it's a functor and not physical display)
2. EditField and LineEdit -> shouldn't be both Edit+Something or Something+Edit?
3. Shouldn't it be a pattern: all classes start with a "thing" and not "action"? like DateField, TextField etc...?
4. sometimes Get() and sometimes GetData() -> shouldn't it be (always) Get+Something more precisely or all classes have only one "main" Get or GetData?
5. SetFont() -> I'd expect to find it in all Text controls...
6. ShowTabs in LineEdit is confusing esp. when searching with TabCtrl -> should be ShowTabChars...

[Updated on: Thu, 30 March 2006 12:08]

Report message to a moderator

Re: User lists of "bad" naming of classes, functions etc in U++... [message #7477 is a reply to message #1574] Sun, 31 December 2006 04:20 Go to previous messageGo to next message
Coder is currently offline  Coder
Messages: 3
Registered: December 2006
Junior Member
From my experience working on large programming teams, having the variable scope prefixed to variables name helps make code a lot easier to read, and allows for different scopes to use the same name variable (less variable name conflicts). It helps in readability in that in looking at a piece of code, you don't have to search for the declaration of a variable in order to determine if it is a local, member, inherited member, static or global variable, and also in trying to understand how a member is used and doing a search you don't accidentally come across a local variable named the same as a member. The ones used in Hungarian Notation are s_* (s_Var) for static variables, g_* (g_Var) for global variables, m_* (m_Var) for class/struct member variables. Since member variables are most often used, sometimes I've seen code where they don't use an underscore, m* (mVar), or they only use underscore _* (_Var). I've also seen some use a_* for arguement variables, this is also useful in reducing variable name conflicts. Also, in general classes/structs with no or few functions and mostly public data, don't have to use scope prefixes.

I think type prefixes are less important, but can reduce variable name conflicts in some cases, or (if there is no quick help) it allows others to quickly understand what a variable is with out looking up it's declaration.

--------

To Werner,
That is useful but not in a way that addresses much of the above. It still requires looking things up, and the information it returns has type and global, instance, class symbol. It doesn't appear to work for local variables. Plus it adds additional information that is kind of confusing about its locality.

There are similar things you can have in Visual Studio, one of them you hover the mouse and it tells you the type and what it is a member variable (if it is a member at all).

But really nothing beats being able to look at variables and know their scope, with out having to look it up. It may also be useful if there were some how a way to color code variables based upon their scope. But you still run into one of the other issues, the variable name conflicts.

[Updated on: Wed, 10 January 2007 20:23]

Report message to a moderator

Re: User lists of "bad" naming of classes, functions etc in U++... [message #7491 is a reply to message #7477] Mon, 01 January 2007 18:44 Go to previous messageGo to next message
Werner is currently offline  Werner
Messages: 234
Registered: May 2006
Location: Cologne / Germany
Experienced Member
You might want to have a look at the "Assist++" section of the Ultimate++ manual, especially the paragraph "Graphical symbols used by Assist++".

Werner
Re: User lists of "bad" naming of classes, functions etc in U++... [message #11575 is a reply to message #1574] Tue, 18 September 2007 02:43 Go to previous messageGo to next message
tvanriper is currently offline  tvanriper
Messages: 85
Registered: September 2007
Location: Germantown, MD, USA
Member
I'm referring to 2007.1.. I haven't been working with the dev builds, so maybe this is already addressed.

GridCtrl and ArrayCtrl are similar controls in that they provide a spreadsheet-like view into rows and columns of data.

Consequently, I think there's an advantage in making sure their functions are named similarly, as someone may elect to switch between them (in fact, I switched from an ArrayCtrl to a GridCtrl recently in my work).

GridCtrl::IsSelected and ArrayCtrl::IsSelect are just close enough to being the same that it seems a shame not to make the names match.
Re: User lists of "bad" naming of classes, functions etc in U++... [message #11583 is a reply to message #11575] Tue, 18 September 2007 08:44 Go to previous messageGo to next message
unodgs is currently offline  unodgs
Messages: 1366
Registered: November 2005
Location: Poland
Ultimate Contributor

tvanriper wrote on Mon, 17 September 2007 20:43


GridCtrl and ArrayCtrl are similar controls in that they provide a spreadsheet-like view into rows and columns of data.
Consequently, I think there's an advantage in making sure their functions are named similarly, as someone may elect to switch between them (in fact, I switched from an ArrayCtrl to a GridCtrl recently in my work).
GridCtrl::IsSelected and ArrayCtrl::IsSelect are just close enough to being the same that it seems a shame not to make the names match.

IsSelect is not grammaticaly correct Wink I was trying to follow ArrayCtrl interface, but there is too much differences now and there will be more in the future (new outstanding gridctrl is comming Wink ) But in cases like IsSelect I agree that they could be the same. The only problem is : what to choose?

[Updated on: Tue, 18 September 2007 08:45]

Report message to a moderator

Re: User lists of "bad" naming of classes, functions etc in U++... [message #11586 is a reply to message #11583] Tue, 18 September 2007 14:38 Go to previous messageGo to next message
mirek is currently offline  mirek
Messages: 13975
Registered: November 2005
Ultimate Member
Afaik, there is no IsSelect in ArrayCtrl...

There is IsSelection and IsSelected.
Re: User lists of "bad" naming of classes, functions etc in U++... [message #11650 is a reply to message #1574] Thu, 20 September 2007 15:16 Go to previous messageGo to next message
mr_ped is currently offline  mr_ped
Messages: 825
Registered: November 2005
Location: Czech Republic - Praha
Experienced Contributor
Util.h:

class Exc : public String {
public:
	Exc(); // throw according to GetLastError()
	Exc(const String& desc) : String(desc) {}

//	void Show() const;
};

class AbortExc : public Exc {
public:
	AbortExc();
};


There's no word "Exception" anywhere, not even in comments.
Makes it hard to find trough text search if you are just checking around if the UPP has some predefined Exception class.
I don't ask as much for renaming the class, as for the comment added.
Re: User lists of "bad" naming of classes, functions etc in U++... [message #11686 is a reply to message #11650] Fri, 21 September 2007 14:56 Go to previous messageGo to next message
mirek is currently offline  mirek
Messages: 13975
Registered: November 2005
Ultimate Member
OK, now there is Smile

Mirek
Re: User lists of "bad" naming of classes, functions etc in U++... [message #14697 is a reply to message #1574] Sun, 09 March 2008 14:19 Go to previous messageGo to next message
darkwyrm is currently offline  darkwyrm
Messages: 3
Registered: February 2008
Junior Member
1. Option -> Checkbox
2. OptionTree -> CheckboxTree
3. Switch -> RadioButton

It's not a matter of opinion on this one, but of matching a cross-API de facto standard (like analog clocks Smile.

gtk+: checkbutton / radiobutton
win32: checkbox / radiobutton
beos: BCheckBox / BRadioButton
wxwidgets: wxCheckBox / wxRadioButton
Qt: QCheckBox / QRadioButton

I would not have found them had I been actually looking for them.

[Updated on: Sun, 09 March 2008 19:22]

Report message to a moderator

Re: User lists of "bad" naming of classes, functions etc in U++... [message #14698 is a reply to message #14697] Sun, 09 March 2008 18:22 Go to previous messageGo to next message
unodgs is currently offline  unodgs
Messages: 1366
Registered: November 2005
Location: Poland
Ultimate Contributor

darkwyrm wrote on Sun, 09 March 2008 09:19

1. Option -> Checkbox
2. OptionTree -> CheckboxTree
3. Switch -> RadioButton


No no no Smile I must say option means more to me than checkbox. The same with Switch. I know this is very subjective, but I vote for no changes here.

[Updated on: Sun, 09 March 2008 18:23]

Report message to a moderator

Re: User lists of "bad" naming of classes, functions etc in U++... [message #23716 is a reply to message #1574] Tue, 17 November 2009 10:00 Go to previous messageGo to next message
ag_newb is currently offline  ag_newb
Messages: 1
Registered: November 2009
Junior Member
Boost C++ naming system should be adopted.
reason: delimiting by underscore is safer than capitalization, IMHO.
Re: User lists of "bad" naming of classes, functions etc in U++... [message #23721 is a reply to message #23716] Tue, 17 November 2009 15:41 Go to previous messageGo to next message
andrei_natanael is currently offline  andrei_natanael
Messages: 262
Registered: January 2009
Experienced Member
ag_newb wrote on Tue, 17 November 2009 11:00

Boost C++ naming system should be adopted.
reason: delimiting by underscore is safer than capitalization, IMHO.

Have you an argument for this?
void DoSomething(const String& paramOne) {}

void do_something(const string& param_one) {}


IMO, using second version(with underscores) takes more time to write because when you write _ you have to press Shift+_ and that means 2 key press more than camel case naming.

Using camelCase notation you identify clearly which is a method of a class or a public variable. For example, you could notate all member function using notation LikeThis and variables using notation likeThis. If a variable is an instance of a class which redefine operator () is clear that accessing it like instance.variableName() means calling operator () from variableName and not calling function variableName().
class X
{
  class Y { public: void operator() {} };
public:
  Y variableName;
  void CallMe() {}
};

class x
{
  class y { public: void operator() {} };
public:
  y variable_name;
  void call_me() {}
};

int main()
{
  X camelCaseNotation;
  x underscore_notation;
  camelCaseNotation.variableName(); // means calling operator () from variableName
  camelCaseNotation.CallMe(); // means calling a member function

  underscore_notation.variable_name(); // looks like we are calling a member function
  underscore_notation.call_me(); // ok, we are calling a member function
  return 0;
}

IMO camelCase make you easier understanding the context.
Re: User lists of "bad" naming of classes, functions etc in U++... [message #23723 is a reply to message #23721] Tue, 17 November 2009 16:48 Go to previous messageGo to next message
koldo is currently offline  koldo
Messages: 3355
Registered: August 2008
Senior Veteran
I support andrei_natanael.

Best regards
Koldo


Best regards
IƱaki
Re: User lists of "bad" naming of classes, functions etc in U++... [message #23725 is a reply to message #23721] Wed, 18 November 2009 08:41 Go to previous messageGo to next message
mirek is currently offline  mirek
Messages: 13975
Registered: November 2005
Ultimate Member
andrei_natanael wrote on Tue, 17 November 2009 09:41

ag_newb wrote on Tue, 17 November 2009 11:00

Boost C++ naming system should be adopted.
reason: delimiting by underscore is safer than capitalization, IMHO.

Have you an argument for this?
void DoSomething(const String& paramOne) {}

void do_something(const string& param_one) {}


IMO, using second version(with underscores) takes more time to write because when you write _ you have to press Shift+_ and that means 2 key press more than camel case naming.



I would not bother 2 more key presses.

But what I do not like about undescores is that it makes the line wider - in quite a lot more cases, it will break statements into more lines. That I believe reduces code readability.

However, I have removed 'sticky' flag of this post. I guess at this stage, any massive renaming is impossible. And as it seems the topic is quite subjective, current naming might not be the best, but is definitely usable...

Mirek
Re: User lists of "bad" naming of classes, functions etc in U++... [message #23732 is a reply to message #23725] Wed, 18 November 2009 12:05 Go to previous messageGo to next message
andrei_natanael is currently offline  andrei_natanael
Messages: 262
Registered: January 2009
Experienced Member
luzr wrote on Wed, 18 November 2009 09:41


I would not bother 2 more key presses.


Then why we have << operator in TopWindow, THISBACK macro, etc.? Razz
Regarding this, i like more to write win.Add(widget) than win << widget, and callback(this, &Window::Something) instead of THISBACK(Something) even if you type more because even if someone is a newcomer to U++ he figure out that win.Add(widget) will add the widget to win window.
Now that i'm talking about that i may summarize the things which i don't like at U++.
We say about U++ that it's a modern framework using advanced C++, though i don't see many design patterns used here, the platform abstraction is not so well implemented(IMO Chameleon it's not so good, dirty code inside Rolling Eyes ) and there are a lot of macros (some have a good reason why them exists).
GUI_APP_MAIN // U++ initialization is hidden by this macro
{
  TopWindow w;
  w.Run();
}

It could be written:
int main(int argc, char *argv[]) // it is possible to write main() for GUI applications in Windows too
{
  Application app(argc, argv); U++ initialization is hidden in Application class
  TopWindow w;
  return app.Run(w);
}

Don't get me wrong, i like U++ that's why i'm using it but here are some bits that i don't agree with because they could be better.

Back to naming conventions if you're using STL with camelCase you may make the difference between you functions, algorithms, etc. and those provided by STL and say: Hey this Sort is provided by U++ not STL (because different naming conventions). However Mirek if you are supposed to re-create U++ which naming convention would you use?
Re: User lists of "bad" naming of classes, functions etc in U++... [message #23736 is a reply to message #23732] Wed, 18 November 2009 12:48 Go to previous messageGo to next message
mirek is currently offline  mirek
Messages: 13975
Registered: November 2005
Ultimate Member
Quote:


GUI_APP_MAIN // U++ initialization is hidden by this macro



Quote:


int main(int argc, char *argv[]) // it is possible to write



Possible, but not really standard. And GUI_APP_MAIN does more than just Application app(argc, argv).

I am not really happy abou these macros too, but they really DO encapsulate a lot of platform specific stuff.

Quote:


Back to naming conventions if you're using STL with camelCase you may make the difference between you functions, algorithms, etc. and those provided by STL and say: Hey this Sort is provided by U++ not STL (because different naming conventions). However Mirek if you are supposed to re-create U++ which naming convention would you use?


Next time, I might consider camelCase, but I would most likely used InitCaps anyway....

Mirek
Re: User lists of "bad" naming of classes, functions etc in U++... [message #23739 is a reply to message #23736] Wed, 18 November 2009 13:56 Go to previous message
tojocky is currently offline  tojocky
Messages: 607
Registered: April 2008
Location: UK
Contributor

Interesting debate!

I thing that must to be a rules standard.

For me, I like macros!

With respect, Ion Lupascu (tojocky)
Previous Topic: BUG: Key states incorrectly cleared on Ubuntu
Next Topic: Painter DrawLine proposal
Goto Forum:
  


Current Time: Thu Mar 28 20:54:55 CET 2024

Total time taken to generate the page: 0.01247 seconds