[PD-dev] Pd code formatter?

[Yves Degoyon]

blah, blah, blah, blah

i don't feel the pd convention was so good in many senses :

* all this blah blah ( and 10 papers from MB that leads to nothing,
except publicity for Desire Data, worst name ever
in software history and still not available and working )

* pddp, cool, one documentation for all,
exatcly whay we don't care about,
and miller's documentation is the real one.

* pd montreal abstractions? what about kinshasa? terrassa and
ouagadougou ?

yeah, pd was nice when it was free of normalisation and b*******

sevy

Mathieu Bouchard wrote:

> On Thu, 27 Sep 2007, Sergei Steshenko wrote:
>
>> I think automatic reformatting is the only way - unless a project 
>> wants too repell developers.
>
>
> 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.
>
> 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.
>
> 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.
>
>> For example, I understand my own code only if it formatted my way;
>
>
> 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.
>
>> whenever I inherit code from somebody else in order to understand it 
>> I first reformat it my way.
>
>
> 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.
> If you don't do this when doing your reformatting, you are missing an 
> important opportunity.
>
>> So, automatic reformatting upon check in is the only way to reconcile 
>> different
>> styles without forcing developers to write the code in an unnatural 
>> for them way.
>
>
> This only applies if you don't put information in the formatting itself.
>
> 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.
>
> Formatting standards prevent this kind of diagrammatic approach.
>
> e.g.
>
> void  floatinlet_float( t_inlet *x, t_float   f) {*(x->u.floatslot) = f;}
> void symbolinlet_symbol(t_inlet *x, t_symbol *s) {*(x->u.  symslot) = s;}
>
> (I hope that this appears as two lines and not four... i tried hard to 
> show something that wouldn't wrap around)
>
> 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).
>
>  _ _ __ ___ _____ ________ _____________ _____________________ ...
> | Mathieu Bouchard - tél:+1.514.383.3801, Montréal QC Cana
> da
>
>------------------------------------------------------------------------
>
>_______________________________________________
>PD-dev mailing list
>PD-dev at iem.at
>http://lists.puredata.info/listinfo/pd-dev
>  
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-dev/attachments/20070928/0029b4aa/attachment.htm>