Menu
▾
▴
adobe-source-devel
|
From: Thomas W. <wi...@ac...> - 2006-01-19 22:51:57
|
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... |
|
From: Sean P. <sp...@ad...> - 2006-01-19 23:32:26
|
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 |
|
From: Tony V. E. <to...@ad...> - 2006-01-19 23:57:53
|
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 > > > |
|
From: Sean P. <sp...@ad...> - 2006-01-20 00:02:50
|
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 |
|
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 > > > |
|
From: Thomas W. <wi...@ac...> - 2006-01-20 01:49:59
|
Tony, 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 agree ;-). Seriously the problem I was talking about is not so much the indentation level but consistency. While I certainly prefer to have the right (read my preferred) indent size I can basically live with any amount of indentation as long as it is consistent and that's where the catch is with tabs. Making sure that you always use tabs in the right way is hard (at least to me) if the right way differs on an hourly bases when switching projects. It is always easy to spot if you broke indentation by adding the wrong amount of spaces. If you add spaces instead of tabs (or the other way round) you might not notice but your poor colleague using a different tab size will. I guess my point is that it is easier to maintain consistency when using spaces only. It takes one probable cause of annoyance out of the collaboration process. Thomas -- Thomas Witt wi...@ac... |
|
From: Niki S. <nik...@gm...> - 2006-01-20 19:06:41
|
Have you checked scintilla/scite? It can handle many tab+indent combinations and also can use per-directory tab/indent settings. Niki Spahiev |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X