Menu
▾
▴
Re: asl-users: Re: [Adobe-source-devel] Code formatting
|
From: Tony V. E. <to...@ad...> - 2006-01-20 00:26:39
|
Yeah, I wish there was an editor which handled this. I hold down space bar. Even in the mixed case, I do <tab><space><space>....column2. If there was a shortcut key to toggle 'turn tabs into spaces' on and off, then it might not be so bad. ie turn it on when aligning stuff, shut it back off when 'coding'. Actually, I suspect I could do this one way or the other in MSVC at least. hmmm.... Tony Van Eerd Adobe Waterloo -via Thunderbird- Sean Parent wrote: > Unfortunately none of my editors have such a mode (and I'm not going to > manually align items by holding down the space bar the right number of > times) it also fails in the mixed case: > > <tab>column1<spaces>column2 > <tab> <tab> column2 > > Sean > > On Jan 19, 2006, at 3:51 PM, Tony Van Eerd wrote: > >> 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 > > > |
