Reviewing GGL against Boost requirements

classic Classic list List threaded Threaded
23 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Reviewing GGL against Boost requirements

Mateusz Loskot
Administrator
Folks,

Perhaps it would be a good idea to walk through Boost guidelines
regarding dirs and files structures, naming, etc. and do a kind of
review of GGL source code. This could make it clear what kind of changes
and how deep changes would be required to follow Boost policies.

I could do it by walking through the Boost policies documents [1]
and [2], list every guideline/requirement and check if GGL does follow
it or not.

[1] http://www.boost.org/development/requirements.html
[2] http://www.boost.org/development/header.html

Do you think it's a good idea?

Best regards,
--
Mateusz Loskot, http://mateusz.loskot.net
Charter Member of OSGeo, http://osgeo.org
--
Mateusz Loskot
http://mateusz.loskot.net
Reply | Threaded
Open this post in threaded view
|

Reviewing GGL against Boost requirements

Barend Gehrels
Hi Mateusz,

> Folks,
>
> Perhaps it would be a good idea to walk through Boost guidelines
> regarding dirs and files structures, naming, etc. and do a kind of
> review of GGL source code. This could make it clear what kind of changes
> and how deep changes would be required to follow Boost policies.
>
> I could do it by walking through the Boost policies documents [1]
> and [2], list every guideline/requirement and check if GGL does follow
> it or not.
>
> [1] http://www.boost.org/development/requirements.html
>  
It is a good idea, sure. I've done it when I first submitted. Most of
the stuff will be according to these. The guidelines are updated last
year, e.g. I saw that the directory structure is now according to how
they are normally in the boost sandboxes (thought it was not like that
earlier).

Anyway, if you can do it it would be welcome. I know I didn't follow the
80-character guideline anymore, and I also favour tabs, but maybe we
should adapt it again.

Regards, Barend




Reply | Threaded
Open this post in threaded view
|

Reviewing GGL against Boost requirements

Mateusz Loskot
Administrator
Barend Gehrels wrote:

> Hi Mateusz,
>
>> Folks,
>>
>> Perhaps it would be a good idea to walk through Boost guidelines
>> regarding dirs and files structures, naming, etc. and do a kind of
>> review of GGL source code. This could make it clear what kind of
>> changes and how deep changes would be required to follow Boost
>> policies.
>>
>> I could do it by walking through the Boost policies documents [1]
>> and [2], list every guideline/requirement and check if GGL does
>> follow it or not.
>>
>> [1] http://www.boost.org/development/requirements.html
>>
> It is a good idea, sure.

Great, then I'll be on it.

> I've done it when I first submitted. Most of the stuff will be
> according to these. The guidelines are updated last year, e.g. I saw
> that the directory structure is now according to how they are
> normally in the boost sandboxes (thought it was not like that
> earlier).

Yes, I've noticed the structure is different in the sandbox.

> Anyway, if you can do it it would be welcome. I know I didn't follow
> the 80-character guideline anymore,

80-chars line is a guideline suggested as "source code should follow".

> and I also favour tabs, but maybe we should adapt it again.

Personally, I use spaces and I've probably destroyed tabs in
files I did edit :-)

I think that we will have to migrate to spaces anyways, because
tabs are clearly forbidden (for similar reasons I prefer spaces myself):

"Tabs are banned because of the practical problems caused by tabs"

http://www.boost.org/development/requirements.html#Tabs

So, what should I do with tabs? Shall I re-tab text files in the tree
(it's automatic process, by the way)?

Best regards,
--
Mateusz Loskot, http://mateusz.loskot.net
Charter Member of OSGeo, http://osgeo.org
--
Mateusz Loskot
http://mateusz.loskot.net
Reply | Threaded
Open this post in threaded view
|

Reviewing GGL against Boost requirements

Barend Gehrels

>  
>> and I also favour tabs, but maybe we should adapt it again.
>>    
>
> Personally, I use spaces and I've probably destroyed tabs in
> files I did edit :-)
>  
No problem
> I think that we will have to migrate to spaces anyways, because
> tabs are clearly forbidden (for similar reasons I prefer spaces myself):
>
> "Tabs are banned because of the practical problems caused by tabs"
>
> http://www.boost.org/development/requirements.html#Tabs
>  
I see it now, didn't see it earlier.
> So, what should I do with tabs? Shall I re-tab text files in the tree
> (it's automatic process, by the way)?
>  
If these are the guidelines we'll follow them. Alas they don't give a
number of spaces but let's take 4, as this is used in MPL and probably
everywhere. So re-tabbing is not necessary.

Regards, Barend

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osgeo.org/pipermail/ggl/attachments/20090419/72231ffa/attachment.html
Reply | Threaded
Open this post in threaded view
|

Reviewing GGL against Boost requirements

Mateusz Loskot
Administrator
Barend Gehrels wrote:

>> I think that we will have to migrate to spaces anyways, because
>> tabs are clearly forbidden (for similar reasons I prefer spaces myself):
>>
>> "Tabs are banned because of the practical problems caused by tabs"
>>
>> http://www.boost.org/development/requirements.html#Tabs
>
> I see it now, didn't see it earlier.
>> So, what should I do with tabs? Shall I re-tab text files in the tree
>> (it's automatic process, by the way)?
>
> If these are the guidelines we'll follow them. Alas they don't give a
> number of spaces but let's take 4, as this is used in MPL and probably
> everywhere. So re-tabbing is not necessary.

OK. Four is perfect for me.

Best regards,
--
Mateusz Loskot, http://mateusz.loskot.net
Charter Member of OSGeo, http://osgeo.org
--
Mateusz Loskot
http://mateusz.loskot.net
Reply | Threaded
Open this post in threaded view
|

Reviewing GGL against Boost requirements

Bruno Lalande
Hi,

>> If these are the guidelines we'll follow them. Alas they don't give a
>> number of spaces but let's take 4, as this is used in MPL and probably
>> everywhere. So re-tabbing is not necessary.
>
> OK. Four is perfect for me.

Yep I had seen this divergence from Boost guidelines when I joined the
project. Didn't do anything at that moment but I knew it would be
necessary in case of inclusion into Boost. And if you want to follow
the 80 characters guideline, it's necessary to not use tabs, for
obvious reasons. So let's go ahead and replace tabs by 4 spaces.

One thing about 80 characters: this guideline in much more easy to
follow when namespaces are not indented. It's the case in a lot of
Boost code and it's quite accepted in the C++ community. So given the
number of nested namespaces we sometimes have in GGL we could do that
as well. I've never noticed any particular problem of readability in
code I've written that way.

Regards
Bruno
Reply | Threaded
Open this post in threaded view
|

Reviewing GGL against Boost requirements

Mateusz Loskot
Administrator
Bruno Lalande wrote:

> Hi,
>
>>> If these are the guidelines we'll follow them. Alas they don't give a
>>> number of spaces but let's take 4, as this is used in MPL and probably
>>> everywhere. So re-tabbing is not necessary.
>> OK. Four is perfect for me.
>
> Yep I had seen this divergence from Boost guidelines when I joined the
> project. Didn't do anything at that moment but I knew it would be
> necessary in case of inclusion into Boost. And if you want to follow
> the 80 characters guideline, it's necessary to not use tabs, for
> obvious reasons. So let's go ahead and replace tabs by 4 spaces.


That's a good point! OK

> One thing about 80 characters: this guideline in much more easy to
> follow when namespaces are not indented. It's the case in a lot of
> Boost code and it's quite accepted in the C++ community. So given the
> number of nested namespaces we sometimes have in GGL we could do that
> as well. I've never noticed any particular problem of readability in
> code I've written that way.

So, we're going to not to indent code on namespace level, right?
If I am, do we assume this scheme?

namespace a {

class T
{
public:
     void foo();
protected:
     void bar();
private:
     std::size_t count_;
};

} // namespace a

Best regards,

--
Mateusz Loskot, http://mateusz.loskot.net
--
Mateusz Loskot
http://mateusz.loskot.net
Reply | Threaded
Open this post in threaded view
|

Reviewing GGL against Boost requirements

Barend Gehrels

>
>> One thing about 80 characters: this guideline in much more easy to
>> follow when namespaces are not indented. It's the case in a lot of
>> Boost code and it's quite accepted in the C++ community. So given the
>> number of nested namespaces we sometimes have in GGL we could do that
>> as well. I've never noticed any particular problem of readability in
>> code I've written that way.
>
> So, we're going to not to indent code on namespace level, right?

OK.

> namespace a {
>
> class T
> {
> public:
>     void foo();
> protected:
>     void bar();
> private:
>     std::size_t count_;
> };
>
> } // namespace a

Few things about this:
- I prefer a struct above a class because, especially in templates, many
is public, often there is no protected / private at all
- T in lowercase
- I've always used the m_ prefix for member variables, don't know where
it comes from. Find them much more readable. The boost sample header
gives no prefix/suffix at all. However, the m_ prefix is used in some
(not many) boost libraries as well (e.g. math/tools/remez). So here I
prefer to keep them, at least in this refactoring round
- In case of a template, I prefer the "typename" above the "class"
(unless, of course, if it is required as in template template parameters)

So new proposal:
namespace a {

template <typename T>
struct sample
{
    void foo();
protected:
    void bar();
private:
    std::size_t m_count;
};

} // namespace a



Regards, Barend




Reply | Threaded
Open this post in threaded view
|

Reviewing GGL against Boost requirements

Mateusz Loskot
Administrator
Barend Gehrels wrote:

>
>>
>>> One thing about 80 characters: this guideline in much more easy to
>>> follow when namespaces are not indented. It's the case in a lot of
>>> Boost code and it's quite accepted in the C++ community. So given the
>>> number of nested namespaces we sometimes have in GGL we could do that
>>> as well. I've never noticed any particular problem of readability in
>>> code I've written that way.
>>
>> So, we're going to not to indent code on namespace level, right?
>
> OK.


OK

>> namespace a {
>>
>> class T
>> {
>> public:
>>     void foo();
>> protected:
>>     void bar();
>> private:
>>     std::size_t count_;
>> };
>>
>> } // namespace a
>
> Few things about this:
> - I prefer a struct above a class because, especially in templates, many
> is public, often there is no protected / private at all
> - T in lowercase
> - I've always used the m_ prefix for member variables, don't know where
> it comes from. Find them much more readable. The boost sample header
> gives no prefix/suffix at all. However, the m_ prefix is used in some
> (not many) boost libraries as well (e.g. math/tools/remez). So here I
> prefer to keep them, at least in this refactoring round
> - In case of a template, I prefer the "typename" above the "class"
> (unless, of course, if it is required as in template template parameters)
> [...]


Sure, agreed.

The snippet I pasted was supposed to show indentation only,
not all-in-one coding style.

Best regards,
--
Mateusz Loskot, http://mateusz.loskot.net
--
Mateusz Loskot
http://mateusz.loskot.net
Reply | Threaded
Open this post in threaded view
|

Reviewing GGL against Boost requirements

Barend Gehrels

>
> The snippet I pasted was supposed to show indentation only,
> not all-in-one coding style.
It was useful anyway, so we've a new candidate for addition into
development_notes.txt
Barend


Reply | Threaded
Open this post in threaded view
|

Reviewing GGL against Boost requirements

Bruno Lalande
In reply to this post by Barend Gehrels
Hi

>> namespace a {
>>
>> class T
>> {
>> public:
>>    void foo();
>> protected:
>>    void bar();
>> private:
>>    std::size_t count_;
>> };
>>
>> } // namespace a

Yep that's what I meant about namespaces. With the convention to
always have the ending comment, sounds important to me precisely
because of the lack of indentation.

> - I prefer a struct above a class because, especially in templates, many is
> public, often there is no protected / private at all

Even if a struct and a class are technically the same, there's a
strong "emotional" difference between them in the head of most
programmers. "class" is often used for classes meant to produce actual
objects, which have methods and an active role in the runtime
functioning of the program. "struct" is rather used either for POD
structures, or for classes used at compile-time like metafunctions,
tags, traits, etc... So if the code above was mine I guess I'd choose
"class", but I'm open to use "struct" if you really prefer.

> - I've always used the m_ prefix for member variables, don't know where it
> comes from. Find them much more readable. The boost sample header gives no
> prefix/suffix at all. However, the m_ prefix is used in some (not many)
> boost libraries as well (e.g. math/tools/remez). So here I prefer to keep
> them, at least in this refactoring round
> - In case of a template, I prefer the "typename" above the "class" (unless,
> of course, if it is required as in template template parameters)

No strong opinion about that so it's ok for me. About "typename", even
though I often use "class" just by convenience (it's shorter ;-)), I
think you're right with "typename" because historically, the fact that
"class" can be used that way is an accident.

Regards
Bruno
Reply | Threaded
Open this post in threaded view
|

Reviewing GGL against Boost requirements

Mateusz Loskot
Administrator
Bruno Lalande wrote:

>>> namespace a {
>>>
>>> class T
>>> {
>>> public:
>>>    void foo();
>>> protected:
>>>    void bar();
>>> private:
>>>    std::size_t count_;
>>> };
>>>
>>> } // namespace a
>
> Yep that's what I meant about namespaces. With the convention to
> always have the ending comment, sounds important to me precisely
> because of the lack of indentation.

Also, sometimes it may be helpful to put

}; // class T
or
}; // struct T

comment if a file consists of number of classes and class
definitions are long.

>> - I prefer a struct above a class because, especially in templates, many is
>> public, often there is no protected / private at all
>
> Even if a struct and a class are technically the same, there's a
> strong "emotional" difference between them in the head of most
> programmers. "class" is often used for classes meant to produce actual
> objects, which have methods and an active role in the runtime
> functioning of the program. "struct" is rather used either for POD
> structures, or for classes used at compile-time like metafunctions,
> tags, traits, etc... So if the code above was mine I guess I'd choose
> "class", but I'm open to use "struct" if you really prefer.

Same here.

>> - I've always used the m_ prefix for member variables, don't know where it
>> comes from. Find them much more readable. The boost sample header gives no
>> prefix/suffix at all. However, the m_ prefix is used in some (not many)
>> boost libraries as well (e.g. math/tools/remez). So here I prefer to keep
>> them, at least in this refactoring round
>> - In case of a template, I prefer the "typename" above the "class" (unless,
>> of course, if it is required as in template template parameters)
>
> No strong opinion about that so it's ok for me. About "typename", even
> though I often use "class" just by convenience (it's shorter ;-)), I
> think you're right with "typename" because historically, the fact that
> "class" can be used that way is an accident.

Same here with inclination toward typename :-)


Best regards
--
Mateusz Loskot, http://mateusz.loskot.net
--
Mateusz Loskot
http://mateusz.loskot.net
Reply | Threaded
Open this post in threaded view
|

Reviewing GGL against Boost requirements

Barend Gehrels



> Also, sometimes it may be helpful to put
>
> }; // class T
> or
> }; // struct T
>
> comment if a file consists of number of classes and class definitions
> are long.
Don't see this a lot in boost. OK for me, but only if it is "very" long.


>
>>> - I prefer a struct above a class because, especially in templates,
>>> many is
>>> public, often there is no protected / private at all
>>
>> Even if a struct and a class are technically the same, there's a
>> strong "emotional" difference between them in the head of most
>> programmers. "class" is often used for classes meant to produce actual
>> objects, which have methods and an active role in the runtime
>> functioning of the program. "struct" is rather used either for POD
>> structures, or for classes used at compile-time like metafunctions,
>> tags, traits, etc... So if the code above was mine I guess I'd choose
>> "class", but I'm open to use "struct" if you really prefer.
>
> Same here.
I agree with this, OK for me. Updated the development_notes



Regards, Barend




Reply | Threaded
Open this post in threaded view
|

Reviewing GGL against Boost requirements

Mateusz Loskot
Administrator
Barend Gehrels wrote:

>
>
>
>> Also, sometimes it may be helpful to put
>>
>> }; // class T
>> or
>> }; // struct T
>>
>> comment if a file consists of number of classes and class definitions
>> are long.
 >
> Don't see this a lot in boost. OK for me, but only if it is "very" long.

Sure. It's a trivial thing anyway.

>>>> - I prefer a struct above a class because, especially in templates,
>>>> many is public, often there is no protected / private at all
>>>
>>> Even if a struct and a class are technically the same, there's a
>>> strong "emotional" difference between them in the head of most
>>> programmers. "class" is often used for classes meant to produce actual
>>> objects, which have methods and an active role in the runtime
>>> functioning of the program. "struct" is rather used either for POD
>>> structures, or for classes used at compile-time like metafunctions,
>>> tags, traits, etc... So if the code above was mine I guess I'd choose
>>> "class", but I'm open to use "struct" if you really prefer.
>>
>> Same here.
 >
> I agree with this, OK for me. Updated the development_notes

Great, thanks!

--
Mateusz Loskot, http://mateusz.loskot.net
Charter Member of OSGeo, http://osgeo.org
--
Mateusz Loskot
http://mateusz.loskot.net
Reply | Threaded
Open this post in threaded view
|

Reviewing GGL against Boost requirements

Mateusz Loskot
Administrator
In reply to this post by Barend Gehrels
Barend Gehrels wrote:

>
>>
>>> One thing about 80 characters: this guideline in much more easy to
>>> follow when namespaces are not indented. It's the case in a lot of
>>> Boost code and it's quite accepted in the C++ community. So given the
>>> number of nested namespaces we sometimes have in GGL we could do that
>>> as well. I've never noticed any particular problem of readability in
>>> code I've written that way.
>>
>> So, we're going to not to indent code on namespace level, right?
>
> OK.
>
>> namespace a {
>>
>> class T
>> {
>> public:
>>     void foo();
>> protected:
>>     void bar();
>> private:
>>     std::size_t count_;
>> };
>>
>> } // namespace a
>
> Few things about this:
> - I prefer a struct above a class because, especially in templates, many
> is public, often there is no protected / private at all
> - T in lowercase

One thing that seems I've not spotted:

What T in lowercase mean?

Is it about T as name of type (struct, class, typedef etc.)
or T as template parameter name?
For the latter, we've decided to use T or TemplParam naming. I'm a bit
confused :-)

Best regards,
--
Mateusz Loskot, http://mateusz.loskot.net
Charter Member of OSGeo, http://osgeo.org
--
Mateusz Loskot
http://mateusz.loskot.net
Reply | Threaded
Open this post in threaded view
|

Reviewing GGL against Boost requirements

Barend Gehrels

>>    
>>> namespace a {
>>>
>>> class T
>>> {
>>> public:
>>>     void foo();
>>> protected:
>>>     void bar();
>>> private:
>>>     std::size_t count_;
>>> };
>>>
>>> } // namespace a
>>>      
>> Few things about this:
>> - I prefer a struct above a class because, especially in templates, many
>> is public, often there is no protected / private at all
>> - T in lowercase
>>    
>
> One thing that seems I've not spotted:
>
> What T in lowercase mean?
>
> Is it about T as name of type (struct, class, typedef etc.)
> or T as template parameter name?
> For the latter, we've decided to use T or TemplParam naming. I'm a bit
> confused :-)
>  
Sure, it was just that here is stated "class T" and classes are normally
written in lowercase. Templates are (like in Boost) in MixedCase (or one
character as T) indeed.

Regards, Barend

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osgeo.org/pipermail/ggl/attachments/20090425/9b9299b4/attachment.html
Reply | Threaded
Open this post in threaded view
|

Reviewing GGL against Boost requirements

Mateusz Loskot
Administrator
Barend Gehrels wrote:

>
>>>    
>>>> namespace a {
>>>>
>>>> class T
>>>> {
>>>> public:
>>>>     void foo();
>>>> protected:
>>>>     void bar();
>>>> private:
>>>>     std::size_t count_;
>>>> };
>>>>
>>>> } // namespace a
>>>>      
>>> Few things about this:
>>> - I prefer a struct above a class because, especially in templates, many
>>> is public, often there is no protected / private at all
>>> - T in lowercase
>>>    
>>
>> One thing that seems I've not spotted:
>>
>> What T in lowercase mean?
>>
>> Is it about T as name of type (struct, class, typedef etc.)
>> or T as template parameter name?
>> For the latter, we've decided to use T or TemplParam naming. I'm a bit
>> confused :-)
>
> Sure, it was just that here is stated "class T" and classes are normally
> written in lowercase. Templates are (like in Boost) in MixedCase (or one
> character as T) indeed.

Understood.

--
Mateusz Loskot, http://mateusz.loskot.net
Charter Member of OSGeo, http://osgeo.org
--
Mateusz Loskot
http://mateusz.loskot.net
Reply | Threaded
Open this post in threaded view
|

Reviewing GGL against Boost requirements

Barend Gehrels
In reply to this post by Bruno Lalande

>>> If these are the guidelines we'll follow them. Alas they don't give a
>>> number of spaces but let's take 4, as this is used in MPL and probably
>>> everywhere. So re-tabbing is not necessary.
>>>      
>> OK. Four is perfect for me.
>>    
>
> Yep I had seen this divergence from Boost guidelines when I joined the
> project. Didn't do anything at that moment but I knew it would be
> necessary in case of inclusion into Boost. And if you want to follow
> the 80 characters guideline, it's necessary to not use tabs, for
> obvious reasons. So let's go ahead and replace tabs by 4 spaces.
>
> One thing about 80 characters: this guideline in much more easy to
> follow when namespaces are not indented. It's the case in a lot of
> Boost code and it's quite accepted in the C++ community. So given the
> number of nested namespaces we sometimes have in GGL we could do that
> as well. I've never noticed any particular problem of readability in
> code I've written that way.
>  
I'm doing some more implementations and at the same time try to conform
the touched sources to the new guidelines.

The CamelCase template parameters are fine for me.
Indentation makes it (my opinion) a bit less readable but is OK for me,
I'll get used to it.

What I really find hard is the 80 characters. Even if namespaces are not
indented.
I tried to adapt and nearly all lines get broken in the most weirdest
places, and/or spread over four lines. I just checked the Boost
libraries and all the libraries I checked (mpl, lambda, proto, variant,
spirit) do NOT follow it.

So I suggest we'll be not too strict here. We're living in 2009, 80
characters per line should be really over and done now.

Regards, Barend

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osgeo.org/pipermail/ggl/attachments/20090430/1274fb2a/attachment.html
Reply | Threaded
Open this post in threaded view
|

Reviewing GGL against Boost requirements

Bruno Lalande
Hi Barend,

> The CamelCase template parameters are fine for me.
> Indentation makes it (my opinion) a bit less readable but is OK for me, I'll
> get used to it.

About this: I think the most disturbing source of unreadability once
namespaces de-indented comes from namespaces such as "impl" that tend
to pollute the files. In this case maybe we could isolate them in a
"impl" directory when it's possible. If find my sources more readable
when I do that with the "detail" namespaces. Don't know if it helps
for the code you're reshaping...

> What I really find hard is the 80 characters. Even if namespaces are not
> indented.
> I tried to adapt and nearly all lines get broken in the most weirdest
> places, and/or spread over four lines. I just checked the Boost libraries
> and all the libraries I checked (mpl, lambda, proto, variant, spirit) do NOT
> follow it.

Indeed some sources don't follow the rule, but much efforts are made
to follow it if you look carefully. I think it can be broken but the
writer has to keep this limit in mind in order to avoid running over
it too much.

The only place where I personally completely forget this rule is for
test files. Such files usually contain very long literals, ugly
expressions, and other things that make them impossible to shape
correctly anyway...

> So I suggest we'll be not too strict here. We're living in 2009, 80
> characters per line should be really over and done now.

I work on a daily basis on native terminals, so 80 characters. The
machines we ship to our customers run on recent systems but just don't
need any advanced interfacing stuff. Of course when it's possible I
connect in SSH from my own computer to have a better view.

I'm OK to not be too strict about that, but let's at least stick to a
100-character rule.

Regards
Bruno
Reply | Threaded
Open this post in threaded view
|

Reviewing GGL against Boost requirements

Mateusz Loskot
Administrator
In reply to this post by Barend Gehrels
Barend Gehrels wrote:
> Indentation makes it (my opinion) a bit less readable but is OK for me,
> I'll get used to it.

The point is that namespace are more like inclusion guards,
you rarely have more than 2 in single file.

> What I really find hard is the 80 characters. Even if namespaces are not
> indented.
> I tried to adapt and nearly all lines get broken in the most weirdest
> places, and/or spread over four lines. I just checked the Boost
> libraries and all the libraries I checked (mpl, lambda, proto, variant,
> spirit) do NOT follow it.

Right.

> So I suggest we'll be not too strict here. We're living in 2009, 80
> characters per line should be really over and done now.

I don't mind to allow more than 80 characters, let's say up to 100.
Most people work with big or multiple screens nowadays.

However and perhaps, for long and complex template/typedef definitions,
it may make sense to indent template params.
It's not uncommon in Boost too. For instance:

typedef typename ia_dflt_help<
      Reference
     , function_object_result<UnaryFunc>
  >::type reference;

or something like this

template
<
     typename T,
     typename P,
     typename A = std::allocator<T, P>
 >
struct my_type
{
};

instead of all in single line.

--
Mateusz Loskot, http://mateusz.loskot.net
--
Mateusz Loskot
http://mateusz.loskot.net
12