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@iem.at
http://lists.puredata.info/listinfo/pd-dev