[PD-dev] Refactoring Pure Data (2 of 2)

[Vincent Lordier]

>
> >> > An explicit name saves the dev brain power at coding time ;)
> >> I assert that often it doesn't. A name shouldn't be more explicit than it
> >> needs to be,
> > Quote from Wikipedia on software quality
> > => http://www.gnu.org/prep/standards/standards.html#Names
>
> yes, according to that page, "Local variable names can be shorter, because
> they are used only within one context". So, what's your point?
>
> > => http://en.wikipedia.org/wiki/Hrair_limit
>
> Exactly: if it's too long, one identifier may occupy the mind more than it
> could, and thus it isn't really optimal.
>


Mathieu, it's all about compromises : what's "good" practice will
hopefully last, what's not will eventually die.
Only real life experience tells us. It's still good to look at other's
practices, standards, and conclusion, but nobody should dictate to the
others what to do here. It's an open source project, we can take it
wherever we want.

Code quality standards try to define what is "good" code. Here, it's
up to us to define what's good to us.
And since we won't reinvent the wheel or write some ISO doc, we'll
just let many hands get on the code, and many eyes read it, alter it,
test it, manipulate it, reuse it.

So for now, I guess we should simply be able to "open" pd's internal
developments to see some kind of Darwinism happening on pd's code and
architecture...
Then, what's "optimal" will emerge by itself IMO.

I proposed a lead for a solution to make the developments faster and
better : breaking vanilla into independent modules. It'll be a long
process, but I hope it'll be adopted in the long run.

Since vanilla is mostly in Miller's hands right now, I sort of asked
him to delegate control on parts of code he wouldn't work on in the
coming year, and let others add value to what already exist...

So it's basically up to Miller to let the development process change,
so we can propose improvements.
If not, then I guess I'll join the growing group of discouraged ones,
eventually.
devel_ is the good place for experimentation, as long as it can be
merged to main easily, and that means we need to make modifications in
vanilla first, so it's actually possible to work on devel_ easily.


++