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
>> <vaughan@...> wrote:
>>> On 2/4/2013 11:16 PM, Campbell Barton wrote:
>>>> On Tue, Feb 5, 2013 at 5:47 PM, Vaughan Johnson
>>>> <vaughan@...> 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"
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
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.
> 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
> 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
>> 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.
>> 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
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.
> audacity-devel mailing list