Letter sized oaper?  Why not international standard like A4?

> Attached: Coding Standards for Csound.html
> Sent using Google Docs http://docs.google.com/
>
> Here are my proposed coding standards. They probably go way too far for
> most of us, but this is what the people who write the software that you
> trust your life to do.
>
> I think it is interesting that there is no apparent conflict between
> correctness and speed. In fact in my experience if you write code just to
> be correct, it usually is about as fast as it can be. I think if by some
> miracle all of Csound were re-written to this admittedly extreme standard,
> it would actually run faster.
>
> Comments are of course invited.
>
> Best,
> Mike
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats.
> http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/_______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel
>



------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

On Tue, May 8, 2012 at 9:20 PM, Michael Gogins (Google Docs)
 wrote:
>
> Attached: Coding Standards for Csound
> Message from michael.gogins@gmail.com:
>
> Here are my proposed coding standards. They probably go way too far for
> most of us, but this is what the people who write the software that you
> trust your life to do.
>
> I think it is interesting that there is no apparent conflict between
> correctness and speed. In fact in my experience if you write code just to be
> correct, it usually is about as fast as it can be. I think if by some
> miracle all of Csound were re-written to this admittedly extreme standard,
> it would actually run faster.
>
> Comments are of course invited.

I'm still going through it, but these two statements raised an alarm for me:

* C++ header files should define as many function bodies within class
declarations as possible. The reasons for this are both readability
and higher performance.
* As much code as possible should be defined as inline. This can
easily be done in C++ by defining functions in header files.

These two are very dangerous when applied to the public API part of a
library. Reasons:

1. Bug fixes need recompilation of user programs.
2. If the library is updated but the program not recompiled, internal
ABI can be broken (that is, if an internal call was changed
incompatibly and an inlined function called it, it will cause
crashes).
3. Issue n°2 effectively restricts inline functions to using public
API functions.

If I could make an addition, I would say: public API C++ classes *must
not* define any functions in the header files (except perhaps trivial
functions). The library *must* be self contained - ie, it must not
depend on the user program to provide some functionality (this would
be broken by inline functions).


--

Saludos,
Felipe Sateler

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net
https://lists.sourceforge.net/lis

On Wed, May 9, 2012 at 10:45 AM,   wrote:
> Letter sized oaper?  Why not international standard like A4?

Also, at what font size? Does anyone still read printed code? Seems
like a waste to not be able to use the available screen real estate.
Moreover, descriptive variable and function names always ends up
clashing with the 80-column rule (or its variants).

-- 

Saludos,
Felipe Sateler

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/csound-

On 09/05/2012 15:52, Felipe Sateler wrote:
> On Wed, May 9, 2012 at 10:45 AM,  wrote:
>> Letter sized oaper?  Why not international standard like A4?
>
> Also, at what font size? Does anyone still read printed code? Seems
> like a waste to not be able to use the available screen real estate.
> Moreover, descriptive variable and function names always ends up
> clashing with the 80-column rule (or its variants).
>

And especially these days when just about everyone has wide-screen style 
displays, rather than the old 5:4 ratio screens, we have far more width 
available then depth. Any standard that does not recognise such changes 
is somewhat out of date. Even DOS console windows can be resized these days.

Richard Dobson



------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

On 09/05/2012 15:49, Felipe Sateler wrote:
..
>
> I'm still going through it, but these two statements raised an alarm for me:
>
> * C++ header files should define as many function bodies within class
> declarations as possible. The reasons for this are both readability
> and higher performance.
> * As much code as possible should be defined as inline. This can
> easily be done in C++ by defining functions in header files.
>
> These two are very dangerous when applied to the public API part of a
> library. Reasons:
>
> 1. Bug fixes need recompilation of user programs.
> 2. If the library is updated but the program not recompiled, internal
> ABI can be broken (that is, if an internal call was changed
> incompatibly and an inlined function called it, it will cause
> crashes).
> 3. Issue n°2 effectively restricts inline functions to using public
> API functions.
>
> If I could make an addition, I would say: public API C++ classes *must
> not* define any functions in the header files (except perhaps trivial
> functions). The library *must* be self contained - ie, it must not
> depend on the user program to provide some functionality (this would
> be broken by inline functions).
>

+1.   And the "higher performance" is more in hope than expectation. 
There is no guarantee that the compiler will inline everything (and more 
than a few subtle reasons why it won't or even can't). Even 
"forceinline" is something of a misnomer.

Richard Dobson

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net
https://lists.sourceforge.net

On Wed, May 9, 2012 at 11:13 AM, Richard Dobson
 wrote:
> On 09/05/2012 15:49, Felipe Sateler wrote:
> ..
>>
>> I'm still going through it, but these two statements raised an alarm for me:
>>
>> * C++ header files should define as many function bodies within class
>> declarations as possible. The reasons for this are both readability
>> and higher performance.
>> * As much code as possible should be defined as inline. This can
>> easily be done in C++ by defining functions in header files.
>>
>> These two are very dangerous when applied to the public API part of a
>> library. Reasons:
>>
>> 1. Bug fixes need recompilation of user programs.
>> 2. If the library is updated but the program not recompiled, internal
>> ABI can be broken (that is, if an internal call was changed
>> incompatibly and an inlined function called it, it will cause
>> crashes).
>> 3. Issue n°2 effectively restricts inline functions to using public
>> API functions.
>>
>> If I could make an addition, I would say: public API C++ classes *must
>> not* define any functions in the header files (except perhaps trivial
>> functions). The library *must* be self contained - ie, it must not
>> depend on the user program to provide some functionality (this would
>> be broken by inline functions).
>>
>
> +1.   And the "higher performance" is more in hope than expectation.
> There is no guarantee that the compiler will inline everything (and more
> than a few subtle reasons why it won't or even can't). Even
> "forceinline" is something of a misnomer.

And even when it inlines, there is no guarantee of improved
performance. Increased code size can cause thrashing, specially when
the function is used a lot.

-- 

Saludos,
Felipe Sateler

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net
https://lists.sou

On Wed, May 9, 2012 at 11:03 AM, Richard Dobson
 wrote:
> On 09/05/2012 15:52, Felipe Sateler wrote:
>> On Wed, May 9, 2012 at 10:45 AM,  wrote:
>>> Letter sized oaper?  Why not international standard like A4?
>>
>> Also, at what font size? Does anyone still read printed code? Seems
>> like a waste to not be able to use the available screen real estate.
>> Moreover, descriptive variable and function names always ends up
>> clashing with the 80-column rule (or its variants).
>>
>
> And especially these days when just about everyone has wide-screen style
> displays, rather than the old 5:4 ratio screens, we have far more width
> available then depth. Any standard that does not recognise such changes
> is somewhat out of date. Even DOS console windows can be resized these days.

+1  Who prints code on paper?  =)

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

May I disagree?  My laptop does not really allow more than 80 characters
wide and on my desktps I never go wider than 85 characters.  I need the
screen scape for other stuff.  All C code in Csound fits in my screen. (no
idea on C++ which i usually ignore).  Wide pages are not efficient to
read, with the problems of left-right alignment, as is well known in
books.

And while we are at it -- no tabs as different systems interpret them
differently.

I would also say no to doxygen which in my experience is totally useless

> On 09/05/2012 15:52, Felipe Sateler wrote:
>> On Wed, May 9, 2012 at 10:45 AM,  wrote:
>>> Letter sized oaper?  Why not international standard like A4?
>>
>> Also, at what font size? Does anyone still read printed code? Seems
>> like a waste to not be able to use the available screen real estate.
>> Moreover, descriptive variable and function names always ends up
>> clashing with the 80-column rule (or its variants).
>>
>
> And especially these days when just about everyone has wide-screen style
> displays, rather than the old 5:4 ratio screens, we have far more width
> available then depth. Any standard that does not recognise such changes
> is somewhat out of date. Even DOS console windows can be resized these
> days.
>
> Richard Dobson
>
>
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel
>
>
>









------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

What I say about inlining is based on positive personal experience as
well as on recommended practice. I have typically seen speedups of 15%
with maximum inlining versus none.

Regards,
Mike

On Wed, May 9, 2012 at 11:13 AM, Richard Dobson
 wrote:
> On 09/05/2012 15:49, Felipe Sateler wrote:
> ..
>>
>> I'm still going through it, but these two statements raised an alarm for me:
>>
>> * C++ header files should define as many function bodies within class
>> declarations as possible. The reasons for this are both readability
>> and higher performance.
>> * As much code as possible should be defined as inline. This can
>> easily be done in C++ by defining functions in header files.
>>
>> These two are very dangerous when applied to the public API part of a
>> library. Reasons:
>>
>> 1. Bug fixes need recompilation of user programs.
>> 2. If the library is updated but the program not recompiled, internal
>> ABI can be broken (that is, if an internal call was changed
>> incompatibly and an inlined function called it, it will cause
>> crashes).
>> 3. Issue n°2 effectively restricts inline functions to using public
>> API functions.
>>
>> If I could make an addition, I would say: public API C++ classes *must
>> not* define any functions in the header files (except perhaps trivial
>> functions). The library *must* be self contained - ie, it must not
>> depend on the user program to provide some functionality (this would
>> be broken by inline functions).
>>
>
> +1.   And the "higher performance" is more in hope than expectation.
> There is no guarantee that the compiler will inline everything (and more
> than a few subtle reasons why it won't or even can't). Even
> "forceinline" is something of a misnomer.
>
> Richard Dobson
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel



-- 
Michael Gogins
Irreducible Productions
http://www.michael-gogins.com
Michael dot Gogins at gmail dot com

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

Fine, we can say function must be defined within one visible page,
whatever that means, whether printout or screen.

Regards,
Mike

On Wed, May 9, 2012 at 11:03 AM, Richard Dobson
 wrote:
> On 09/05/2012 15:52, Felipe Sateler wrote:
>> On Wed, May 9, 2012 at 10:45 AM,  wrote:
>>> Letter sized oaper?  Why not international standard like A4?
>>
>> Also, at what font size? Does anyone still read printed code? Seems
>> like a waste to not be able to use the available screen real estate.
>> Moreover, descriptive variable and function names always ends up
>> clashing with the 80-column rule (or its variants).
>>
>
> And especially these days when just about everyone has wide-screen style
> displays, rather than the old 5:4 ratio screens, we have far more width
> available then depth. Any standard that does not recognise such changes
> is somewhat out of date. Even DOS console windows can be resized these days.
>
> Richard Dobson
>
>
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel



-- 
Michael Gogins
Irreducible Productions
http://www.michael-gogins.com
Michael dot Gogins at gmail dot com

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

I agree with you about public C++. It should all be pure abstract
classes. The implementations should do as I suggest however.

Regards,
Mike

On Wed, May 9, 2012 at 11:13 AM, Richard Dobson
 wrote:
> On 09/05/2012 15:49, Felipe Sateler wrote:
> ..
>>
>> I'm still going through it, but these two statements raised an alarm for me:
>>
>> * C++ header files should define as many function bodies within class
>> declarations as possible. The reasons for this are both readability
>> and higher performance.
>> * As much code as possible should be defined as inline. This can
>> easily be done in C++ by defining functions in header files.
>>
>> These two are very dangerous when applied to the public API part of a
>> library. Reasons:
>>
>> 1. Bug fixes need recompilation of user programs.
>> 2. If the library is updated but the program not recompiled, internal
>> ABI can be broken (that is, if an internal call was changed
>> incompatibly and an inlined function called it, it will cause
>> crashes).
>> 3. Issue n°2 effectively restricts inline functions to using public
>> API functions.
>>
>> If I could make an addition, I would say: public API C++ classes *must
>> not* define any functions in the header files (except perhaps trivial
>> functions). The library *must* be self contained - ie, it must not
>> depend on the user program to provide some functionality (this would
>> be broken by inline functions).
>>
>
> +1.   And the "higher performance" is more in hope than expectation.
> There is no guarantee that the compiler will inline everything (and more
> than a few subtle reasons why it won't or even can't). Even
> "forceinline" is something of a misnomer.
>
> Richard Dobson
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel



-- 
Michael Gogins
Irreducible Productions
http://www.michael-gogins.com
Michael dot Gogins at gmail dot com

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

No tabs, I agree.

You may find doxygen useless, but I use it all the time for Csound.

Regards,
Mike

On Wed, May 9, 2012 at 11:38 AM,   wrote:
> May I disagree?  My laptop does not really allow more than 80 characters
> wide and on my desktps I never go wider than 85 characters.  I need the
> screen scape for other stuff.  All C code in Csound fits in my screen. (no
> idea on C++ which i usually ignore).  Wide pages are not efficient to
> read, with the problems of left-right alignment, as is well known in
> books.
>
> And while we are at it -- no tabs as different systems interpret them
> differently.
>
> I would also say no to doxygen which in my experience is totally useless
>
>> On 09/05/2012 15:52, Felipe Sateler wrote:
>>> On Wed, May 9, 2012 at 10:45 AM,  wrote:
>>>> Letter sized oaper?  Why not international standard like A4?
>>>
>>> Also, at what font size? Does anyone still read printed code? Seems
>>> like a waste to not be able to use the available screen real estate.
>>> Moreover, descriptive variable and function names always ends up
>>> clashing with the 80-column rule (or its variants).
>>>
>>
>> And especially these days when just about everyone has wide-screen style
>> displays, rather than the old 5:4 ratio screens, we have far more width
>> available then depth. Any standard that does not recognise such changes
>> is somewhat out of date. Even DOS console windows can be resized these
>> days.
>>
>> Richard Dobson
>>
>>
>>
>> ------------------------------------------------------------------------------
>> Live Security Virtual Conference
>> Exclusive live event will cover all the ways today's security and
>> threat landscape has changed and how IT managers can respond. Discussions
>> will include endpoint security, mobile security and the latest in malware
>> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>> _______________________________________________
>> Csound-devel mailing list
>> Csound-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>
>>
>>
>
>
>
>
>
>
>
>
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel



-- 
Michael Gogins
Irreducible Productions
http://www.michael-gogins.com
Michael dot Gogins at gmail dot com

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

I like 80 characters per line personally, but I also like using big
fonts these days, and my main monitor is 13" on my Macbook, so not a
gigantic monitor.

I think using Doxygen is great for the public API.  Otherwise, I think
comments should be judiciously used, where a function name or member
variable name isn't enough to understand its intended usage.  I guess
it's a matter of documenting with the intended audience of someone who
hasn't looked at the code before (i.e. I might not know what an OPARM
is, or an OPDS, just by its name).

steven

On Wed, May 9, 2012 at 11:43 AM, Michael Gogins
 wrote:
> No tabs, I agree.
>
> You may find doxygen useless, but I use it all the time for Csound.
>
> Regards,
> Mike
>
> On Wed, May 9, 2012 at 11:38 AM,   wrote:
>> May I disagree?  My laptop does not really allow more than 80 characters
>> wide and on my desktps I never go wider than 85 characters.  I need the
>> screen scape for other stuff.  All C code in Csound fits in my screen. (no
>> idea on C++ which i usually ignore).  Wide pages are not efficient to
>> read, with the problems of left-right alignment, as is well known in
>> books.
>>
>> And while we are at it -- no tabs as different systems interpret them
>> differently.
>>
>> I would also say no to doxygen which in my experience is totally useless
>>
>>> On 09/05/2012 15:52, Felipe Sateler wrote:
>>>> On Wed, May 9, 2012 at 10:45 AM,  wrote:
>>>>> Letter sized oaper?  Why not international standard like A4?
>>>>
>>>> Also, at what font size? Does anyone still read printed code? Seems
>>>> like a waste to not be able to use the available screen real estate.
>>>> Moreover, descriptive variable and function names always ends up
>>>> clashing with the 80-column rule (or its variants).
>>>>
>>>
>>> And especially these days when just about everyone has wide-screen style
>>> displays, rather than the old 5:4 ratio screens, we have far more width
>>> available then depth. Any standard that does not recognise such changes
>>> is somewhat out of date. Even DOS console windows can be resized these
>>> days.
>>>
>>> Richard Dobson
>>>
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> Live Security Virtual Conference
>>> Exclusive live event will cover all the ways today's security and
>>> threat landscape has changed and how IT managers can respond. Discussions
>>> will include endpoint security, mobile security and the latest in malware
>>> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>>> _______________________________________________
>>> Csound-devel mailing list
>>> Csound-devel@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>>
>>>
>>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> ------------------------------------------------------------------------------
>> Live Security Virtual Conference
>> Exclusive live event will cover all the ways today's security and
>> threat landscape has changed and how IT managers can respond. Discussions
>> will include endpoint security, mobile security and the latest in malware
>> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>> _______________________________________________
>> Csound-devel mailing list
>> Csound-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>
>
>
> --
> Michael Gogins
> Irreducible Productions
> http://www.michael-gogins.com
> Michael dot Gogins at gmail dot com
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

Michael, thanks for putting these together.

I have one concern.  The guideline "Tasks that can run in parallel,
should be enabled to run in parallel at the highest possible level of
granularity." might IMHO be using a rather broad brush.  The exact
decision of whether it makes sense to parallelize tasks is so heavily
context-dependent (performance, interaction with other subsystems,
size of work, increased code complexity, etc.) that this might lead
developers to spend time on parallelizing code with either minimal or
negative impact.

John L.

On Wed, May 9, 2012 at 5:00 PM, Steven Yi  wrote:
> I like 80 characters per line personally, but I also like using big
> fonts these days, and my main monitor is 13" on my Macbook, so not a
> gigantic monitor.
>
> I think using Doxygen is great for the public API.  Otherwise, I think
> comments should be judiciously used, where a function name or member
> variable name isn't enough to understand its intended usage.  I guess
> it's a matter of documenting with the intended audience of someone who
> hasn't looked at the code before (i.e. I might not know what an OPARM
> is, or an OPDS, just by its name).
>
> steven
>
> On Wed, May 9, 2012 at 11:43 AM, Michael Gogins
>  wrote:
>> No tabs, I agree.
>>
>> You may find doxygen useless, but I use it all the time for Csound.
>>
>> Regards,
>> Mike
>>
>> On Wed, May 9, 2012 at 11:38 AM,   wrote:
>>> May I disagree?  My laptop does not really allow more than 80 characters
>>> wide and on my desktps I never go wider than 85 characters.  I need the
>>> screen scape for other stuff.  All C code in Csound fits in my screen. (no
>>> idea on C++ which i usually ignore).  Wide pages are not efficient to
>>> read, with the problems of left-right alignment, as is well known in
>>> books.
>>>
>>> And while we are at it -- no tabs as different systems interpret them
>>> differently.
>>>
>>> I would also say no to doxygen which in my experience is totally useless
>>>
>>>> On 09/05/2012 15:52, Felipe Sateler wrote:
>>>>> On Wed, May 9, 2012 at 10:45 AM,  wrote:
>>>>>> Letter sized oaper?  Why not international standard like A4?
>>>>>
>>>>> Also, at what font size? Does anyone still read printed code? Seems
>>>>> like a waste to not be able to use the available screen real estate.
>>>>> Moreover, descriptive variable and function names always ends up
>>>>> clashing with the 80-column rule (or its variants).
>>>>>
>>>>
>>>> And especially these days when just about everyone has wide-screen style
>>>> displays, rather than the old 5:4 ratio screens, we have far more width
>>>> available then depth. Any standard that does not recognise such changes
>>>> is somewhat out of date. Even DOS console windows can be resized these
>>>> days.
>>>>
>>>> Richard Dobson
>>>>
>>>>
>>>>
>>>> ------------------------------------------------------------------------------
>>>> Live Security Virtual Conference
>>>> Exclusive live event will cover all the ways today's security and
>>>> threat landscape has changed and how IT managers can respond. Discussions
>>>> will include endpoint security, mobile security and the latest in malware
>>>> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>>>> _______________________________________________
>>>> Csound-devel mailing list
>>>> Csound-devel@lists.sourceforge.net
>>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>>>
>>>>
>>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> Live Security Virtual Conference
>>> Exclusive live event will cover all the ways today's security and
>>> threat landscape has changed and how IT managers can respond. Discussions
>>> will include endpoint security, mobile security and the latest in malware
>>> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>>> _______________________________________________
>>> Csound-devel mailing list
>>> Csound-devel@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>
>>
>>
>> --
>> Michael Gogins
>> Irreducible Productions
>> http://www.michael-gogins.com
>> Michael dot Gogins at gmail dot com
>>
>> ------------------------------------------------------------------------------
>> Live Security Virtual Conference
>> Exclusive live event will cover all the ways today's security and
>> threat landscape has changed and how IT managers can respond. Discussions
>> will include endpoint security, mobile security and the latest in malware
>> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>> _______________________________________________
>> Csound-devel mailing list
>> Csound-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

I agree, this should be qualified by costing or something.

Regards,
Mike

On Wed, May 9, 2012 at 3:04 PM, John Lato  wrote:
> Michael, thanks for putting these together.
>
> I have one concern.  The guideline "Tasks that can run in parallel,
> should be enabled to run in parallel at the highest possible level of
> granularity." might IMHO be using a rather broad brush.  The exact
> decision of whether it makes sense to parallelize tasks is so heavily
> context-dependent (performance, interaction with other subsystems,
> size of work, increased code complexity, etc.) that this might lead
> developers to spend time on parallelizing code with either minimal or
> negative impact.
>
> John L.
>
> On Wed, May 9, 2012 at 5:00 PM, Steven Yi  wrote:
>> I like 80 characters per line personally, but I also like using big
>> fonts these days, and my main monitor is 13" on my Macbook, so not a
>> gigantic monitor.
>>
>> I think using Doxygen is great for the public API.  Otherwise, I think
>> comments should be judiciously used, where a function name or member
>> variable name isn't enough to understand its intended usage.  I guess
>> it's a matter of documenting with the intended audience of someone who
>> hasn't looked at the code before (i.e. I might not know what an OPARM
>> is, or an OPDS, just by its name).
>>
>> steven
>>
>> On Wed, May 9, 2012 at 11:43 AM, Michael Gogins
>>  wrote:
>>> No tabs, I agree.
>>>
>>> You may find doxygen useless, but I use it all the time for Csound.
>>>
>>> Regards,
>>> Mike
>>>
>>> On Wed, May 9, 2012 at 11:38 AM,   wrote:
>>>> May I disagree?  My laptop does not really allow more than 80 characters
>>>> wide and on my desktps I never go wider than 85 characters.  I need the
>>>> screen scape for other stuff.  All C code in Csound fits in my screen. (no
>>>> idea on C++ which i usually ignore).  Wide pages are not efficient to
>>>> read, with the problems of left-right alignment, as is well known in
>>>> books.
>>>>
>>>> And while we are at it -- no tabs as different systems interpret them
>>>> differently.
>>>>
>>>> I would also say no to doxygen which in my experience is totally useless
>>>>
>>>>> On 09/05/2012 15:52, Felipe Sateler wrote:
>>>>>> On Wed, May 9, 2012 at 10:45 AM,  wrote:
>>>>>>> Letter sized oaper?  Why not international standard like A4?
>>>>>>
>>>>>> Also, at what font size? Does anyone still read printed code? Seems
>>>>>> like a waste to not be able to use the available screen real estate.
>>>>>> Moreover, descriptive variable and function names always ends up
>>>>>> clashing with the 80-column rule (or its variants).
>>>>>>
>>>>>
>>>>> And especially these days when just about everyone has wide-screen style
>>>>> displays, rather than the old 5:4 ratio screens, we have far more width
>>>>> available then depth. Any standard that does not recognise such changes
>>>>> is somewhat out of date. Even DOS console windows can be resized these
>>>>> days.
>>>>>
>>>>> Richard Dobson
>>>>>
>>>>>
>>>>>
>>>>> ------------------------------------------------------------------------------
>>>>> Live Security Virtual Conference
>>>>> Exclusive live event will cover all the ways today's security and
>>>>> threat landscape has changed and how IT managers can respond. Discussions
>>>>> will include endpoint security, mobile security and the latest in malware
>>>>> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>>>>> _______________________________________________
>>>>> Csound-devel mailing list
>>>>> Csound-devel@lists.sourceforge.net
>>>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> ------------------------------------------------------------------------------
>>>> Live Security Virtual Conference
>>>> Exclusive live event will cover all the ways today's security and
>>>> threat landscape has changed and how IT managers can respond. Discussions
>>>> will include endpoint security, mobile security and the latest in malware
>>>> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>>>> _______________________________________________
>>>> Csound-devel mailing list
>>>> Csound-devel@lists.sourceforge.net
>>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>>
>>>
>>>
>>> --
>>> Michael Gogins
>>> Irreducible Productions
>>> http://www.michael-gogins.com
>>> Michael dot Gogins at gmail dot com
>>>
>>> ------------------------------------------------------------------------------
>>> Live Security Virtual Conference
>>> Exclusive live event will cover all the ways today's security and
>>> threat landscape has changed and how IT managers can respond. Discussions
>>> will include endpoint security, mobile security and the latest in malware
>>> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>>> _______________________________________________
>>> Csound-devel mailing list
>>> Csound-devel@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>
>> ------------------------------------------------------------------------------
>> Live Security Virtual Conference
>> Exclusive live event will cover all the ways today's security and
>> threat landscape has changed and how IT managers can respond. Discussions
>> will include endpoint security, mobile security and the latest in malware
>> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>> _______________________________________________
>> Csound-devel mailing list
>> Csound-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel



-- 
Michael Gogins
Irreducible Productions
http://www.michael-gogins.com
Michael dot Gogins at gmail dot com

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

The whole point of these coding standards is that a name such as
OPARMS should never be used. The meanings of types should be obvious
to the uninitiated. Something like "PerformanceParameters" should be
enough. (What does "O" mean here, anyway?) If that isn't clear enough,
please suggest something that is. The amount of typing involved should
not be a factor, although names longer than 31 characters should not
be used.

One of the basic principles of coding to standards is to define things
as little possible. If you don't need to define it, don't define it.
If you do need to define it, define it in one and only one place.
Therefore, if you can define it just by naming a type, do that. If you
have to name a type and then comment it, that's two definitions for
the same thing. Invariably, in my experience, and evidently in the
experience of the critical systems programmers, some of these multiple
definitions drift apart, and then it's just not clear what's really
supposed to be happening.

This is also the real reason for using something like Doxygen -- if
you have to explain what a type does, do it in one and only one place.
Since we do have to do that sometimes in comments, then let us do it
only in comments.

Please note, as I said at the very top of the document, I'm NOT
proposing renaming everything in Csound. This proposal is for new
code.

Although, if everything were renamed as clearly as possible, we would
all probably learn a great deal...

Regards,
Mike

On Wed, May 9, 2012 at 12:00 PM, Steven Yi  wrote:
> I like 80 characters per line personally, but I also like using big
> fonts these days, and my main monitor is 13" on my Macbook, so not a
> gigantic monitor.
>
> I think using Doxygen is great for the public API.  Otherwise, I think
> comments should be judiciously used, where a function name or member
> variable name isn't enough to understand its intended usage.  I guess
> it's a matter of documenting with the intended audience of someone who
> hasn't looked at the code before (i.e. I might not know what an OPARM
> is, or an OPDS, just by its name).
>
> steven
>
> On Wed, May 9, 2012 at 11:43 AM, Michael Gogins
>  wrote:
>> No tabs, I agree.
>>
>> You may find doxygen useless, but I use it all the time for Csound.
>>
>> Regards,
>> Mike
>>
>> On Wed, May 9, 2012 at 11:38 AM,   wrote:
>>> May I disagree?  My laptop does not really allow more than 80 characters
>>> wide and on my desktps I never go wider than 85 characters.  I need the
>>> screen scape for other stuff.  All C code in Csound fits in my screen. (no
>>> idea on C++ which i usually ignore).  Wide pages are not efficient to
>>> read, with the problems of left-right alignment, as is well known in
>>> books.
>>>
>>> And while we are at it -- no tabs as different systems interpret them
>>> differently.
>>>
>>> I would also say no to doxygen which in my experience is totally useless
>>>
>>>> On 09/05/2012 15:52, Felipe Sateler wrote:
>>>>> On Wed, May 9, 2012 at 10:45 AM,  wrote:
>>>>>> Letter sized oaper?  Why not international standard like A4?
>>>>>
>>>>> Also, at what font size? Does anyone still read printed code? Seems
>>>>> like a waste to not be able to use the available screen real estate.
>>>>> Moreover, descriptive variable and function names always ends up
>>>>> clashing with the 80-column rule (or its variants).
>>>>>
>>>>
>>>> And especially these days when just about everyone has wide-screen style
>>>> displays, rather than the old 5:4 ratio screens, we have far more width
>>>> available then depth. Any standard that does not recognise such changes
>>>> is somewhat out of date. Even DOS console windows can be resized these
>>>> days.
>>>>
>>>> Richard Dobson
>>>>
>>>>
>>>>
>>>> ------------------------------------------------------------------------------
>>>> Live Security Virtual Conference
>>>> Exclusive live event will cover all the ways today's security and
>>>> threat landscape has changed and how IT managers can respond. Discussions
>>>> will include endpoint security, mobile security and the latest in malware
>>>> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>>>> _______________________________________________
>>>> Csound-devel mailing list
>>>> Csound-devel@lists.sourceforge.net
>>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>>>
>>>>
>>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> Live Security Virtual Conference
>>> Exclusive live event will cover all the ways today's security and
>>> threat landscape has changed and how IT managers can respond. Discussions
>>> will include endpoint security, mobile security and the latest in malware
>>> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>>> _______________________________________________
>>> Csound-devel mailing list
>>> Csound-devel@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>
>>
>>
>> --
>> Michael Gogins
>> Irreducible Productions
>> http://www.michael-gogins.com
>> Michael dot Gogins at gmail dot com
>>
>> ------------------------------------------------------------------------------
>> Live Security Virtual Conference
>> Exclusive live event will cover all the ways today's security and
>> threat landscape has changed and how IT managers can respond. Discussions
>> will include endpoint security, mobile security and the latest in malware
>> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>> _______________________________________________
>> Csound-devel mailing list
>> Csound-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel



-- 
Michael Gogins
Irreducible Productions
http://www.michael-gogins.com
Michael dot Gogins at gmail dot com

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net