Thread: Re: [Audacity-devel] Code Style Guide?
A free multi-track audio editor and recorder
Brought to you by:
aosiniao
From: Leland <le...@au...> - 2013-02-02 21:31:04
|
I would kiss (no wait...that's not a perk ;-)) the first person to put the Audacity source into one consistent style, excluding lib-src of course. There used to be some strong opinions on what the style should be and compliance to that style (similar to my opinions on top posting), but that may no longer be a road block. Sure, I have my own coding style, but when dealing with Audacity the best I can do is try to be consistent to the code around where I'm working. But, over the years a TON of different "styles" have found their way into the source (I'm as guilty as the rest). I think it would benefit the project considerably to have a single style as it would simply be easier for potential newcomers to get comfortable with the source. One thing that I totally hate though is this: if (...) do something; if (...) do something; else do something; if (...) do something; if (...) do something; else do something; I always prefer braces. But, if a proposed style wanted the above I'd follow the style religiously as I'd be so happy that there was only one style. Can I give a +100 to this? :-) Leland |
From: Benjamin D. <bd...@de...> - 2013-02-02 23:10:44
|
Am Samstag, den 02.02.2013, 15:31 -0600 schrieb Leland: > I would kiss (no wait...that's not a perk ;-)) the first person to put > the Audacity source into one consistent style, excluding lib-src of course. > > There used to be some strong opinions on what the style should be and > compliance to that style (similar to my opinions on top posting), but > that may no longer be a road block. Sure, I have my own coding style, > but when dealing with Audacity the best I can do is try to be consistent > to the code around where I'm working. > > But, over the years a TON of different "styles" have found their way > into the source (I'm as guilty as the rest). I think it would benefit > the project considerably to have a single style as it would simply be > easier for potential newcomers to get comfortable with the source. +1 It's more important to be consistent than to have your own preferred style. Can we extend [1] to make it more detailed? Is there a strong preference to use three spaces per indent? I would prefer to switch to either two or four spaces per indent. [1] http://wiki.audacityteam.org/wiki/CodingStandards > One thing that I totally hate though is this: > > if (...) > do something; > > if (...) > do something; > else > do something; > > if (...) do something; > > if (...) > do something; > else do something; > > I always prefer braces. +100 from me to always use braces. Extending the if-clauses above cause problems in case of adding the braces is forgotten. > But, if a proposed style wanted the above I'd > follow the style religiously as I'd be so happy that there was only one > style. The current coding standard does say anything about it. -- Benjamin Drung Debian & Ubuntu Developer |
From: Vaughan J. <va...@au...> - 2013-02-05 06:34:03
|
On 2/2/2013 3:10 PM, Benjamin Drung wrote: > Am Samstag, den 02.02.2013, 15:31 -0600 schrieb Leland: >> [...]> > Is there a strong preference to use three spaces per indent? YES! That's the ONLY style guideline we've really ever tried to really enforce over the whole life of this project. Leland's call was for *more* consistency, not less. Obviously, some contributors have ignored some of the conventions mentioned at http://wiki.audacityteam.org/wiki/CodingStandards#Conventions. And more. Quality of performance matters lots more. >I would > prefer to switch to either two or four spaces per indent. No way, newcomer! :-) - V |
From: Leland <le...@au...> - 2013-02-03 00:22:30
|
Here's a little more background: http://audacity.238276.n2.nabble.com/How-about-resurrecting-scripts-reindent-td249124.html And I'm sure it was discussed way before that. For those that don't know Dominic was one of the original authors of Audacity. Leland |
From: Benjamin D. <bd...@de...> - 2013-02-03 00:43:26
|
Am Samstag, den 02.02.2013, 18:22 -0600 schrieb Leland: > Here's a little more background: > > http://audacity.238276.n2.nabble.com/How-about-resurrecting-scripts-reindent-td249124.html Thanks. > And I'm sure it was discussed way before that. For those that don't > know Dominic was one of the original authors of Audacity. Maybe it's time to discuss it again. Old developers retired and new joined. So the overall preference could have been changed. Who of the Audacity developers has strong opinions regarding coding styles and who does not care (as long it's consistent)? Three spaces for indentation was a compromise between two and four. Who is for two spaces and who is for four? -- Benjamin Drung Debian & Ubuntu Developer |
From: Vaughan J. <va...@au...> - 2013-02-05 06:37:05
|
On 2/2/2013 4:43 PM, Benjamin Drung wrote: > Am Samstag, den 02.02.2013, 18:22 -0600 schrieb Leland: >> Here's a little more background: >> >> http://audacity.238276.n2.nabble.com/How-about-resurrecting-scripts-reindent-td249124.html > > Thanks. > >> And I'm sure it was discussed way before that. For those that don't >> know Dominic was one of the original authors of Audacity. > > Maybe it's time to discuss it again. Old developers retired and new > joined. So the overall preference could have been changed. Who of the > Audacity developers has strong opinions regarding coding styles and who > does not care (as long it's consistent)? > > Three spaces for indentation was a compromise between two and four. Who > is for two spaces and who is for four? > Come on. We have better things to discuss, and work on. How on earth would this be a benefit to Audacity users? No change. Let's drop this discussion. - V |
From: Campbell B. <ide...@gm...> - 2013-02-03 02:42:39
|
The Coding Standards doc is OK but misses a lot of areas. http://wiki.audacityteam.org/wiki/CodingStandards Some suggestions (take with grain of salt, Im not an Audacity dev, though I have applied code style to large open-source code-base before). First of all, I'd suggest agreeing on a basic style guide even if you don't immediately apply it, this at least gives new devs some direction. Here are some areas I think would be good to define initially. Indentation ----------- Looks like its already 3 spaces, just not followed sometimes. grep -R $'^\t' * | wc -l --> 2342 Its annoying when editing others code if this is all mixed up, easy one to resolve. Braces ------ Recommend including in your style guides, existing code uses most possible permutations of... } else { - snip } else { - snip } else { - snip ...and even if(...) { } I've found having this consistent just makes code easier to follow and removes the desire to reformat when you see style mixed up in adjacent blocks of code. Operators --------- a*b, a+b... are readable but expressions like a->b-=c->d-1 can get confusing, some projects use spaces around operators always for better clarity. This could remain left open to devs to do how they like to use common sense add spaces when its obviously more readable. but suggest setting on one way for pointer & references. int *v; or... int* v; Spacing for flow control if/switch/while ---------------------------------------- if () { - snip if(){ - snip if() { Another area where theres zero advantage in mixing up style IMHO. Line Length ----------- If this is included in the style guide, editors that draw a right margin can have this set to a useful value, once the margin's there - its pretty easy to follow. More could be written on this but think having these basics agreed on would be a nice start for audacity, and makes it more pleasant newcomers having to grok the code-base. |
From: Leland <le...@au...> - 2013-02-03 05:47:39
|
On 2/2/2013 6:43 PM, Benjamin Drung wrote: > Am Samstag, den 02.02.2013, 18:22 -0600 schrieb Leland: >> Here's a little more background: >> >> http://audacity.238276.n2.nabble.com/How-about-resurrecting-scripts-reindent-td249124.html > > Thanks. > >> And I'm sure it was discussed way before that. For those that don't >> know Dominic was one of the original authors of Audacity. > > Maybe it's time to discuss it again. Old developers retired and new > joined. So the overall preference could have been changed. Who of the > Audacity developers has strong opinions regarding coding styles and who > does not care (as long it's consistent)? > Honestly, I'm not active enough to warrant a vote in the style itself, but it might not be a bad idea to devise one where GNU indent (that's why I asked the question back in 2006 ;-)) could be used to help police it. Reviewing code can be difficult enough without adding in the "eyeballing" approach of verifying style. > Three spaces for indentation was a compromise between two and four. Who > is for two spaces and who is for four? > Definitely 4, but only my opinion. I use 2 when writing REXX code, but 4 for everything else. Leland |
From: Rob S. <aq...@ya...> - 2013-02-03 09:17:24
|
Last time I was on a project faced with sorting out a style guide, we opted to avoid all personal opinion by adopting an off-the-shelf guide—this one seemed the most complete and well thought out: http://geosoft.no/development/cppstyle.html Cheers, Rob |
From: Vaughan J. <va...@au...> - 2013-02-05 06:54:38
|
On 2/3/2013 1:17 AM, Rob Sykes wrote: > > > Last time I was on a project faced with sorting out a style guide, we opted to avoid all personal opinion by adopting an off-the-shelf guide—this one seemed the most complete and well thought out: http://geosoft.no/development/cppstyle.html > > Cheers, > Rob > I agree off-the-shelf would be better than an extended discussion among ourselves, but I just don't see the value for the project right now, unless it's to apply it to a new almost-from-scratch rewrite. And we don't have resources for either. - V |
From: Michael S. <msc...@bs...> - 2013-02-03 09:58:31
|
On 03.02.2013 03:42, Campbell Barton wrote: > if (...) > { > > } > else > { > > } This creates a huge count of line breaks without any functionality at all and reduces the code readability by moving much stuff out of sight. -Michael |
From: Campbell B. <ide...@gm...> - 2013-02-03 10:10:40
|
On Sun, Feb 3, 2013 at 8:43 PM, Michael Schnell <msc...@bs...> wrote: > On 03.02.2013 03:42, Campbell Barton wrote: >> if (...) >> { >> >> } >> else >> { >> >> } > > This creates a huge count of line breaks without any functionality at > all and reduces the code readability by moving much stuff out of sight. > > -Michael Just pointing out that this exists in Audacity's code, not making a call which style should be used (better existing core developers do that). |
From: Vaughan J. <va...@au...> - 2013-02-05 06:52:06
|
On 2/3/2013 1:43 AM, Michael Schnell wrote: > On 03.02.2013 03:42, Campbell Barton wrote: >> if (...) >> { >> >> } >> else >> { >> >> } > > This creates a huge count of line breaks without any functionality at > all and reduces the code readability by moving much stuff out of sight. > > -Michael Michael, I strongly admire your abilities, but this style is per the original C spec. I've used different styles over the years, and now find this way easiest to parse. Number of line breaks? Monitors are huge and hi-rez. Again, I say this is all religious/personal-pref argument, and not even different religions, just sects within the same one. Probably why it's generating so much discussion. ;-) - V |
From: Michael S. <msc...@bs...> - 2013-02-03 09:58:50
|
On 02.02.2013 22:31, Leland wrote: > do something; > else > do something; > IMHO braces should only be dropped when the if clause completely resides in a single line: if (...) do_something; but (always avoiding a single line for an opening brace): if (...){ do something; } With "else" and other multi-alternatives I use "half-indentation" to make very clear where the complete "if" clause is finished (the opening line starts straight above the closing brace): if (...){ do something; } else { do_something_else; } and switch (...){ case 1: do_case_1; break; case 2: do_case_2; break; case 3: do_case_3; break; default do_default; break; } and if (...){ do_case_1; } else if (...) { do_case_2; } else if (...) { do_case_4; } else { do_default; break; } -Michael |
From: Vaughan J. <va...@au...> - 2013-02-05 06:26:43
|
On 2/2/2013 1:31 PM, Leland wrote: > I would kiss (no wait...that's not a perk ;-)) the first person to put > the Audacity source into one consistent style, excluding lib-src of course. Oh no! Leland, I think this is really the wrong way for you to drop back in. This is a discussion about minutiae, as I see it, and not productive, vs a major start-from-scratch rewrite. Varying personal styles vs contribution levels are simply a fact of life of F/OSS. Decision was made by Dominic at project inception (14 yrs ago?!) that contribution level is more important than style rigor. I have very strong opinions about style, but bite my tongue about them consistently, regarding Audacity, in favor of actual progress. > > There used to be some strong opinions on what the style should be and > compliance to that style (similar to my opinions on top posting), but > that may no longer be a road block. Sure, I have my own coding style, > but when dealing with Audacity the best I can do is try to be consistent > to the code around where I'm working. Yes, that's the cooperative way to work. The problems you're bringing up are from people who ignored that principle, as I see it. I certainly don't want to spend my time making their stuff that works, but ignores convention, follow my conventions. > > But, over the years a TON of different "styles" have found their way > into the source (I'm as guilty as the rest). Yeah, the people who have ventured far from the original, and more standard practices (e.g., vars begin with lower case) have made some sections of the code much harder to read. But I don't think it's a good use of anybody's time (other than maybe the original person who ignored convention) to fix that. And it doesn't seem like you're offering, just opining. Any one of us who would offer to do it his way would be violating style sensibilities of at least one of us. Always been that way on this project. Again, not something I think we should focus on. >I think it would benefit > the project considerably I disagree with "considerably" in view of other glaring resource shortages we have. >to have a single style as it would simply be > easier for potential newcomers to get comfortable with the source. Still think it's small reward to effort ratio. Hasn't been a major drag to new contributors so far, I think. > > One thing that I totally hate though is this: > > if (...) > do something; > > if (...) > do something; > else > do something; > > if (...) do something; > > if (...) > do something; > else do something; > > I always prefer braces. But, if a proposed style wanted the above I'd > follow the style religiously as I'd be so happy that there was only one > style. > Come on, man. Minutiae. I agree with your aesthetics there, but we have more important things to do. How many other standards of indentation/braces/whatever would we need to discuss? Yes, religious arguments, and of tiny import compared to how the software actually functions. > Can I give a +100 to this? :-) No way. There's only +/-1 in voting, yea or nay. But to counteract, I say -101. That's compared to keeping the project vital with new and corrected functionality vs internal stylistic correctness. - V |
From: Vaughan J. <va...@au...> - 2013-02-05 06:47:32
|
Hi, Campbell. Great to have a contribution from you. But as I've written to others on this thread, we have better things to discuss, and to work on. To be clear, I would *prefer* the code were consistent with the few guidelines we already have. But other than all this opining, who is willing to even enforce those existing guidelines, much less new suggested guidelines? On 2/2/2013 6:42 PM, Campbell Barton wrote: > The Coding Standards doc is OK but misses a lot of areas. > http://wiki.audacityteam.org/wiki/CodingStandards > > Some suggestions > (take with grain of salt, Im not an Audacity dev, though I have > applied code style to large open-source code-base before). Okay, with what measurable benefits? Even 10% gain in productivity to developers would surprise me. And I think just about 0% value to users. - V |
From: Campbell B. <ide...@gm...> - 2013-02-05 07:16:17
|
On Tue, Feb 5, 2013 at 5:47 PM, Vaughan Johnson <va...@au...> wrote: > Hi, Campbell. Great to have a contribution from you. But as I've written > to others on this thread, we have better things to discuss, and to work on. > > To be clear, I would *prefer* the code were consistent with the few > guidelines we already have. But other than all this opining, who is > willing to even enforce those existing guidelines, much less new > suggested guidelines? > > > On 2/2/2013 6:42 PM, Campbell Barton wrote: >> The Coding Standards doc is OK but misses a lot of areas. >> http://wiki.audacityteam.org/wiki/CodingStandards >> >> Some suggestions >> (take with grain of salt, Im not an Audacity dev, though I have >> applied code style to large open-source code-base before). > > Okay, with what measurable benefits? Even 10% gain in productivity to > developers would surprise me. And I think just about 0% value to users. > > - V As for measurable - none since I applied and moved on. But some of my own experience... - Having done a lot of bugfixing (reading other peoples code on a daily basis for over a year), using consistent brace placement (as a minimum) makes logic-flow easier to comprehend. ... since typically code is read more then written, to be able to follow the logic easily when moving between files is an advantage. - while working on bugfixing I found bugs that were caused by changes to code that was confusingly formatted to begin with, not a large number --- perhaps 30 or so in the past year, but enough. Regarding who does this, as I said before - a style guide can be agreed on, and then only applied to newly written code, its not necessarily a lot of work. Exactly what style is used is up to devs but formalizing the style already used by the majority of audacities code is reasonable IMHO and not disruptive to the codebase (no diff's changing every if/for/while). Final point, while of course this isn't high priority - IMHO this isn't necessarily taking time away from other important tasks. Time I spent working on style-cleanup was time I'd probably have done some other relaxing/non-stressful tasks (since its normally not as intense as real development work). For those who dont think code style is important, suggest watching http://www.youtube.com/watch?v=taaEzHI9xyY There are good reasons many companies/projects settle on a style guide. - Campbell |
From: Vaughan J. <va...@au...> - 2013-02-05 08:26:44
|
On 2/4/2013 11:16 PM, Campbell Barton wrote: > On Tue, Feb 5, 2013 at 5:47 PM, Vaughan Johnson > <va...@au...> wrote: >> [...] >> To be clear, I would *prefer* the code were consistent with the few >> guidelines we already have. But other than all this opining, who is >> willing to even enforce those existing guidelines, much less new >> suggested guidelines? >> >> >> On 2/2/2013 6:42 PM, Campbell Barton wrote: >>> [...] >> Okay, with what measurable benefits? Even 10% gain in productivity to >> developers would surprise me. And I think just about 0% value to users. >>[...] > > As for measurable - none since I applied and moved on. Okay, so it's your personal opinion. > > But some of my own experience... > > - Having done a lot of bugfixing (reading other peoples code on a > daily basis for over a year) More than one year? Blessings on you. I've been fixing other peoples' bugs on Audacity (alone) for at least 5. Yes, much of those fixes would have been easier if they coded in my style, so I could more easily understand it, but that's just not a reasonable expectation for f/oSS, imo. >, using consistent brace placement (as a > minimum) makes logic-flow easier to comprehend. I said I don't disagree about the specifics, just the value of this discussion. Good arguments exist for all the popular C++ coding styles. Code is code, so if a compiler can parse it, I think a human can. Each of us finds somebody else's style/grammar more/less difficult to read. > ... since typically code is read more then written, Not sure that's true. Depends on the code, number of developers, and especially encapsulation. Refs? >to be able to > follow the logic easily when moving between files is an advantage. No doubt. But just in this thread, we clearly have different opinions about what's easy to read. > Final point, while of course this isn't high priority - IMHO this > isn't necessarily taking time away from other important tasks. This discussion *itself* is taking time away from other important tasks. > [...] > There are good reasons many companies/projects settle on a style guide. > For sure. We're not a company, though, and have been quite successful with a relatively loose attention to style, high attention to functionality and bug-fixing. Thanks, Vaughan |
From: Campbell B. <ide...@gm...> - 2013-02-06 04:52:12
|
On Tue, Feb 5, 2013 at 7:22 PM, Vaughan Johnson <va...@au...> wrote: > On 2/4/2013 11:16 PM, Campbell Barton wrote: >> On Tue, Feb 5, 2013 at 5:47 PM, Vaughan Johnson >> <va...@au...> wrote: >>> [...] >>> To be clear, I would *prefer* the code were consistent with the few >>> guidelines we already have. But other than all this opining, who is >>> willing to even enforce those existing guidelines, much less new >>> suggested guidelines? >>> >>> >>> On 2/2/2013 6:42 PM, Campbell Barton wrote: >>>> [...] >>> Okay, with what measurable benefits? Even 10% gain in productivity to >>> developers would surprise me. And I think just about 0% value to users. >>>[...] >> >> As for measurable - none since I applied and moved on. > > Okay, so it's your personal opinion. > > >> >> But some of my own experience... >> >> - Having done a lot of bugfixing (reading other peoples code on a >> daily basis for over a year) > > More than one year? Blessings on you. I've been fixing other peoples' > bugs on Audacity (alone) for at least 5. Great you've been working on Audacity fixing bugs but no need to be patronizing. This isnt a competition - was just saying that I was reading other peoples code for my day job and found errors caused by poorly formatted/confusing code. > Yes, much of those fixes would have been easier if they coded in my > style, so I could more easily understand it, but that's just not a > reasonable expectation for f/oSS, imo. You miss the point, confusing personal preference with self-consistency. Also not sure why you would have lower expectations for f/oSS? >>, using consistent brace placement (as a >> minimum) makes logic-flow easier to comprehend. > > I said I don't disagree about the specifics, just the value of this > discussion. Good arguments exist for all the popular C++ coding styles. > > Code is code, so if a compiler can parse it, I think a human can. Each > of us finds somebody else's style/grammar more/less difficult to read. Strongly disagree here, compilers can parse all sorts of cruft you'd never want to have to debug or read. >> ... since typically code is read more then written, > > Not sure that's true. Depends on the code, number of developers, and > especially encapsulation. Refs? For sure its true, refer to Guido van Rossum (Python founder) who's no fool. http://www.python.org/dev/peps/pep-0008/#a-foolish-consistency-is-the-hobgoblin-of-little-minds >>to be able to >> follow the logic easily when moving between files is an advantage. > > No doubt. But just in this thread, we clearly have different opinions > about what's easy to read. Refer to my point about standardizing on what you have (since the style _is_ consistent across some areas - just use this as the standard). Though since it seems Audacity doesn't have clear leadership and is governed by consensus? In this case you end up with "Cant agree on everything, do nothing" outcome. >> Final point, while of course this isn't high priority - IMHO this >> isn't necessarily taking time away from other important tasks. > > This discussion *itself* is taking time away from other important tasks. > > >> [...] >> There are good reasons many companies/projects settle on a style guide. >> > > For sure. We're not a company, though, and have been quite successful > with a relatively loose attention to style, high attention to > functionality and bug-fixing. Not being a company is no reason to think this unimportant - many entirely OSS projects do this In fact most that I come across - off hand, cpython, gcc, cmake, linux, xorg. And I find it mildly off-putting when they don't have some coherent code style. Even when its not my personal preferred style, consistency is best. > Thanks, > Vaughan > > > > ------------------------------------------------------------------------------ > Free Next-Gen Firewall Hardware Offer > Buy your Sophos next-gen firewall before the end March 2013 > and get the hardware for free! Learn more. > http://p.sf.net/sfu/sophos-d2d-feb > _______________________________________________ > audacity-devel mailing list > aud...@li... > https://lists.sourceforge.net/lists/listinfo/audacity-devel -- - Campbell |
From: Vaughan J. <va...@au...> - 2013-02-08 08:01:19
|
On 2/5/2013 8:52 PM, Campbell Barton wrote: > On Tue, Feb 5, 2013 at 7:22 PM, Vaughan Johnson > <va...@au...> wrote: >> On 2/4/2013 11:16 PM, Campbell Barton wrote: >>> On Tue, Feb 5, 2013 at 5:47 PM, Vaughan Johnson >>> <va...@au...> wrote: >>>> [...] >>>> >>> But some of my own experience... >>> >>> - Having done a lot of bugfixing (reading other peoples code on a >>> daily basis for over a year) >> >> More than one year? Blessings on you. I've been fixing other peoples' >> bugs on Audacity (alone) for at least 5. > > Great you've been working on Audacity fixing bugs but no need to be patronizing. > This isnt a competition - was just saying that I was reading other > peoples code for my day job and found errors caused by poorly > formatted/confusing code. Just responding to your bringing up the metric of your "over a year" experience. Had been trying to discuss based on the merits, not arguing from level of experience. I responded on that point because you brought it up, and a year is not much experience. Looked like a troll to me. I'm getting tired of feeding this particular troll. :-( > >> Yes, much of those fixes would have been easier if they coded in my >> style, so I could more easily understand it, but that's just not a >> reasonable expectation for f/oSS, imo. > > You miss the point, confusing personal preference with self-consistency. Actually, I was talking about overall consistency, whether my personal preference or not. As a polemic, I was just giving the polar example of "everything the way I'd do it", which is what I think much of this discussion is about, at core. > Also not sure why you would have lower expectations for f/oSS? That's not necessarily lower expectations, vs growth and influence of the project. Maybe "not a reasonable expectation" was too broad a generalization from me over f/oss, but I meant that for Audacity (and I think most f/oss projects), because most contribution is voluntary, and transient, consistent style is very hard to achieve. We've had many developers over the years who participate for a short (sometimes long, often infrequent) time, then move on, or become lurkers. (Ahem, like the guy who started this thread, and admitted he'd diverged from prior style when he contributed -- much love!) That's fine, that's how Audacity grew, but it makes it pretty much impossible for the long-time contributors to enforce tight style standards. > >>> , using consistent brace placement (as a >>> minimum) makes logic-flow easier to comprehend. >> >> I said I don't disagree about the specifics, just the value of this >> discussion. Good arguments exist for all the popular C++ coding styles. >> >> Code is code, so if a compiler can parse it, I think a human can. Each >> of us finds somebody else's style/grammar more/less difficult to read. > > Strongly disagree here, compilers can parse all sorts of cruft you'd > never want to have to debug or read. If it's that bad, we wouldn't accept into our code base. This discussion is not about that kind of extreme, just tabs vs 3 vs 4 vs 2 spaces, and where braces appear, for pete's sake. Both discussions I think are pointless. Was talking about generally accepted standards, though varying in Audacity code. I don't see the varying existing styles ("spaces and braces"?!) as such a big problem that warrants this much discussion. Exception would be if the submitted code were very idiosyncratic/hard-to-read, but tremendously encapsulated (like many of the libraries we use), in which case we don't need to worry about the style of whoever is maintaining it, i.e., it's a "black box" plus API. > >>> ... since typically code is read more then written, >> >> Not sure that's true. Depends on the code, number of developers, and >> especially encapsulation. Refs? > > For sure its true, refer to Guido van Rossum (Python founder) who's no fool. > http://www.python.org/dev/peps/pep-0008/#a-foolish-consistency-is-the-hobgoblin-of-little-minds > I am, and have been, totally agreeing that consistency is preferable. But this specific citation is more religion, imo. You site one project, when I said it depends... I was talking about Audacity code, not the whole world of code. As I wrote, depends on the code, *number of devs*, and encapsulation. Python has tons more developers than Audacity, so of course its code is more widely read. Doesn't apply here, at least not the past few years, relative to number of contributors. And even among these few consistent, remaining developers to Audacity, there's been slight attention to prior style standards. Seems most don't know or don't respect the existing conventions. But it's a "do-ocracy" so what works and is acceptably readable, is accepted. >>> to be able to >>> follow the logic easily when moving between files is an advantage. Of course it is. I said that. Just that it's not the best thing to prioritize for Audacity, given our limited resources. I sure don't want to review, or allow to be committed, tens of thousands of changed lines of code that vary only by a space. I'd rather do an almost-from-scratch rewrite, if we had the resources. I think that could go a lot further to making a new generation of Audacity that has much bigger benefit for users. >> >> No doubt. But just in this thread, we clearly have different opinions >> about what's easy to read. > > Refer to my point about standardizing on what you have (since the > style _is_ consistent across some areas - just use this as the > standard). The reason it's different in other areas is the stuff I discussed above. Anyway, the places it's consistent were not this discussion, it was about changing indentations and braces, for cryin' out loud. > > Though since it seems Audacity doesn't have clear leadership and is > governed by consensus? Not for code. Not for decisions about direction of the project. We have the Tech Leaders (http://audacity.sourceforge.net/about/credits), and allow commits only by review, except for a few developers. The rest is mostly by consensus, and more so, level of interest/effort. All the issues in this thread have already been decided, prior to this re-discussion. > In this case you end up with "Cant agree on everything, do nothing" outcome. Not the case here. Insulting for you to imply it. > >>> Final point, while of course this isn't high priority - IMHO this >>> isn't necessarily taking time away from other important tasks. >> >> This discussion *itself* is taking time away from other important tasks. >> >> >>> [...] >>> There are good reasons many companies/projects settle on a style guide. >>> >> >> For sure. We're not a company, though, and have been quite successful >> with a relatively loose attention to style, high attention to >> functionality and bug-fixing. > > Not being a company is no reason to think this unimportant Dude, I have responded to you. No implication that it's unimportant, just already decided. But I'm getting tired of repeating that. >- many > entirely OSS projects do this In fact most that I come across - off > hand, cpython, gcc, cmake, linux, xorg. > And I find it mildly off-putting when they don't have some coherent code style. > Even when its not my personal preferred style, consistency is best. > Totally prefer that. Don't see any way we have resources for it. - V |
From: Campbell B. <ide...@gm...> - 2013-02-08 08:59:49
|
On Fri, Feb 8, 2013 at 7:01 PM, Vaughan Johnson <va...@au...> wrote: > On 2/5/2013 8:52 PM, Campbell Barton wrote: >> On Tue, Feb 5, 2013 at 7:22 PM, Vaughan Johnson >> <va...@au...> wrote: >>> On 2/4/2013 11:16 PM, Campbell Barton wrote: >>>> On Tue, Feb 5, 2013 at 5:47 PM, Vaughan Johnson >>>> <va...@au...> wrote: >>>>> [...] >>>>> >>>> But some of my own experience... >>>> >>>> - Having done a lot of bugfixing (reading other peoples code on a >>>> daily basis for over a year) >>> >>> More than one year? Blessings on you. I've been fixing other peoples' >>> bugs on Audacity (alone) for at least 5. >> >> Great you've been working on Audacity fixing bugs but no need to be patronizing. >> This isnt a competition - was just saying that I was reading other >> peoples code for my day job and found errors caused by poorly >> formatted/confusing code. > > Just responding to your bringing up the metric of your "over a year" > experience. think you misunderstood, I was working on the project for some years, then moved to bug-fixing full-time (I wasn't aware of audacity having any fulltime devs - quick check of ohloh seems not, but I may be wrong). Not that this gives me some right to say whats best for other projects, but if you have to do a lot of bugfixing you start to see patterns and re-occurring errors and think about how best to void. > Had been trying to discuss based on the merits, not arguing from level > of experience. I responded on that point because you brought it up, and > a year is not much experience. > > Looked like a troll to me. I'm getting tired of feeding this particular > troll. :-( > > >> >>> Yes, much of those fixes would have been easier if they coded in my >>> style, so I could more easily understand it, but that's just not a >>> reasonable expectation for f/oSS, imo. >> >> You miss the point, confusing personal preference with self-consistency. > > Actually, I was talking about overall consistency, whether my personal > preference or not. As a polemic, I was just giving the polar example of > "everything the way I'd do it", which is what I think much of this > discussion is about, at core. Was trying to avoid personal preference coming into it, this is for technical leaders to choose. >> Also not sure why you would have lower expectations for f/oSS? > > That's not necessarily lower expectations, vs growth and influence of > the project. > > Maybe "not a reasonable expectation" was too broad a generalization from > me over f/oss, but I meant that for Audacity (and I think most f/oss > projects), because most contribution is voluntary, and transient, > consistent style is very hard to achieve. > > We've had many developers over the years who participate for a short > (sometimes long, often infrequent) time, then move on, or become > lurkers. (Ahem, like the guy who started this thread, and admitted he'd > diverged from prior style when he contributed -- much love!) > > That's fine, that's how Audacity grew, but it makes it pretty much > impossible for the long-time contributors to enforce tight style standards. My suggestion was to settle on a standard and apply when writing new code (to begin with). I think its feasible even with small team. >>>> , using consistent brace placement (as a >>>> minimum) makes logic-flow easier to comprehend. >>> >>> I said I don't disagree about the specifics, just the value of this >>> discussion. Good arguments exist for all the popular C++ coding styles. >>> >>> Code is code, so if a compiler can parse it, I think a human can. Each >>> of us finds somebody else's style/grammar more/less difficult to read. >> >> Strongly disagree here, compilers can parse all sorts of cruft you'd >> never want to have to debug or read. > > If it's that bad, we wouldn't accept into our code base. > > This discussion is not about that kind of extreme, just tabs vs 3 vs 4 > vs 2 spaces, and where braces appear, for pete's sake. Both discussions > I think are pointless. re: indentation - agree, I assumed existing indentation would be kept. as for braces, dont think its pointless since it effects how you read the code and mixing up confuses IMHO. > Was talking about generally accepted standards, though varying in > Audacity code. I don't see the varying existing styles ("spaces and > braces"?!) as such a big problem that warrants this much discussion. > > Exception would be if the submitted code were very > idiosyncratic/hard-to-read, but tremendously encapsulated (like many of > the libraries we use), in which case we don't need to worry about the > style of whoever is maintaining it, i.e., it's a "black box" plus API. > > >> >>>> ... since typically code is read more then written, >>> >>> Not sure that's true. Depends on the code, number of developers, and >>> especially encapsulation. Refs? >> >> For sure its true, refer to Guido van Rossum (Python founder) who's no fool. >> http://www.python.org/dev/peps/pep-0008/#a-foolish-consistency-is-the-hobgoblin-of-little-minds >> > > I am, and have been, totally agreeing that consistency is preferable. > But this specific citation is more religion, imo. You site one project, > when I said it depends... > > I was talking about Audacity code, not the whole world of code. As I > wrote, depends on the code, *number of devs*, and encapsulation. Python > has tons more developers than Audacity, so of course its code is more > widely read. Doesn't apply here, at least not the past few years, > relative to number of contributors. See your point, Though even if only one developer ever reads their own code, every time you step over it with a debugger or go to make some small change, you're still end up reading it each time. > And even among these few consistent, remaining developers to Audacity, > there's been slight attention to prior style standards. Seems most don't > know or don't respect the existing conventions. But it's a "do-ocracy" > so what works and is acceptably readable, is accepted. > > >>>> to be able to >>>> follow the logic easily when moving between files is an advantage. > > Of course it is. I said that. Just that it's not the best thing to > prioritize for Audacity, given our limited resources. > > I sure don't want to review, or allow to be committed, tens of thousands > of changed lines of code that vary only by a space. Not sure what you mean, are you saying you don't want to review patches that only reformat? In that case - you need to trust the person doing the work isnt making functional changes (or if not, make the changes yourself - or be clever and diff assembler output or so) - of course reviewing that kind of patch is horrible & poor use of time. > I'd rather do an almost-from-scratch rewrite, if we had the resources. I > think that could go a lot further to making a new generation of Audacity > that has much bigger benefit for users. > > >>> >>> No doubt. But just in this thread, we clearly have different opinions >>> about what's easy to read. >> >> Refer to my point about standardizing on what you have (since the >> style _is_ consistent across some areas - just use this as the >> standard). > > The reason it's different in other areas is the stuff I discussed above. > > Anyway, the places it's consistent were not this discussion, it was > about changing indentations and braces, for cryin' out loud. > > >> >> Though since it seems Audacity doesn't have clear leadership and is >> governed by consensus? > > Not for code. Not for decisions about direction of the project. > > We have the Tech Leaders > (http://audacity.sourceforge.net/about/credits), and allow commits only > by review, except for a few developers. > > The rest is mostly by consensus, and more so, level of interest/effort. > > All the issues in this thread have already been decided, prior to this > re-discussion. > > >> In this case you end up with "Cant agree on everything, do nothing" outcome. > > Not the case here. Insulting for you to imply it. I didn't mean this to be insulting, its just in my experience - controversial areas of projects tend to be avoided by developers who know they will put themselves in the middle of a big argument & open a can of worms and their changes will have to be justified to others on the team who disagree. >>>> Final point, while of course this isn't high priority - IMHO this >>>> isn't necessarily taking time away from other important tasks. >>> >>> This discussion *itself* is taking time away from other important tasks. >>> >>> >>>> [...] >>>> There are good reasons many companies/projects settle on a style guide. >>>> >>> >>> For sure. We're not a company, though, and have been quite successful >>> with a relatively loose attention to style, high attention to >>> functionality and bug-fixing. >> >> Not being a company is no reason to think this unimportant > > Dude, I have responded to you. No implication that it's unimportant, > just already decided. But I'm getting tired of repeating that. > > >>- many >> entirely OSS projects do this In fact most that I come across - off >> hand, cpython, gcc, cmake, linux, xorg. >> And I find it mildly off-putting when they don't have some coherent code style. >> Even when its not my personal preferred style, consistency is best. >> > > Totally prefer that. Don't see any way we have resources for it. Think this can be tacked in a way that its not out of reach - you may even find some 'lurkers' are willing to foot some of the work. Also think it can be broken up into small parts - eg, define module which is a bit of a mess and first make it consistent... finish it and move on. I'd be happy to help out on this, if some agreement can be made as to what areas should be worked on. > - V > > > ------------------------------------------------------------------------------ > Free Next-Gen Firewall Hardware Offer > Buy your Sophos next-gen firewall before the end March 2013 > and get the hardware for free! Learn more. > http://p.sf.net/sfu/sophos-d2d-feb > _______________________________________________ > audacity-devel mailing list > aud...@li... > https://lists.sourceforge.net/lists/listinfo/audacity-devel -- - Campbell |
From: Vaughan J. <va...@au...> - 2013-02-09 00:44:02
|
On 2/8/2013 12:59 AM, Campbell Barton wrote: > On Fri, Feb 8, 2013 at 7:01 PM, Vaughan Johnson >> On 2/5/2013 8:52 PM, Campbell Barton wrote: >>> On Tue, Feb 5, 2013 at 7:22 PM, Vaughan Johnson >>>> On 2/4/2013 11:16 PM, Campbell Barton wrote: >>>>> On Tue, Feb 5, 2013 at 5:47 PM, Vaughan Johnson >>>>> <va...@au...> wrote: >>>>>> [...] >>>>>> >>>>> But some of my own experience... >>>>> >>>>> - Having done a lot of bugfixing (reading other peoples code on a >>>>> daily basis for over a year) >>>> >>>> More than one year? Blessings on you. I've been fixing other peoples' >>>> bugs on Audacity (alone) for at least 5. >>> >>> Great you've been working on Audacity fixing bugs but no need to be patronizing. I was just calling a troll a troll, as I read it. If that wasn't your intention, I apologize. But I still think that's what it effectively was. >>> This isnt a competition - was just saying that I was reading other >>> peoples code for my day job and found errors caused by poorly >>> formatted/confusing code. My point was that because you had no idea of the backgrounds of most (any?) of us, it was not a helpful point, especially as we were already in agreement in principle that consistent, good code style can be very helpful. And just so the new contributors on this thread know, some of us have gradually been making it more consistent over the years. But we haven't got resources to do it all at once. And it wouldn't fix the bigger architectural issues that are much more important, primary among those being GUI code intermixed with processing code, no real time effects, and other ideas for major changes, all in the archives, not to mention Bugzilla. We need to make progress on things that will actually benefit users near term with the resources we have, e.g., integrating libsoxr (thanks Rob!). >> >> Just responding to your bringing up the metric of your "over a year" >> experience. > think you misunderstood, I was working on the project for some years, > then moved to bug-fixing full-time (I wasn't aware of audacity having > any fulltime devs - quick check of ohloh seems not, but I may be > wrong). What does full time on Audacity have to do with what prior and current experience we have elsewhere? > [...] >> Actually, I was talking about overall consistency, whether my personal >> preference or not. As a polemic, I was just giving the polar example of >> "everything the way I'd do it", which is what I think much of this >> discussion is about, at core. > > Was trying to avoid personal preference coming into it, this is for > technical leaders to choose. As I wrote, it was just an extreme example, *not* my personal preference. But I think every post in this thread has been soaking in personal preference. :-) > [...] > > My suggestion was to settle on a standard and apply when writing new > code (to begin with). > I think its feasible even with small team. Heh, I think this thread (and the digression into email style) is evidence that discussing what style to use would use up far more resources than it would save in the long run. And then we would be discouraging contribution from new developers who don't want to be forced into a style they don't like. And we'd have to enforce it. I don't know who would want to spend time doing it. I usually do, to some extent, to our most typical style, when I review patches. We have long time contributors who still violate the tiny set of guidelines we already have. I'm not saying it's because this is the way we've always done it, although I'll say again that we've been quite successful doing it this way. But at this time, it's just not a good choice of major projects to take on. So for me, this discussion has gone on way too long. (And it's a discussion that pops up every few years, mostly from new contributors.) I'm going to bow out of this discussion topic. If the rest of you want to continue it until the thread has reached some specific, agreed proposal for decision, then I'd be willing to discuss it with the Tech Leaders for consideration, to use going forward. But from what I've seen over the years on Audacity, some people will consistently revert to their own preferred style. (Some people even switch styles over years, evolving into something quite different.) > [...] >>>> I said I don't disagree about the specifics, just the value of this >>>> discussion. Good arguments exist for all the popular C++ coding styles. >>>> >>>> [...] >> This discussion is not about that kind of extreme, just tabs vs 3 vs 4 >> vs 2 spaces, and where braces appear, for pete's sake. Both discussions >> I think are pointless. > > re: indentation - agree, I assumed existing indentation would be kept. > as for braces, dont think its pointless since it effects how you read > the code and mixing up confuses IMHO. To me that's evidence that coming to agreement would be difficult. > [...] >> I was talking about Audacity code, not the whole world of code. As I >> wrote, depends on the code, *number of devs*, and encapsulation. Python >> has tons more developers than Audacity, so of course its code is more >> widely read. Doesn't apply here, at least not the past few years, >> relative to number of contributors. > > See your point, Though even if only one developer ever reads their own > code, every time you step over it with a debugger or go to make some > small change, you're still end up reading it each time. Yeah, and I think we have had some contributors who've contributed different hunks of code in different styles from their own! >[...] >> I sure don't want to review, or allow to be committed, tens of thousands >> of changed lines of code that vary only by a space. > > Not sure what you mean, are you saying you don't want to review > patches that only reformat? I don't want to review 160k lines of code that somebody *tells* me has only changes to spaces. > > In that case - you need to trust the person doing the work isnt making > functional changes (or if not, make the changes yourself - or be > clever and diff assembler output or so) - of course reviewing that > kind of patch is horrible & poor use of time. Exactly. > [...] >>> Though since it seems Audacity doesn't have clear leadership and is >>> governed by consensus? >> >> Not for code. Not for decisions about direction of the project. >> >> We have the Tech Leaders >> (http://audacity.sourceforge.net/about/credits), and allow commits only >> by review, except for a few developers. >> >> The rest is mostly by consensus, and more so, level of interest/effort. And most of that is on the open list. But I should also have mentioned that there's another level of leadership for Audacity as well. Many of our decisions are reached by discussion among Audacity Team (http://audacity.sourceforge.net/about/credits). All of Tech Leaders are in team, and both categories require significant contribution, and then invitation. >> >> All the issues in this thread have already been decided, prior to this >> re-discussion. >> >> >>> In this case you end up with "Cant agree on everything, do nothing" outcome. >> >> Not the case here. Insulting for you to imply it. > > I didn't mean this to be insulting, its just in my experience - > controversial areas of projects tend to be avoided by developers who > know they will put themselves in the middle of a big argument & open a > can of worms and their changes will have to be justified to others on > the team who disagree. That happens, for sure. Part of the overhead I foresee if we were to do this. But it's not "Cant agree on everything, do nothing". It's that the original primary developer decided to *not* enforce strict or wide-ranging guidelines, the vast majority of contributors have preferred that, and it's been a great benefit to the project. The decision was made, and it's incurred some problems, unquestionably, but more benefit than cost. Overall, putting effort into stricter, more comprehensive code style guidelines would be poor diversion of resources, imo. >>>>> [...] > > Think this can be tacked in a way that its not out of reach - you may > even find some 'lurkers' are willing to foot some of the work. > Also think it can be broken up into small parts - eg, define module > which is a bit of a mess and first make it consistent... finish it and > move on. Well, "lurkers may appear" is no basis for putting effort into this, imo. But go for it, lurkers. > > I'd be happy to help out on this, if some agreement can be made as to > what areas should be worked on. I appreciate that all this is trying to make things better, and I thank you for your effort. I think we have better things to do. Thanks, Vaughan |
From: Leland <le...@au...> - 2013-02-08 22:48:58
|
On Fri, Feb 8, 2013 at 2:01 AM, Vaughan Johnson <va...@au...>wrote: > We've had many developers over the years who participate for a short > (sometimes long, often infrequent) time, then move on, or become > lurkers. (Ahem, like the guy who started this thread, and admitted he'd > diverged from prior style when he contributed -- much love!) > If this is a reference to me, then I was just doing what I thought you wanted...to keep quiet. Your original response was quite clear and nothing more needed to be said. Basically, the Audacity project is flexible, to some extent, when it comes to coding style. Why have you kept the thread alive? It's really simple...don't respond. Leland |
From: Vaughan J. <va...@au...> - 2013-02-09 00:55:28
|
On 2/8/2013 2:48 PM, Leland wrote: > On Fri, Feb 8, 2013 at 2:01 AM, Vaughan Johnson \> We've had many developers over the years who participate for a short > (sometimes long, often infrequent) time, then move on, or become > lurkers. (Ahem, like the guy who started this thread, and admitted he'd > diverged from prior style when he contributed -- much love!) > > > If this is a reference to me, then I was just doing what I thought you > wanted...to keep quiet. Thanks, Leland. I appreciate that, too. >Your original response was quite clear and > nothing more needed to be said. Basically, the Audacity project is > flexible, to some extent, when it comes to coding style. > > Why have you kept the thread alive? It's really simple...don't respond. I kept alive to engage the new posters, who apparently weren't getting what I said in my original response, and diverged into other topics. Sorry it's not more pleasant, but I get frustrated repeating myself and being argued against the same thing. I'm glad you found it clear what I was saying, but yes, I did feed the troll. Thanks, Vaughan |
From: Vaughan J. <va...@au...> - 2013-02-09 00:58:19
|
On 2/8/2013 4:55 PM, Vaughan Johnson wrote: > On 2/8/2013 2:48 PM, Leland wrote: >> On Fri, Feb 8, 2013 at 2:01 AM, Vaughan Johnson > \> We've had many developers over the years who participate for a short >> (sometimes long, often infrequent) time, then move on, or become >> lurkers. (Ahem, like the guy who started this thread, and admitted he'd >> diverged from prior style when he contributed -- much love!) >> >> >> If this is a reference to me, then I was just doing what I thought you >> wanted...to keep quiet. |