Thanks for your correction about CR being OS 9 line endings not OS 10.

There probably is some tool we can run in the build to fix line endings.

About spaces and tabs, I simply wasn't aware that most Csound sources use spaces. The only real problem is in SConstruct. Python editors normally use tabs. I don't know what to suggest in this case.

Some projects run all sources through a source code reformatter as part of build or checkin.

Regards,
Mike

 

-----Original Message-----
>From: Anthony Kozar 
>Sent: Feb 18, 2008 1:16 AM
>To: Developer discussions 
>Subject: Re: [Cs-dev] Source code formatting problems
>
>First, I am sorry that MSVC is so stupid about line endings -- I remember
>struggling with it in school (editing on a Mac at home and MSVC at
>school).  Personally I feel that any compiler or command-line tool worth
>its salt should be completely ambivalent about line endings.
>
>Second, OS X line endings are Unix line endings for the vast majority of
>software now (AFAIK).   MacOS 9 uses CRs by convention but OS X uses LFs. 
>So, if there are bare \r's creeping in, it might be my fault.  But, my CVS
>client is supposed to handle that transparently -- I get CRs on check out
>and they should be LFs on check in.  I have no idea how to verify that
>this is happening though.  I suppose if it is a probem that I can turn off
>line ending translation and MY editor/compiler will not care!
>
>Regarding tabs, I thought we had a policy of no tabs in C/C++ source for
>Csound (not sure about SConstruct ...).  I try hard to remember but I am
>sure that I sometimes forget.
>
>Finally, I completely agree with Eric -- none of the editors that I use
>for code display  LFs differently than CRs, so it is very difficult to
>check.  My IDE's editor also cannot display tabs.
>
>Anthony
>
>On Sun, February 17, 2008 4:06 pm, victor wrote:
>> As far as I can see I am using unix line endings (as I always
>> use emacs on OSX), but something could have got in
>> between. I'll do my best to keep to it, apologies if
>> I unadvertdly do not.
>>
>> But the tabs thing seems to be more of a problem.
>>
>> Victor
>> ----- Original Message -----
>> From: "Michael Gogins" 
>> To: "Csound Developers" 
>> Sent: Sunday, February 17, 2008 7:42 PM
>> Subject: [Cs-dev] Source code formatting problems
>>
>>
>>> In the course of putting together an MSVC build for Csound I have
>encountered inconsistent tabs/spaces in SConstruct and other files,
>inconsistent Windows/OS X/Unix line endings, and so on.
>>> Please, can we agree on the following standards for source code
>editing?
>>> -- All line endings should be Unix line endings (one linefeed, no carriage
>>> return).
>>> -- When you inspect whitespace in a source file, you should always see
>1
>>> tab character every 4 spaces, never any blocks of spaces. (Actually it can
>>> be every 8 spaces, but it is important to use tabs not spaces for
>indenting.)
>>> A number of things broke in my build and John ffitch's build related to
>these issues: SConstruct failed due to mixture of tabs and spaces for
>Python indenting, and a number of files had OS X line endings and would
>not build with MSVC at all until I reformatted them.
>>> It is important to be consistent in a cross-platform project, and
>Posix/GNU is a reasonable standard.
>>> Please let us know if there are questions or objections.
>>> Regards,
>>> Mike
>
>
>
>-------------------------------------------------------------------------
>This SF.net email is sponsored by: Microsoft
>Defy all challenges. Microsoft(R) Visual Studio 2008.
>http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
>_______________________________________________
>Csound-devel mailing list
>Csound-devel@lists.sourceforge.net
>https://lists.sourceforge.net/lists/listinfo/csound-devel




-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

AFAIK, Python doesn't care whether you use tabs or spaces, as long as 
they are used consistently within a file.

Every place I've ever worked at has specifically directed developers to 
use spaces instead of tabs in their source code.  Because different 
coders use different editor settings for tab display, using spaces 
consistently is the only way to make code look the same in all editors.

- Dave

Steven Yi wrote:
> Hi Michael,
> 
> I've actually found most Python code to use 4 spaces as indentation
> and no use of tabs.  (Idle uses 4 spaces, for example). I found this
> style guide that recommends 4 spaces as well:
> 
> http://www.python.org/doc/essays/styleguide.html
> 
> steven
> 
> On Feb 18, 2008 5:18 AM, Michael Gogins  wrote:
>> Thanks for your correction about CR being OS 9 line endings not OS 10.
>>
>> There probably is some tool we can run in the build to fix line endings.
>>
>> About spaces and tabs, I simply wasn't aware that most Csound sources use spaces. The only real problem is in SConstruct. Python editors normally use tabs. I don't know what to suggest in this case.
>>
>> Some projects run all sources through a source code reformatter as part of build or checkin.
>>
>> Regards,
>> Mike
>>
>>
>>
>>
>> -----Original Message-----
>>> From: Anthony Kozar 
>>> Sent: Feb 18, 2008 1:16 AM
>>> To: Developer discussions 
>>> Subject: Re: [Cs-dev] Source code formatting problems
>>>
>>> First, I am sorry that MSVC is so stupid about line endings -- I remember
>>> struggling with it in school (editing on a Mac at home and MSVC at
>>> school).  Personally I feel that any compiler or command-line tool worth
>>> its salt should be completely ambivalent about line endings.
>>>
>>> Second, OS X line endings are Unix line endings for the vast majority of
>>> software now (AFAIK).   MacOS 9 uses CRs by convention but OS X uses LFs.
>>> So, if there are bare \r's creeping in, it might be my fault.  But, my CVS
>>> client is supposed to handle that transparently -- I get CRs on check out
>>> and they should be LFs on check in.  I have no idea how to verify that
>>> this is happening though.  I suppose if it is a probem that I can turn off
>>> line ending translation and MY editor/compiler will not care!
>>>
>>> Regarding tabs, I thought we had a policy of no tabs in C/C++ source for
>>> Csound (not sure about SConstruct ...).  I try hard to remember but I am
>>> sure that I sometimes forget.
>>>
>>> Finally, I completely agree with Eric -- none of the editors that I use
>>> for code display  LFs differently than CRs, so it is very difficult to
>>> check.  My IDE's editor also cannot display tabs.
>>>
>>> Anthony
>>>
>>> On Sun, February 17, 2008 4:06 pm, victor wrote:
>>>> As far as I can see I am using unix line endings (as I always
>>>> use emacs on OSX), but something could have got in
>>>> between. I'll do my best to keep to it, apologies if
>>>> I unadvertdly do not.
>>>>
>>>> But the tabs thing seems to be more of a problem.
>>>>
>>>> Victor
>>>> ----- Original Message -----
>>>> From: "Michael Gogins" 
>>>> To: "Csound Developers" 
>>>> Sent: Sunday, February 17, 2008 7:42 PM
>>>> Subject: [Cs-dev] Source code formatting problems
>>>>
>>>>
>>>>> In the course of putting together an MSVC build for Csound I have
>>> encountered inconsistent tabs/spaces in SConstruct and other files,
>>> inconsistent Windows/OS X/Unix line endings, and so on.
>>>>> Please, can we agree on the following standards for source code
>>> editing?
>>>>> -- All line endings should be Unix line endings (one linefeed, no carriage
>>>>> return).
>>>>> -- When you inspect whitespace in a source file, you should always see
>>> 1
>>>>> tab character every 4 spaces, never any blocks of spaces. (Actually it can
>>>>> be every 8 spaces, but it is important to use tabs not spaces for
>>> indenting.)
>>>>> A number of things broke in my build and John ffitch's build related to
>>> these issues: SConstruct failed due to mixture of tabs and spaces for
>>> Python indenting, and a number of files had OS X line endings and would
>>> not build with MSVC at all until I reformatted them.
>>>>> It is important to be consistent in a cross-platform project, and
>>> Posix/GNU is a reasonable standard.
>>>>> Please let us know if there are questions or objections.
>>>>> Regards,
>>>>> Mike
>>>
>>>
>>> -------------------------------------------------------------------------
>>> This SF.net email is sponsored by: Microsoft
>>> Defy all challenges. Microsoft(R) Visual Studio 2008.
>>> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
>>> _______________________________________________
>>> Csound-devel mailing list
>>> Csound-devel@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>
>>
>>
>> -------------------------------------------------------------------------
>> This SF.net email is sponsored by: Microsoft
>> Defy all challenges. Microsoft(R) Visual Studio 2008.
>> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
>> _______________________________________________
>> Csound-devel mailing list
>> Csound-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>
> 
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2008.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel
> 
> 


-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net