Re: asl-users: Re: [Adobe-source-devel] Code formatting

[Tony V. E. <to...@ad...>]

I've found that a workable rule for tabs is to only allow tabs at the 
beginning of a line.  ie ONLY for indentation.  ie NOT for aligning 
#defines, etc.

Thus, it doesn't matter what tab setting you use, the indents still work.

If you convert your tabs to spaces, then the spaces have effectively 
*forced* a tab/indent size upon everyone.  I think that is worse.


If everyone followed my rule, we'd all be happy.  :-)  I say that only 
half in jest.  ie you could say that (in jest) about almost any rule, 
but in the tab-for-indent-only case, everyone ***still gets whatever 
indent size they like***.  None of the other rules (fixed tab size or 
fixed # of spaces) leaves everyone with their indent preference in tack.

Tony Van Eerd
Adobe Waterloo
-via Thunderbird-

Sean Parent wrote:
> I'm also sending this to the internal Adobe list (so for Adobe folks  - 
> there are external people on this list).
> 
> The tabs (with a width of 4) is a _long_ time Adobe standard but  trying 
> several editors it doesn't bother me either way though  generally I 
> prefer the notion of tabs over spaces.
> 
> If detab-ed is the general consensus then we can convert (probably  for 
> the next release - we should do it in one swoop).
> 
> For if statements - I'm fine with code either way - I tend to write  
> single line and just set the break point in the assembly view if I  need 
> to break after the conditional (or loop or whatever). I'll try  to 
> remember to split mine up - but since that isn't just an editor  setting 
> I'm sure it will take awhile to train my fingers.
> 
> Sean
> 
> On Jan 19, 2006, at 2:51 PM, Thomas Witt wrote:
> 
>>
>> Hi,
>>
>> The good news:
>>     I am not going to talk about curly braces.
>>
>> The bad news:
>>     I am still going to talk about code formatting.
>>
>>
>> The following issues are things that make my life hard when dealing  
>> with asl code. I bring these up because I think that there is at  
>> least a chance that the potential benefits from doing it the way it  
>> is done now don't outweigh the burden it puts on me and potentially  
>> others working with the code.
>>
>> Tabs-vs-spaces:
>>
>> ASL code currently uses TAB's for indentation. While they might  work 
>> well when working only on a single project. They are a pain if  you 
>> work on multiple projects with different conventions at the  same 
>> time. It is so much easier to check whether your indentation  level is 
>> correct than it is to check whether you used the right  indentation 
>> character. I tried to do this for my asl work and I am  getting it 
>> wrong time and again. Other opensource projects (eg.  boost) have 
>> settled on spaces just because they are less brittle in  a multiple 
>> contributors scenario.
>>
>> if statements:
>>
>> Recently I came across a lot of one-line if statements like
>>
>> if (in_good_mood) do_good();
>>
>> there are readability arguments about code like this but this is  not 
>> my issue with that. My problem is that they don't allow me to  easily 
>> set breakpoints for the true case in Visual Studio. You can  only do 
>> that when do_good() is on its own line. And yes I hate to  format my 
>> code according to tool limitation but in the end tool  limitations are 
>> a fact of life and we need to get a job done.
>>
>> Curly braces:
>>
>> Just kidding ;-)
>>
>>
>> Thanks for bearing with me. Comments?
>>
>> Thomas
>>
>> -- 
>> Thomas Witt
>> wi...@ac...
>>
>>
>> -------------------------------------------------------
>> This SF.net email is sponsored by: Splunk Inc. Do you grep through  
>> log files
>> for problems?  Stop!  Download the new AJAX search engine that makes
>> searching your log files as easy as surfing the  web.  DOWNLOAD  SPLUNK!
>> http://sel.as-us.falkag.net/sel? cmd=lnk&kid=103432&bid=230486&dat=121642
>> _______________________________________________
>> Adobe-source-devel mailing list
>> Ado...@li...
>> https://lists.sourceforge.net/lists/listinfo/adobe-source-devel
> 
> 
>