• Advertisement
Sign in to follow this  

flippy!!!!!!

This topic is 4217 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Wouldn't it be nice to nice to have a framework that gives you a choice of naming conventions? I'm making one for my dev team, and I need some suggestions of formats to choose from, but none that nobody will ever use. And what would be a good short name for a namespace with stuff like types and common functions? Standard Types type_t type Type Local Variables varName VarName Global Variables g_varName gVarName Private Member Variables m_varName mVarName Static Member Variables s_varName sVarName Functions FunctionName functionName function_name Classes ClassName ClassName_t CClassName Interfaces InterfaceName InterfaceName_t IInterfaceName Structs StructName StructName_t SStructName Unions UnionName UnionName_t UUnionName Enumerators EnumName EnumName_t EEnumName Constants CONSTANT_NAME

Share this post


Link to post
Share on other sites
Advertisement
You might want to rethink your thread title.

Quote:
Original post by F-Kop
Wouldn't it be nice to nice to have a framework that gives you a choice of naming conventions?


Uh, you always have free choice what convention you use, and you always have the choice to name any given thing, as anything that is allowed by the language and doesn't conflict with something else. It just isn't necessarily a good *idea*.

So I really don't know what you mean by "framework" here. Are you trying to develop a coding standard for your project? If so, you don't really want to allow for much choice, because that rather defeats the purpose.

Share this post


Link to post
Share on other sites
I mean you use defines like NAMING_FUNCTION_CAPITAL to change the names of all the functions to the capital format etc.

Share this post


Link to post
Share on other sites
Quote:
Original post by F-Kop
I mean you use defines like NAMING_FUNCTION_CAPITAL to change the names of all the functions to the capital format etc.
Leaving aside the question of why you'd want to do something like that, how would that work exactly? Can you give an example?

And:
Quote:
You might want to rethink your thread title.

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
Everywhere ive ever seen whatever_t has been a typedef.
E.g.
struct my_type_s{ int blah; };
typedef struct my_type_s my_type_t;

I use hungarian notation mostly (iMyInteger, flFraction, cCharacter).
And use g_, m_, and s_ on the front to show scope (global,member,static).

All of my core functionality is in a namespace named "core" ;)

Share this post


Link to post
Share on other sites

// someheader.h

#ifndef _FLIPPY_SOMEHEADER_H_
#define _FLIPPY_SOMEHEADER_H_

#ifdef NAMING_FUNCTION_CAPITAL
#define FUNCTION_OPEN_FILE OpenFile
#endif

#ifdef NAMING_FUNCTION_UNDERSCORE
#define FUNCTION_OPEN_FILE open_file
#endif

TYPE_HANDLE FUNCTION_OPEN_FILE( TYPE_STR fileName, TYPE_ENUM mode );

#endif



There's the general idea.

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
Quote:
Original post by F-Kop
I mean you use defines like NAMING_FUNCTION_CAPITAL to change the names of all the functions to the capital format etc.


This seems like a hell of a lot of work for not much benifit!

Eg every time you write a function
void
#ifdef CONVENTION_1
MyFunction
#else
#ifdef CONVENTION_2
myFunction
#else
#ifdef CONVENTION_3
my_function
#endif
#endif
#endif
( void );

Share this post


Link to post
Share on other sites
Quote:
Original post by jyk
Quote:
Original post by F-Kop
I mean you use defines like NAMING_FUNCTION_CAPITAL to change the names of all the functions to the capital format etc.
Leaving aside the question of why you'd want to do something like that ...
<snip>


Actually, I'm more interested in the 'why' part... [lol]

You mean programmers have to wrap all their code in macros, so that you can "convert" it to any given naming convention by changing a macro?

If so, isn't that just a very verbose, ugly, unreadable and messy naming convention your team is forced to follow?

Quote:

Wouldn't it be nice to nice to have a framework that gives you a choice of naming conventions?

Quite simply, no. The entire point in a naming convention is that you choose one and stick with it.

Edit, after seeing the OP's latest post above:
What a horrible horrible idea.

So, to define a function, I need to write 3x extra lines in an arbitrary header somewhere, where x is the number of "supported naming conventions"? If, god forbid, another naming convention is added, I have to go through *every* single function and variable, and add an extra macro for it?

When I want to *use* a function, I have to write something like

FUNCTION_OPEN_FILE(whatever)



Let's ignore for the moment that this name is 1) longer, 2) all caps, and 3) uses underscores, all of which makes it more difficult to type than a mere "open_file", "OpenFile" or "openFile". (Personally, I'd want to avoid at least some of those. Either use underscores, or use capitalized letters, but do I really need to use both?)

But more to the point, tell me again, how is that *not* a single naming convention you're enforcing? Where exactly is the freedom in choice of naming convention? I know that I *have* to use FUNCTION_OPEN_FILE and not openFile or open_file. That sounds like a naming convention to me.
A verbose, ugly and unsafe one, but still a naming convention of sorts.

Share this post


Link to post
Share on other sites
Lol, naming conventions are for the programmers, not for the preprocessor and the compiler[smile]. They don't care if you name your function OpenFile or oP_3NF1l_E. With your method, all the programmers going to see is FUNCTION_OPEN_FILE, so where's the difference?

Share this post


Link to post
Share on other sites
Not everything is going to use that format. Just the simple things that need to work on more than one platform, like a file class or a window class.

Share this post


Link to post
Share on other sites
Quote:
Original post by F-Kop
Not everything is going to use that format. Just the simple things that need to work on more than one platform, like a file class or a window class.
What does working on more than one platform have to do with the naming convention?

Share this post


Link to post
Share on other sites
It doesn't. Those are just two different things needed.

Share this post


Link to post
Share on other sites
To be honest, as a programmer, I would rather use any naming convention you throw at me than even try to figure out what the hell is going on here. Maybe that was a little too honest.

Share this post


Link to post
Share on other sites
In all honesty, this is not a good idea at all. You're making your code more brittle for absolutely no gain: if you ever have cause to change a function, you can't use automated refactoring tools to handle it; you have to manually screw around with a bunch of function names and macro crap, and hope you don't introduce compiler errors. And that ignores the fact that macros are bloody evil to begin with. Say goodbye to namespaces and scope safety if you use this system - and those are things you do not want to say goodbye to, believe me.

Frankly the only reason I can see for such a monstrous mess would be to cater to "programmers" who are really prissy about naming conventions. If someone can't work with someone else's established conventions, they need to find another line of work. Dealing gracefully with other people's coding styles is important.

Besides, this really counteracts the entire benefit of a convention in the first place - namely, that everything following that convention is consistent. For instance, a team that uses a single convention has consistent code in all of their projects - it's familiar and reliable, even if it's not the most subjectively comfortable option for certain members of the team. As soon as you allow people to just go choosing their own style on a whim, you've shot the idea of a "convention" straight to hell.


To be totally blunt, if I worked on a team that used a system like this, I would have no problem throwing some very rude four-letter words at the team lead, walking out the door, and never looking back. This is seriously misguided and shows a real lack of understanding about the fundamental importance of the things you are trying to "improve."

Share this post


Link to post
Share on other sites
Okay, I think everybody misunderstood me. I'm making a few headers (like 3 or 4) that use this format as use a few basic classes, like CFile and CWindow. Nobody else in my team has to look at the ugly part. All they have to do is define a few things in project settings, and that's all. For example:

Defining NAMING_FUNCTION_CAPITAL and NAMING_CLASS_CCLASS in project settings:


#include <file.h>

int main( )
{
CFile file;
file.OpenFile( "MyFile.DAT", FILE_READWRITE );
//blah
file.CloseFile( );
return 0;
}



Or defining NAMING_FUNCTION_UNDERSCORE and NAMING_CLASS_CAPITAL in project settings:


#include <file.h>

int main( )
{
File file;
file.open_file( "MyFile.DAT", FILE_READWRITE );
//blah
file.close_file( );
return 0;
}



That's all the others would have to do. And not every function in a program uses the ugly format, just those few universal headers (like <file.h>).

Share this post


Link to post
Share on other sites
This is not a good idea.

First, it's a lot of work on the maintenance end that inevitably makes change harder. Want to change a function name? Now instead of finding one function name to change, you have to find multiple variations of that function to change throughout your code. Automated tools won't be able to help you.

Second, it defies the whole purpose of naming conventions. Naming conventions are there so that programmers *don't* write the way they want to necessarily - they write in a consistent way so that the code is easier to read by the entire team. Allowing the programmer to choose his naming convention by setting up some parameters is counter-intuitive.

Cheers,
--Brian

Share this post


Link to post
Share on other sites
Personally, I think you're going to have a hard time convincing anyone around here that this is a good idea (or for that matter, anything but a very bad one).

The reasons it's a bad idea are too many for one post (which should tell you something), but there are a couple of things that seem particularly obvious.

For one thing, even if it's just 'a few classes', creating and updating the macros for every function added or modified will be a maintenance nightmare, not to mention the many other implications mentioned by previous posters.

In any case, if these classes are going to be used by other members of your team, why the hell would you want to let each of them choose a different naming convention? Will all the code generated be part of the same project? If so, I can't imagine what purpose this would serve.

If however you're trying to offer modules that will be used as a part of different projects, you should just choose a single naming convention and stick with it. Most C++ programmers use the standard library, but that doesn't mean they all use lower_case_with_underscores in their own code. It's common and perfectly acceptable for separate modules to use different conventions.

Plus, if you let the user choose the naming convention, then your module doesn't even expose a consistent API from project to project, which is ridiculous.

In short, it's a bad idea. Don't do it.

Share this post


Link to post
Share on other sites
Ok, you say you're working with a team, which implies at least you and two other people. What if all three of you use different formatting definitions and try to combine the files you're working on together? I have a hard time imagining this compiling, and even if it compiles, I have a much harder time imagining it linking.

Share this post


Link to post
Share on other sites
...

...

I think what he's looking for is a tool that will reformat code according to some conventions. The preprocessor is a red herring here; what he wants is that each programmer can easily look at and edit the code as if it were in his or her preferred conventions, and then check it in with some common conventions.

There are plenty of tools out there that will at least rework the whitespace and bracing in this way (they're often called "pretty-printers"), but I don't know of tools that do anything more complex. Anyway, such a thing would need some serious testing, because of the need to transform separate pieces of code automatically and have them somehow link against each other. Not to mention that any programmer's deviations from his/her own standard would likely seriously confuse the tool :\

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
Quote:
Original post by SiCrane
Ok, you say you're working with a team, which implies at least you and two other people. What if all three of you use different formatting definitions and try to combine the files you're working on together? I have a hard time imagining this compiling, and even if it compiles, I have a much harder time imagining it linking.

#define FooBar foo_bar_canonical
#define foobar foo_bar_canonical
#define foo_bar foo_bar_canonical

Now you can use any of the above foobars as an identifier, as all of them will be converted to the same identifier. All the linker would see was definition of foo_bar_canonical and calls to foo_bar_canonical. As an added bonus, you could use all the different conventions without any extra NAMING_FUNCTION_CAPITAL-defines.

On the other hand, I have no idea why anyone would do this. Just pick one convention and move on to real problems. (<

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
OFFTOPIC:
SiCrane, since you're staff, could you add one line to the forum code that would escape anonymous posters messages so that < is converted to & l t ;? Or persuade someone who has access to the forum code to do so? It makes absolutely no sense to disable html and at the same time just make all text after < disappear.

Share this post


Link to post
Share on other sites
Quote:
Original post by Anonymous Poster
Quote:
Original post by SiCrane
Ok, you say you're working with a team, which implies at least you and two other people. What if all three of you use different formatting definitions and try to combine the files you're working on together? I have a hard time imagining this compiling, and even if it compiles, I have a much harder time imagining it linking.

#define FooBar foo_bar_canonical
#define foobar foo_bar_canonical
#define foo_bar foo_bar_canonical

Now you can use any of the above foobars as an identifier, as all of them will be converted to the same identifier. All the linker would see was definition of foo_bar_canonical and calls to foo_bar_canonical. As an added bonus, you could use all the different conventions without any extra NAMING_FUNCTION_CAPITAL-defines.

On the other hand, I have no idea why anyone would do this. Just pick one convention and move on to real problems. (<


Macros are bloody evil.

Please do not do this in your code.

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
Quote:
Original post by ApochPiQ
Macros are bloody evil.
So they say, and still C++ programmers love library libraries like boost and loki that rely heavily on macros, and many (all?) large C programs would have much more duplication and maintainance problems if it weren't for the macros. Macros are absolutely fine for things that can't be done without them.

Share this post


Link to post
Share on other sites
Quote:
Original post by Anonymous Poster
Quote:
Original post by ApochPiQ
Macros are bloody evil.
many (all?) large C programs would have much more duplication and maintainance problems if it weren't for the macros.


C != C++. Note that all four of those links came from the C++ Faq Lite.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement