Re: [Adobe-source-devel] Code formatting

[Sean P. <sp...@ad...>]

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