[PD-dev] Pd code formatter?

[Mathieu Bouchard]

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 Canada