Naming conventions

[Miguel Guedes]

Hello,

Does anyone have a link to the C++ Standard Library naming conventions
that they could share? I have found a few links to pages on C++ naming
conventions but am unsure as to what standard they follow.

Best Regards,

-- Miguel Guedes

- X marks the spot for spammers. If you wish to get in touch with me by
email, remove the X from my address. -

 

[Victor Bazarov]

Does anyone have a link to the C++ Standard Library naming conventions
that they could share? I have found a few links to pages on C++ naming
conventions but am unsure as to what standard they follow.

What do you need it for? If you want to know what's allowed to be used,
get a copy of the Standard, and see what's not allowed; everything else
would be OK. All names visible to the programmer are defined in the
Standard already. You're not supposed to add any. If you need to know
what functions/objects/types exist, get yourself a reference manual.

V

 

[Miguel Guedes]

Miguel Guedes wrote:
What do you need it for? If you want to know what's allowed to be used,
get a copy of the Standard, and see what's not allowed; everything else
would be OK. All names visible to the programmer are defined in the
Standard already. You're not supposed to add any. If you need to know
what functions/objects/types exist, get yourself a reference manual.

V

I'm sorry for not making myself clear, Victor.

I'd like to adopt standard compliant naming conventions and thought that
the best way to do it would be to read up on the C++ standard naming
conventions. Boost.org, for instance, recommends this.

I found a link [1] but, seeing the standards presented on the page are
_derived_ from the C++ Coding Standards, I'm unsure what to make of it...


[1] http://www.nws.noaa.gov/oh/hrl/ihfs/standards/html/C++_naming.htm

 

[Victor Bazarov]

Miguel Guedes wrote:
What do you need it for? If you want to know what's allowed to be
used, get a copy of the Standard, and see what's not allowed;
everything else would be OK. All names visible to the programmer
are defined in the Standard already. You're not supposed to add
any. If you need to know what functions/objects/types exist, get
yourself a reference manual.

V

I'm sorry for not making myself clear, Victor.

I'd like to adopt standard compliant naming conventions and thought
that the best way to do it would be to read up on the C++ standard
naming conventions. Boost.org, for instance, recommends this.

I found a link [1] but, seeing the standards presented on the page are
_derived_ from the C++ Coding Standards, I'm unsure what to make of
it...


[1] http://www.nws.noaa.gov/oh/hrl/ihfs/standards/html/C++_naming.htm

Ah... Um... All names are lowercase. Multi-word names have words
separated by underscores (random_shuffle, push_back, find_if). It's
not as consistent as many would like, though. E.g. "getline" is
a single "word", no underscores (and there are other examples like
that).

Don't get hung up on a specific naming convention. Pick one that is
convenient and be consistent with it.

V

 

[Miguel Guedes]

Ah... Um... All names are lowercase. Multi-word names have words
separated by underscores (random_shuffle, push_back, find_if). It's
not as consistent as many would like, though. E.g. "getline" is
a single "word", no underscores (and there are other examples like
that).

Don't get hung up on a specific naming convention. Pick one that is
convenient and be consistent with it.

V

Trouble is I have many questions I've not been able to find convincing
answers to. For instance:

- When naming pointers should I append a prefix (pName, or p_name), add
a suffix (name_p) or nothing at all?

- Should I name namespaces in all-lowercase letters or follow class name
conventions (all words start with uppercase)?

- What about global and static variables? Should I append a prefix 'glo'
and 'sta' respectively, as the guidelines in Boost.org recommend?

I won't bore you to death. This is just an illustration of how much
unsure I am when it comes to naming conventions.

In all honesty, the reason why I started this thread was because I'm
still using remnants of Microsoft's crippled god-awful hungarian
notation (professional obligation) and want to completely get rid of all
the inconsistencies it introduces. So, seeing I'm about to start anew, I
thought that there's nothing better than to follow _proper_ standards -
the ones specified in C++ standards.

 

[Bo Persson]

Miguel Guedes wrote:
:: Victor Bazarov wrote:
::: Miguel Guedes wrote:
::: What do you need it for? If you want to know what's allowed to
::: be used, get a copy of the Standard, and see what's not allowed;
::: everything else would be OK. All names visible to the programmer
::: are defined in the Standard already. You're not supposed to add
::: any. If you need to know what functions/objects/types exist, get
::: yourself a reference manual.
:::
::: V
::
:: I'm sorry for not making myself clear, Victor.
::
:: I'd like to adopt standard compliant naming conventions and
:: thought that the best way to do it would be to read up on the C++
:: standard naming conventions. Boost.org, for instance, recommends
:: this.
::
:: I found a link [1] but, seeing the standards presented on the page
:: are _derived_ from the C++ Coding Standards, I'm unsure what to
:: make of it...
::
::
:: [1]
:: http://www.nws.noaa.gov/oh/hrl/ihfs/standards/html/C++_naming.htm
::
:: --

The standard doesn't have a naming convention. Different chapters of
the standards document have different authors, and they don't agree
completely either on style or on namning.

Your link points to two reasonable and widespread conventions,
lowercase and underscore, or uppercase letters as word separators.
That gives you either get_line(), or GetLine(). Choose one, and stick
to it!

I do not at all believe in using prefixes, like ref or ptr, or using
an upper or lower case first letter to differentiate between different
types of objects.


Bo Persson

 

[Victor Bazarov]

Trouble is I have many questions I've not been able to find convincing
answers to. For instance:

- When naming pointers should I append a prefix (pName, or p_name),
add a suffix (name_p) or nothing at all?

- Should I name namespaces in all-lowercase letters or follow class
name conventions (all words start with uppercase)?

- What about global and static variables? Should I append a prefix
'glo' and 'sta' respectively, as the guidelines in Boost.org
recommend?

I won't bore you to death. This is just an illustration of how much
unsure I am when it comes to naming conventions.

In all honesty, the reason why I started this thread was because I'm
still using remnants of Microsoft's crippled god-awful hungarian
notation (professional obligation) and want to completely get rid of
all the inconsistencies it introduces. So, seeing I'm about to start
anew, I thought that there's nothing better than to follow _proper_
standards - the ones specified in C++ standards.

You're a bit mistaken here. The C++ Standard does NOT specify any
naming convention. It tries to follow some, but isn't doing a good
job, either.

Cleaning out inconsistencies is a good goal to have, unfortunately
it's an unattainable one. Even if you do a piece-meal by collecting
different conventions from more than one style guide, you will likely
end up with some sort of inconsistency or two. There is no escape.

The rule of thumb here is "try to be simple, as simple as possible,
but not simpler". If you think you need prefices, use them. Which
ones? Who cares? You just need to be consistent. 'p' for pointers,
'g' for globals, 'm' for members... It does not matter. The
Standard Library and the language proper does not use many prefices,
but it uses suffices, like '_t' for new types (size_t, ptrdiff_t).
Is that better? Not sure. Not all types have _t on them either.

Here is my final advice: take _a_ convention and write it down. Try
to reduce the number of rules you have in your style guide. If you
can, have no more than, say, five rules. If in the process of
following your own style guide you find that you need to introduce
more rules, try to resist the temptation becuase it may mean you'll
need to review previously written code, where you didn't follow
the same new rules. IOW, the style guide should be (a) a *guide*
not a *law*, and (b) *descriptive* more than *perscriptive*.

V

 

[Gianni Mariani]

Trouble is I have many questions I've not been able to find convincing
answers to. For instance:

- When naming pointers should I append a prefix (pName, or p_name), add
a suffix (name_p) or nothing at all?

- Should I name namespaces in all-lowercase letters or follow class name
conventions (all words start with uppercase)?

- What about global and static variables? Should I append a prefix 'glo'
and 'sta' respectively, as the guidelines in Boost.org recommend?

I won't bore you to death. This is just an illustration of how much
unsure I am when it comes to naming conventions.

In all honesty, the reason why I started this thread was because I'm
still using remnants of Microsoft's crippled god-awful hungarian
notation (professional obligation) and want to completely get rid of all
the inconsistencies it introduces. So, seeing I'm about to start anew, I
thought that there's nothing better than to follow _proper_ standards -
the ones specified in C++ standards.

I have a naming convention for you.

Pick names that mean somthing useful.

e.g., I don't find it useful to prepend "p" for pointer, but I do find
it useful to prepend "s_" for static, or "w_" for template parameter or
"m_" for member variable - but not for function names.

The convention I usually use is:

When declaring function parameters do:
i_ - input
o_ - output
io_ - input/output

Class members:
t_ - type
m_ - member
s_ - static member

Templates
w_ - template parameter

Other decls
g_ - global variable
l_ - local variable


This does help me disambiguate some cases - like:

struct A
{
int m_val;
A( int i_val ) : m_val( i_val ) {}
};


Make sense ?

 

[=?ISO-8859-1?Q?Erik_Wikstr=F6m?=]

Trouble is I have many questions I've not been able to find convincing
answers to. For instance:

- When naming pointers should I append a prefix (pName, or p_name), add
a suffix (name_p) or nothing at all?

Use names that makes sense, it's often more important to know what it
points to than that it's a pointer. Most IDEs can tell you the type of a
variable but they can not tell you what the value represents.

- Should I name namespaces in all-lowercase letters or follow class name
conventions (all words start with uppercase)?

As previously pointed out, the classes etc. in the standard library use
underscores and not camel-case. Personally I like camel-case better but
Bjarne Stroustrup claims that underscores have been proven to be more
readable.

- What about global and static variables? Should I append a prefix 'glo'
and 'sta' respectively, as the guidelines in Boost.org recommend?

You should avoid globals

I won't bore you to death. This is just an illustration of how much
unsure I am when it comes to naming conventions.

In all honesty, the reason why I started this thread was because I'm
still using remnants of Microsoft's crippled god-awful hungarian
notation (professional obligation) and want to completely get rid of all
the inconsistencies it introduces.

If you try to get rid of MS's Hungarian notation then why do you try to
put it back in with prefixing stuff. The original Hungarian notation
used prefixes to indicate what type of data was stored, not the type of
the variable used to store them, i.e. szWidth indicates that the
variable contains the size of something.

So, seeing I'm about to start anew, I thought that there's nothing
better than to follow _proper_ standards - the ones specified in C++
standards.

There is no formal C++ naming convention used by the standards committee
(AFAIK) but they do try to keep things consistent but I'm quite sure
that there are inconsistencies, some due to backward compatibility no
doubt. If you are looking at for a standard you'll probably have better
luck looking at Java and .Net, for frameworks that large I'm sure they
have worked out some standard.

Get something that feels comfortable and start to write a list of how
you should name stuff, when you can no longer come up with any more
cases start using the standard and fix the remaining cases as they come
up. It does not matter what standard you use, because I can almost
guarantee that none else will used the same standard, there are always
some corner cases where they differ.

 

[Bo Persson]

Gianni Mariani wrote:
:: Miguel Guedes wrote:
:::
::: In all honesty, the reason why I started this thread was because
::: I'm still using remnants of Microsoft's crippled god-awful
::: hungarian notation (professional obligation) and want to
::: completely get rid of all the inconsistencies it introduces. So,
::: seeing I'm about to start anew, I thought that there's nothing
::: better than to follow _proper_ standards - the ones specified in
::: C++ standards.
::
:: I have a naming convention for you.
::
:: Pick names that mean somthing useful.

Good idea!!

::
:: struct A
:: {
:: int m_val;
:: A( int i_val ) : m_val( i_val ) {}
:: };
::
::
:: Make sense ?

Personally I don't like all the underscores and little separate
characters.

I have a hypothesis that there might be some cultural preferences
between people using get_line() and GetLine(). Scandinavians and
germans, for example are very used to create new words by appending a
number of smaller words. We do that all the time, IRL! English and
americans do not, and that might make them prefer to write
lots_of_little_words_with_undescores. I find that hard to read!

struct A
{
int Value;
A(int Init) : Value(Init) {}
};



Bo Persson

 

[Bo Persson]

Miguel Guedes wrote:
:: Victor Bazarov wrote:
::: Ah... Um... All names are lowercase. Multi-word names have words
::: separated by underscores (random_shuffle, push_back, find_if).
::: It's not as consistent as many would like, though. E.g.
::: "getline" is
::: a single "word", no underscores (and there are other examples like
::: that).
:::
::: Don't get hung up on a specific naming convention. Pick one that
::: is convenient and be consistent with it.
:::
::: V
::
:: Trouble is I have many questions I've not been able to find
:: convincing answers to. For instance:
::
:: - When naming pointers should I append a prefix (pName, or
:: p_name), add a suffix (name_p) or nothing at all?

Think about what that will buy you. Is it important to always know
that something is a pointer? When you later realize that it should
have been a reference, will you change the name?

Pointers are easily recognized as they are used in expressions like
*Name, or Name->Something.

::
:: - Should I name namespaces in all-lowercase letters or follow
:: class name conventions (all words start with uppercase)?

You should probably just use one way of creating names. Otherwise you
risk getting names that just differs by case.

namespace car
{
class Car;
}

Now you have

car::Car // a type

Car::Car // a constructor

Not good!

::
:: - What about global and static variables? Should I append a prefix
:: 'glo' and 'sta' respectively, as the guidelines in Boost.org
:: recommend?

You probably shouldn't use many of these in the first place!

If you need some global configuration settings, for example, you can
put them in a namespace and get code like:

if (Global::Config::ShowDebugInfo)
{
// display something interesting
}

::
:: I won't bore you to death. This is just an illustration of how much
:: unsure I am when it comes to naming conventions.

So are we. And nobody agrees anyway!

Use readable names!

::
:: In all honesty, the reason why I started this thread was because
:: I'm still using remnants of Microsoft's crippled god-awful
:: hungarian notation (professional obligation) and want to
:: completely get rid of all the inconsistencies it introduces.

That was somewhat useful once upon a time, to simulate type checking
when C types were really just typedefs. In C++ the compiler will tell
you not to mix two incompatible classes in the same expression.

:: So,
:: seeing I'm about to start anew, I thought that there's nothing
:: better than to follow _proper_ standards - the ones specified in
:: C++ standards.

And there aren't any. :-(


Bo Persson

 

[Miguel Guedes]

I have a naming convention for you.

Pick names that mean somthing useful.

e.g., I don't find it useful to prepend "p" for pointer, but I do find
it useful to prepend "s_" for static, or "w_" for template parameter or
"m_" for member variable - but not for function names.

The convention I usually use is:

When declaring function parameters do:
i_ - input
o_ - output
io_ - input/output

This makes no sense. In my experience the name of the argument is more
than enough to specify what is I/O and if I really want to go all the
way - as I am forced to - I document the code as I go using Doxygen's tags.

Class members:
t_ - type
m_ - member

I've used 'm_' prefixes for class members for far too long and I still
feel today as I did then when I was forced to adopt this naming scheme -
that it doesn't improve code readability in the slightest, though it
does help to avoid ambiguous situations.

For instance, just now I stepped into this situation:

class Window
{
public:
bool isMinimized() const;
bool onFullScreen() const;

protected:
bool isMinimized;
bool onFullScreen;
}

Now, do I change the method's names or the attributes'? Obviously I
ended up changing the attributes' but if I were using the 'm_' prefix
this would never have been an issue...

s_ - static member

I treat static members as class members, only I declare them in a 'meta'
section above all class declarations.

Templates
w_ - template parameter

I'd rather stick to one single uppercase letter as it stands out well
enough.

Other decls
g_ - global variable

I tend to append the 'g_' prefix, but then again I also refer to global
variables and functions using the global namespace '::' too, which makes
the prefix redundant.

l_ - local variable
Why?



This does help me disambiguate some cases - like:

struct A
{
int m_val;
A( int i_val ) : m_val( i_val ) {}
};

The constructor of A (without modifying the parameter's name) can
actually be written as:

A(int val) : val(val) {}

.... without any warnings being output (in MsVC.)

Make sense ?

Not at all. In my opinion, I would find code written using your naming
scheme cryptic, hard to read and understand. But then again, people are
different and I guess if you're using this naming scheme that means you
must do well with it.

 

[Miguel Guedes]

Think about what that will buy you. Is it important to always know
that something is a pointer? When you later realize that it should
have been a reference, will you change the name?

Pointers are easily recognized as they are used in expressions like
*Name, or Name->Something.

You should probably just use one way of creating names. Otherwise you
risk getting names that just differs by case.

namespace car
{
class Car;
}

Now you have

car::Car // a type

Car::Car // a constructor

Not good!

Note taken. I asked that question because STL's namespaces are all in
lowercase and I think I read a guideline somewhere on the Net.

You probably shouldn't use many of these in the first place!

If you need some global configuration settings, for example, you can
put them in a namespace and get code like:

if (Global::Config::ShowDebugInfo)
{
// display something interesting
}

::
:: I won't bore you to death. This is just an illustration of how much
:: unsure I am when it comes to naming conventions.

So are we. And nobody agrees anyway!

He he. Somehow I don't feel as bad!

Use readable names!


That was somewhat useful once upon a time, to simulate type checking
when C types were really just typedefs. In C++ the compiler will tell
you not to mix two incompatible classes in the same expression.

:: So,
:: seeing I'm about to start anew, I thought that there's nothing
:: better than to follow _proper_ standards - the ones specified in
:: C++ standards.

And there aren't any. :-(


Bo Persson

So, I take it the moral of the story is: make up your own naming
convention and stick to them?

 

[Alf P. Steinbach]

* Miguel Guedes:

So, I take it the moral of the story is: make up your own naming
convention and stick to them?

To some degree.

However, Java and C# have established naming conventions, and to keep
things as simple as possible it's a good idea to try to use as much as
practical of the same conventions in all three languages, e.g. "my"
prefix for (most) instance members, "s" suffix for collection type
names, camel-case for function names (except if colleagues puke), except
that Java and C#'s all uppercase for constants is counter-productive in
C++, where that form should be reserved for macro names, except that
Java and C#'s "get"-convention is also counter-productive in C++ (I
guess those counter-productive cases are part of "practicalness").

There's also another consideration: by /not/ adopting the standard
library's type name conventions, e.g. don't use "_t" suffix, and /not/
adopting the Windows API's function name conventions, i.e. don't use
uppercase first letter for function names, it becomes easier to see
which names are or are not from the standard library or Windows API.

Personally I prefer first letter uppercase (Pascal-case) for types and
having all other names in camel-case, which frees the underscore for the
places it really can help separate logically distinct name parts, and
also makes it possible to have "Bananas bananas" without being overly
creative in trying to come up with some distinct name for the instance.

For a period I tended to stick a "_" suffix on template names, but I
can't recollect why I thought that was so splendid an idea.

 

[Gianni Mariani]

Let me start by saying that there is NO right answer and YMMV.

This makes no sense. In my experience the name of the argument is more
than enough to specify what is I/O and if I really want to go all the
way - as I am forced to - I document the code as I go using Doxygen's tags.

I have a very different experience to you then.

I've used 'm_' prefixes for class members for far too long and I still
feel today as I did then when I was forced to adopt this naming scheme -
that it doesn't improve code readability in the slightest, though it
does help to avoid ambiguous situations.

exactly. I use many editor features like "highlight all occurrences of
word under cursor" which makes it very easy to look at a chunk o code
and understand it better. So, disambiguating is very useful.

For instance, just now I stepped into this situation:

class Window
{
public:
bool isMinimized() const;
bool onFullScreen() const;

protected:
bool isMinimized;
bool onFullScreen;
}

Now, do I change the method's names or the attributes'? Obviously I
ended up changing the attributes' but if I were using the 'm_' prefix
this would never have been an issue...


I treat static members as class members, only I declare them in a 'meta'
section above all class declarations

I'm not sure if that is a critique or just an observation ...

I'd rather stick to one single uppercase letter as it stands out well
enough.

That's just it, it does not. When you have a more complex set of
templates you need template parameter names that make sense.

I tend to append the 'g_' prefix, but then again I also refer to global
variables and functions using the global namespace '::' too, which makes
the prefix redundant.


Why?

Consistantcy and ambiguity resolution.

The constructor of A (without modifying the parameter's name) can
actually be written as:

A(int val) : val(val) {}

Yes, but I'm not doing this for the sake of the compiler.

... without any warnings being output (in MsVC.)


Not at all. In my opinion, I would find code written using your naming
scheme cryptic, hard to read and understand. But then again, people are
different and I guess if you're using this naming scheme that means you
must do well with it.

In my opinion, your opinion is unfounded since I have experience
otherwise that tells me it's easy to use and makes code more readable.

 

[Frank Birbacher]

Hi!

Personally I prefer first letter uppercase (Pascal-case) for types and
having all other names in camel-case, which frees the underscore for the
places it really can help separate logically distinct name parts, and
also makes it possible to have "Bananas bananas" without being overly
creative in trying to come up with some distinct name for the instance.

Yes. I agree to this. This matches my preferences. And with Bo's
hypothesis: I'm German and I don't like names_with_underscores, but I
like CamelCase.

For a period I tended to stick a "_" suffix on template names, but I
can't recollect why I thought that was so splendid an idea.

I see them as regular types, thus they get an uppercase CamelCase name
which usually names the concept the type needs to implement:
template<typename RandomAccessIterator> ...

But I disagree on Bo's namespace example:

namespace car {
class Car;
}

car::Car //type
Car::Car //ctor

I use lowercase namespace names. But this ambiguty has never bitten me.
Creating a namespace with the same name as a type therein seems to be a
conceptual error in naming (at least to me).

Frank

 

[Frank Birbacher]

Hi!

In my opinion, your opinion is unfounded since I have experience
otherwise that tells me it's easy to use and makes code more readable.

How many lines of code does your average function contain?

Frank

 

[Gianni Mariani]

Hi!



How many lines of code does your average function contain?

I don't count lines of code in a function so I don't know.

The idea is that functions are "orthogonal" in terms of functionality.
If a function gets a little long winded, you should try to see if there
is any repetition in the code that allows you to break the function down
to logical "orthogonal" units.

There are a small set of hard problems that are simply complex logic. I
don't advocate breaking a complex unit for the sake of breaking it down
to a set of complex units that make a more complex system than what you
began with. That means you will occasionally find a function that is
huge (very occasionally). One that comes to mind was a real-time UDP
protocol stack. For every packet that came in it needed to deal with
about 18 cases that were inter-related. That function, while it was
complex and long really could not be simplified without making the
"system" more complex, or at least I couldn't come up with a way at the
time that made any sense to me.

You'll find an example of code using the naming convention I described
here and a bunch of functions where you can figure out the average
length from:

http://austria.sourceforge.net/dox/html/at__lifetime_8h-source.html

It's doxygenated so it's missing lots of doxygen comments.

 

[Miguel Guedes]

Hi!


Yes. I agree to this. This matches my preferences. And with Bo's
hypothesis: I'm German and I don't like names_with_underscores, but I
like CamelCase.

I'm neither German nor from an English-speaking country, but I too
prefer CamelCase over underscoring! I can still remember a few times
when I had to develop server-side scripting for a few websites in PHP
and the shock it was to have to use underscoring so as to be consistent
with the language (PHP uses underscoring.) Not only does it make typing
slower (in my case), but also I find it impacts slightly on code readbility.

Speaking of the '_' character I am currently appending a '_' prefix to
_private_ class members (attributes/methods) but I'm unsure if it's
worth the effort. What do you think?

I see them as regular types, thus they get an uppercase CamelCase name
which usually names the concept the type needs to implement:
template<typename RandomAccessIterator> ...

Good to know it's not against any C++ programmer's standard to adopt
template type names lengthier than one letter.

Some of the guidelines on C++ coding styles I found on the net from big
corporations and research institutes recommend that templates types be
one uppercase letter, while others advise against it for the sake of
code readability, etc. This same inconsistency applies to namespaces,
class attributes and methods, and anything else that involves picking a
name.

This lack of a 'standard' among C++ programmers, so to speak, has only
added to my confusion making it unclear which naming scheme to adopt.

But I disagree on Bo's namespace example:

namespace car {
class Car;
}

car::Car //type
Car::Car //ctor

I use lowercase namespace names. But this ambiguty has never bitten me.
Creating a namespace with the same name as a type therein seems to be a
conceptual error in naming (at least to me).

Frank

Note taken. I was using CamelCase, first letter uppercased, but somehow
it didn't feel right. You've now given me a logical reason to why not do it.


Thank you - all the posters who've contributed to this thread - for
making it all a bit clearer, and easier for me. Hopefully, the
information contained in this thread will be as useful to others as it
is to me.

This newsgroup is without a doubt a source of immense knowledge.

 

[Frank Birbacher]

Hi!

Good to know it's not against any C++ programmer's standard to adopt
template type names lengthier than one letter.

Well, if there is no particular concept the type needs to model I
will use "T" as the template parameter (assuming value semantics, which
could be expressed as CopyConstructibleAndAssignable, but that is too
clumsy). I take this as a consensus just like using "i" as a "for"-loop
counter. But often enough I also name it "Value". I guess I'm still
searching for my personal naming convention.

This newsgroup is without a doubt a source of immense knowledge.

Frank