|
|
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  |
 |
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   |
 |
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   |
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 #14697 is a reply to message #1574] |
Sun, 09 March 2008 14:19   |
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 .
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 #23725 is a reply to message #23721] |
Wed, 18 November 2009 08:41   |
 |
mirek
Messages: 14255 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   |
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.? 
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 ) 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   |
 |
mirek
Messages: 14255 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
|
|
|
|
Goto Forum:
Current Time: Sat Apr 26 21:53:47 CEST 2025
Total time taken to generate the page: 0.03481 seconds
|
|
|