Menu
▾
▴
corelinux-develop
|
From: Hans D. <dul...@eg...> - 2000-09-23 01:12:22
|
Frank, I thought I fixed bug 113984 (header alignments).
But again I checked the cppstnd.tex and could not find any
appropriate guidelines.
You wrote the following three lines in the bug report:
[#1] Method comments should left justify with return type in signature.
[#2] Method signatures should left justify with return types in
signature.
[#3] Return types generally align on a four level indentation depth.
My questions:
Point #1 and #2 were clearly understood.
Point #3 is a bit unclear: when you mentioned "4-level deep", which
column is the reference column? I assume it is 4-level deep relative
to the "class" keyword.
Is the following correctly indented according to the above 'guidelines'?
(leading blanks were replaced with = or -)
namespace corelinux {
===class MyClass {
===---===---===/**
===---===---===---constructors have no return type.
===---===---===---I assume the return type is "empty string"
===---===---===*/
===---===---===MyClass( params );
===---===---===/// comment for virtual MethodA
===---virtual ReturnType MethodA( signature ... );
===---===---===/// comment for methodB
===---===---===void MethodB ( signature ... );
===};
}
I think we should add this "guideline" to the C++ Coding standard.
--
Hans Dulimarta, Ph.D. dul...@co...
P: 517-432-7589 http://www.egr.msu.edu/~dulimart
F: 760-281-7691 http://corelinux.sourceforge.net
Elec. & Comp. Engg., Mich. State Univ., E. Lansing, MI 48824
|
|
From: Frank V. C. <fr...@co...> - 2000-09-23 02:08:11
|
Hans Dulimarta wrote:
>
> Frank, I thought I fixed bug 113984 (header alignments).
> But again I checked the cppstnd.tex and could not find any
> appropriate guidelines.
>
> You wrote the following three lines in the bug report:
>
> [#1] Method comments should left justify with return type in signature.
> [#2] Method signatures should left justify with return types in
> signature.
> [#3] Return types generally align on a four level indentation depth.
What I meant by #3 can be summarized in the header file
MutexSemaphoreGroup.hpp, so in answer to your graphic depiction, yes it
is correct with the exception of the class MyClass opening brace (which
should line up with 'class' on the next line.
Now, this has mostly been my organization and alignment which for me is
readable. How do you feel about it?
>
> My questions:
> Point #1 and #2 were clearly understood.
> Point #3 is a bit unclear: when you mentioned "4-level deep", which
> column is the reference column? I assume it is 4-level deep relative
> to the "class" keyword.
>
> Is the following correctly indented according to the above 'guidelines'?
> (leading blanks were replaced with = or -)
>
> namespace corelinux {
>
> ===class MyClass {
> ===---===---===/**
> ===---===---===---constructors have no return type.
> ===---===---===---I assume the return type is "empty string"
> ===---===---===*/
> ===---===---===MyClass( params );
>
> ===---===---===/// comment for virtual MethodA
> ===---virtual ReturnType MethodA( signature ... );
>
> ===---===---===/// comment for methodB
> ===---===---===void MethodB ( signature ... );
> ===};
> }
>
> I think we should add this "guideline" to the C++ Coding standard.
>
> --
> Hans Dulimarta, Ph.D. dul...@co...
> P: 517-432-7589 http://www.egr.msu.edu/~dulimart
> F: 760-281-7691 http://corelinux.sourceforge.net
> Elec. & Comp. Engg., Mich. State Univ., E. Lansing, MI 48824
> _______________________________________________
> Corelinux-develop mailing list
> Cor...@li...
> http://lists.sourceforge.net/mailman/listinfo/corelinux-develop
--
Frank V. Castellucci
|
|
From: Hans D. <dul...@eg...> - 2000-09-23 04:34:14
|
"Frank V. Castellucci" wrote:
>
> Hans Dulimarta wrote:
> >
> > Frank, I thought I fixed bug 113984 (header alignments).
> > But again I checked the cppstnd.tex and could not find any
> > appropriate guidelines.
> >
> > You wrote the following three lines in the bug report:
> >
> > [#1] Method comments should left justify with return type in signature.
> > [#2] Method signatures should left justify with return types in
> > signature.
> > [#3] Return types generally align on a four level indentation depth.
>
> What I meant by #3 can be summarized in the header file
> MutexSemaphoreGroup.hpp, so in answer to your graphic depiction, yes it
> is correct with the exception of the class MyClass opening brace (which
> should line up with 'class' on the next line.
>
> Now, this has mostly been my organization and alignment which for me is
> readable. How do you feel about it?
Personally, I prefer the comments flushed left with any
modifiers, which means
that 4 level indentation does not apply. But, I guess for
this project I have
to decline my own preferences.
>
> >
> > My questions:
> > Point #1 and #2 were clearly understood.
> > Point #3 is a bit unclear: when you mentioned "4-level deep", which
> > column is the reference column? I assume it is 4-level deep relative
> > to the "class" keyword.
> >
> > Is the following correctly indented according to the above 'guidelines'?
> > (leading blanks were replaced with = or -)
> >
> > namespace corelinux {
> >
> > ===class MyClass {
> > ===---===---===/**
> > ===---===---===---constructors have no return type.
> > ===---===---===---I assume the return type is "empty string"
> > ===---===---===*/
> > ===---===---===MyClass( params );
> >
> > ===---===---===/// comment for virtual MethodA
> > ===---virtual ReturnType MethodA( signature ... );
> >
> > ===---===---===/// comment for methodB
> > ===---===---===void MethodB ( signature ... );
> > ===};
> > }
> >
> > I think we should add this "guideline" to the C++ Coding standard.
> >
> > --
> > Hans Dulimarta, Ph.D. dul...@co...
> > P: 517-432-7589 http://www.egr.msu.edu/~dulimart
> > F: 760-281-7691 http://corelinux.sourceforge.net
> > Elec. & Comp. Engg., Mich. State Univ., E. Lansing, MI 48824
> > _______________________________________________
> > Corelinux-develop mailing list
> > Cor...@li...
> > http://lists.sourceforge.net/mailman/listinfo/corelinux-develop
>
> --
> Frank V. Castellucci
> _______________________________________________
> Corelinux-develop mailing list
> Cor...@li...
> http://lists.sourceforge.net/mailman/listinfo/corelinux-develop
--
Hans Dulimarta, Ph.D. dul...@co...
P: 517-432-7589
http://www.egr.msu.edu/~dulimart
F: 760-281-7691 http://corelinux.sourceforge.net
Elec. & Comp. Engg., Mich. State Univ., E. Lansing, MI 48824
|
|
From: Frank V. C. <fr...@co...> - 2000-09-23 05:05:12
|
Hans Dulimarta wrote:
>
> "Frank V. Castellucci" wrote:
> >
> > Hans Dulimarta wrote:
> > >
> > > Frank, I thought I fixed bug 113984 (header alignments).
> > > But again I checked the cppstnd.tex and could not find any
> > > appropriate guidelines.
> > >
> > > You wrote the following three lines in the bug report:
> > >
> > > [#1] Method comments should left justify with return type in signature.
> > > [#2] Method signatures should left justify with return types in
> > > signature.
> > > [#3] Return types generally align on a four level indentation depth.
> >
> > What I meant by #3 can be summarized in the header file
> > MutexSemaphoreGroup.hpp, so in answer to your graphic depiction, yes it
> > is correct with the exception of the class MyClass opening brace (which
> > should line up with 'class' on the next line.
> >
> > Now, this has mostly been my organization and alignment which for me is
> > readable. How do you feel about it?
>
> Personally, I prefer the comments flushed left with any
> modifiers, which means
> that 4 level indentation does not apply. But, I guess for
> this project I have
> to decline my own preferences.
I guess the goal/objective is that whatever the standard is, that the
code be consistent. So if we started with flushing left the comments
with the modifiers, as long as we stuck to it, would have been ok. And
this is your project now! :)
BTW: Are you done with the checking in for the moment?
>
> >
> > >
> > > My questions:
> > > Point #1 and #2 were clearly understood.
> > > Point #3 is a bit unclear: when you mentioned "4-level deep", which
> > > column is the reference column? I assume it is 4-level deep relative
> > > to the "class" keyword.
> > >
> > > Is the following correctly indented according to the above 'guidelines'?
> > > (leading blanks were replaced with = or -)
> > >
> > > namespace corelinux {
> > >
> > > ===class MyClass {
> > > ===---===---===/**
> > > ===---===---===---constructors have no return type.
> > > ===---===---===---I assume the return type is "empty string"
> > > ===---===---===*/
> > > ===---===---===MyClass( params );
> > >
> > > ===---===---===/// comment for virtual MethodA
> > > ===---virtual ReturnType MethodA( signature ... );
> > >
> > > ===---===---===/// comment for methodB
> > > ===---===---===void MethodB ( signature ... );
> > > ===};
> > > }
> > >
> > > I think we should add this "guideline" to the C++ Coding standard.
> > >
> > > --
> > > Hans Dulimarta, Ph.D. dul...@co...
> > > P: 517-432-7589 http://www.egr.msu.edu/~dulimart
> > > F: 760-281-7691 http://corelinux.sourceforge.net
> > > Elec. & Comp. Engg., Mich. State Univ., E. Lansing, MI 48824
> > > _______________________________________________
> > > Corelinux-develop mailing list
> > > Cor...@li...
> > > http://lists.sourceforge.net/mailman/listinfo/corelinux-develop
> >
> > --
> > Frank V. Castellucci
> > _______________________________________________
> > Corelinux-develop mailing list
> > Cor...@li...
> > http://lists.sourceforge.net/mailman/listinfo/corelinux-develop
>
> --
> Hans Dulimarta, Ph.D. dul...@co...
> P: 517-432-7589
> http://www.egr.msu.edu/~dulimart
> F: 760-281-7691 http://corelinux.sourceforge.net
> Elec. & Comp. Engg., Mich. State Univ., E. Lansing, MI 48824
> _______________________________________________
> Corelinux-develop mailing list
> Cor...@li...
> http://lists.sourceforge.net/mailman/listinfo/corelinux-develop
--
Frank V. Castellucci
http://corelinux.sourceforge.net
OOA/OOD/C++ Standards and Guidelines for Linux
http://PythPat.sourceforge.net
Pythons Pattern Package
|
|
From: Hans D. <dul...@eg...> - 2000-09-23 06:24:02
|
"Frank V. Castellucci" wrote:
>
> Hans Dulimarta wrote:
> >
> > "Frank V. Castellucci" wrote:
> > >
> > > What I meant by #3 can be summarized in the header file
> > > MutexSemaphoreGroup.hpp, so in answer to your graphic depiction, yes it
> > > is correct with the exception of the class MyClass opening brace (which
> > > should line up with 'class' on the next line.
> > >
> > > Now, this has mostly been my organization and alignment which for me is
> > > readable. How do you feel about it?
> >
> > Personally, I prefer the comments flushed left with any
> > modifiers, which means
> > that 4 level indentation does not apply. But, I guess for
> > this project I have
> > to decline my own preferences.
>
> I guess the goal/objective is that whatever the standard is, that the
> code be consistent. So if we started with flushing left the comments
> with the modifiers, as long as we stuck to it, would have been ok. And
> this is your project now! :)
>
But that will need a lot of editing of the other files to
make them
consistent. This 4 level of indentation is also readable.
> BTW: Are you done with the checking in for the moment?
Yes. I'll let you freeze the code for 0.4.28. For the 0.4.29
release
I am planning to complete the requirements of EventSemaphore
which are
still unimplemented.
Also, I'd like to ask you a question. How does a Guard work?
Is it possible
to release a Guard and the lock it again in the middle of a
function before
the function exits? I will need to protect some operations
to data members of
EventSemaphore.
>
> >
> > >
> > > >
> > > > My questions:
> > > > Point #1 and #2 were clearly understood.
> > > > Point #3 is a bit unclear: when you mentioned "4-level deep", which
> > > > column is the reference column? I assume it is 4-level deep relative
> > > > to the "class" keyword.
> > > >
> > > > Is the following correctly indented according to the above 'guidelines'?
> > > > (leading blanks were replaced with = or -)
> > > >
> > > > namespace corelinux {
> > > >
> > > > ===class MyClass {
> > > > ===---===---===/**
> > > > ===---===---===---constructors have no return type.
> > > > ===---===---===---I assume the return type is "empty string"
> > > > ===---===---===*/
> > > > ===---===---===MyClass( params );
> > > >
> > > > ===---===---===/// comment for virtual MethodA
> > > > ===---virtual ReturnType MethodA( signature ... );
> > > >
> > > > ===---===---===/// comment for methodB
> > > > ===---===---===void MethodB ( signature ... );
> > > > ===};
> > > > }
> > > >
> > > > I think we should add this "guideline" to the C++ Coding standard.
> > > >
> > > > --
> > > > Hans Dulimarta, Ph.D. dul...@co...
> > > > P: 517-432-7589 http://www.egr.msu.edu/~dulimart
> > > > F: 760-281-7691 http://corelinux.sourceforge.net
> > > > Elec. & Comp. Engg., Mich. State Univ., E. Lansing, MI 48824
> > > > _______________________________________________
> > > > Corelinux-develop mailing list
> > > > Cor...@li...
> > > > http://lists.sourceforge.net/mailman/listinfo/corelinux-develop
> > >
> > > --
> > > Frank V. Castellucci
> > > _______________________________________________
> > > Corelinux-develop mailing list
> > > Cor...@li...
> > > http://lists.sourceforge.net/mailman/listinfo/corelinux-develop
> >
> > --
> > Hans Dulimarta, Ph.D. dul...@co...
> > P: 517-432-7589
> > http://www.egr.msu.edu/~dulimart
> > F: 760-281-7691 http://corelinux.sourceforge.net
> > Elec. & Comp. Engg., Mich. State Univ., E. Lansing, MI 48824
> > _______________________________________________
> > Corelinux-develop mailing list
> > Cor...@li...
> > http://lists.sourceforge.net/mailman/listinfo/corelinux-develop
>
> --
> Frank V. Castellucci
> http://corelinux.sourceforge.net
> OOA/OOD/C++ Standards and Guidelines for Linux
> http://PythPat.sourceforge.net
> Pythons Pattern Package
> _______________________________________________
> Corelinux-develop mailing list
> Cor...@li...
> http://lists.sourceforge.net/mailman/listinfo/corelinux-develop
--
Hans Dulimarta, Ph.D. dul...@co...
P: 517-432-7589
http://www.egr.msu.edu/~dulimart
F: 760-281-7691 http://corelinux.sourceforge.net
Elec. & Comp. Engg., Mich. State Univ., E. Lansing, MI 48824
|
|
From: Frank V. C. <fr...@co...> - 2000-09-23 21:09:43
|
Hans Dulimarta wrote:
>
> "Frank V. Castellucci" wrote:
> >
> > Hans Dulimarta wrote:
> > >
> > > "Frank V. Castellucci" wrote:
> > > >
> > > > What I meant by #3 can be summarized in the header file
> > > > MutexSemaphoreGroup.hpp, so in answer to your graphic depiction, yes it
> > > > is correct with the exception of the class MyClass opening brace (which
> > > > should line up with 'class' on the next line.
> > > >
> > > > Now, this has mostly been my organization and alignment which for me is
> > > > readable. How do you feel about it?
> > >
> > > Personally, I prefer the comments flushed left with any
> > > modifiers, which means
> > > that 4 level indentation does not apply. But, I guess for
> > > this project I have
> > > to decline my own preferences.
> >
> > I guess the goal/objective is that whatever the standard is, that the
> > code be consistent. So if we started with flushing left the comments
> > with the modifiers, as long as we stuck to it, would have been ok. And
> > this is your project now! :)
> >
>
> But that will need a lot of editing of the other files to
> make them
> consistent. This 4 level of indentation is also readable.
>
> > BTW: Are you done with the checking in for the moment?
>
> Yes. I'll let you freeze the code for 0.4.28. For the 0.4.29
> release
> I am planning to complete the requirements of EventSemaphore
> which are
> still unimplemented.
Cool.
>
> Also, I'd like to ask you a question. How does a Guard work?
> Is it possible
> to release a Guard and the lock it again in the middle of a
> function before
> the function exits? I will need to protect some operations
> to data members of
> EventSemaphore.
You can get a Guard from the Synchronized instance, and then release it
once, and only once.
You can then get another Guard for later on in the function but be
careful about deadlocks.
>
> >
> > >
> > > >
> > > > >
> > > > > My questions:
> > > > > Point #1 and #2 were clearly understood.
> > > > > Point #3 is a bit unclear: when you mentioned "4-level deep", which
> > > > > column is the reference column? I assume it is 4-level deep relative
> > > > > to the "class" keyword.
> > > > >
> > > > > Is the following correctly indented according to the above 'guidelines'?
> > > > > (leading blanks were replaced with = or -)
> > > > >
> > > > > namespace corelinux {
> > > > >
> > > > > ===class MyClass {
> > > > > ===---===---===/**
> > > > > ===---===---===---constructors have no return type.
> > > > > ===---===---===---I assume the return type is "empty string"
> > > > > ===---===---===*/
> > > > > ===---===---===MyClass( params );
> > > > >
> > > > > ===---===---===/// comment for virtual MethodA
> > > > > ===---virtual ReturnType MethodA( signature ... );
> > > > >
> > > > > ===---===---===/// comment for methodB
> > > > > ===---===---===void MethodB ( signature ... );
> > > > > ===};
> > > > > }
> > > > >
> > > > > I think we should add this "guideline" to the C++ Coding standard.
> > > > >
> > > > > --
> > > > > Hans Dulimarta, Ph.D. dul...@co...
> > > > > P: 517-432-7589 http://www.egr.msu.edu/~dulimart
> > > > > F: 760-281-7691 http://corelinux.sourceforge.net
> > > > > Elec. & Comp. Engg., Mich. State Univ., E. Lansing, MI 48824
> > > > > _______________________________________________
> > > > > Corelinux-develop mailing list
> > > > > Cor...@li...
> > > > > http://lists.sourceforge.net/mailman/listinfo/corelinux-develop
> > > >
> > > > --
> > > > Frank V. Castellucci
> > > > _______________________________________________
> > > > Corelinux-develop mailing list
> > > > Cor...@li...
> > > > http://lists.sourceforge.net/mailman/listinfo/corelinux-develop
> > >
> > > --
> > > Hans Dulimarta, Ph.D. dul...@co...
> > > P: 517-432-7589
> > > http://www.egr.msu.edu/~dulimart
> > > F: 760-281-7691 http://corelinux.sourceforge.net
> > > Elec. & Comp. Engg., Mich. State Univ., E. Lansing, MI 48824
> > > _______________________________________________
> > > Corelinux-develop mailing list
> > > Cor...@li...
> > > http://lists.sourceforge.net/mailman/listinfo/corelinux-develop
> >
> > --
> > Frank V. Castellucci
> > http://corelinux.sourceforge.net
> > OOA/OOD/C++ Standards and Guidelines for Linux
> > http://PythPat.sourceforge.net
> > Pythons Pattern Package
> > _______________________________________________
> > Corelinux-develop mailing list
> > Cor...@li...
> > http://lists.sourceforge.net/mailman/listinfo/corelinux-develop
>
> --
> Hans Dulimarta, Ph.D. dul...@co...
> P: 517-432-7589
> http://www.egr.msu.edu/~dulimart
> F: 760-281-7691 http://corelinux.sourceforge.net
> Elec. & Comp. Engg., Mich. State Univ., E. Lansing, MI 48824
> _______________________________________________
> Corelinux-develop mailing list
> Cor...@li...
> http://lists.sourceforge.net/mailman/listinfo/corelinux-develop
--
Frank V. Castellucci
http://corelinux.sourceforge.net
OOA/OOD/C++ Standards and Guidelines for Linux
http://PythPat.sourceforge.net
Pythons Pattern Package
|
