<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
<title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
blah, blah, blah, blah<br>
<br>
i don't feel the pd convention was so good in many senses :<br>
<br>
* all this blah blah ( and 10 papers from MB that leads to nothing,<br>
except publicity for Desire Data, worst name ever<br>
in software history and still not available and working )<br>
<br>
* pddp, cool, one documentation for all,<br>
exatcly whay we don't care about,<br>
and miller's documentation is the real one.<br>
<br>
* pd montreal abstractions? what about kinshasa? terrassa and<br>
ouagadougou ?<br>
<br>
yeah, pd was nice when it was free of normalisation and b*******<br>
<br>
sevy<br>
<br>
Mathieu Bouchard wrote:
<blockquote
cite="midPine.LNX.4.64.0709271236590.12064@paik.artengine.ca"
type="cite">On Thu, 27 Sep 2007, Sergei Steshenko wrote:
<br>
<br>
<blockquote type="cite">I think automatic reformatting is the only
way - unless a project wants too repell developers.
<br>
</blockquote>
<br>
The main branch of Pd must be repelling people in another way, because
not that many changes are made by non-Millers, and they all have like 5
years of experience using Pd.
<br>
<br>
And even then, if any aspect of the code repels people, it's not
necessarily negative. If five aspects of *my* code repel people, but
mostly the same people in each case, and I assess that there's at least
one aspect that I won't change no matter what, then there is not much
incentive to "fix" any of those other four, especially if there are
various downsides to adapting to those programmers.
<br>
<br>
Then I would also have to assess how much those programmers can
contribute anything worthwhile if they have several principles that
reduce their own productivity (e.g. "macros are evil") and that also
reduce mine.
<br>
<br>
<blockquote type="cite">For example, I understand my own code only if
it formatted my way;
<br>
</blockquote>
<br>
This is extremely unflexible of you. I use a quite special formatting
for my own code, but I quite routinely read other people's source code
in a variety of formattings (more different formattings than what many
programmers would usually tolerate...). I used to hate reading code,
for various reasons, but it's counterproductive, even when the code is
redundant or dumbly formatted.
<br>
<br>
<blockquote type="cite">whenever I inherit code from somebody else in
order to understand it I first reformat it my way.
<br>
</blockquote>
<br>
This is because the act of reformatting leads you to read source code
that otherwise you wouldn't feel compelled to put your eyes on. I know
that phenomenon and I applied this technique to myself, but I went
farther than reformatting: I removed unused variables and made various
simplifications.
<br>
If you don't do this when doing your reformatting, you are missing an
important opportunity.
<br>
<br>
<blockquote type="cite">So, automatic reformatting upon check in is
the only way to reconcile different
<br>
styles without forcing developers to write the code in an unnatural for
them way.
<br>
</blockquote>
<br>
This only applies if you don't put information in the formatting
itself.
<br>
<br>
The formatting of the code is an important opportunity to make things
more obvious. For example, some people would spread two simple similar
functions over 15 lines just to follow a standard, but it's possible
that i'd found that they'd fit in 2 lines (1 line each) and that by
inserting spaces in the right places you would see exactly what's the
difference between the two lines and what's repetitive.
<br>
<br>
Formatting standards prevent this kind of diagrammatic approach.
<br>
<br>
e.g.
<br>
<br>
void floatinlet_float( t_inlet *x, t_float f) {*(x->u.floatslot)
= f;}
<br>
void symbolinlet_symbol(t_inlet *x, t_symbol *s) {*(x->u. symslot)
= s;}
<br>
<br>
(I hope that this appears as two lines and not four... i tried hard to
show something that wouldn't wrap around)
<br>
<br>
The formatting of the above code emphasises that both functions are
very similar in structure and that the differences between the two are
thin. This is the kind of information that does not "jump to the eye"
in any kind of standard formatting. Indeed, it looks to me like
standard formattings are specifically designed to prevent things from
being that obvious (but I believe that the actual reasons are more
complicated).
<br>
<br>
_ _ __ ___ _____ ________ _____________ _____________________ ...
<br>
| Mathieu Bouchard - tél:+1.514.383.3801, Montréal QC Cana<br>
da<br>
<pre wrap="">
<hr size="4" width="90%">
_______________________________________________
PD-dev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:PD-dev@iem.at">PD-dev@iem.at</a>
<a class="moz-txt-link-freetext" href="http://lists.puredata.info/listinfo/pd-dev">http://lists.puredata.info/listinfo/pd-dev</a>
</pre>
</blockquote>
<br>
</body>
</html>