We know how you love XML! ;)

.hc

On Sep 26, 2007, at 12:00 PM, marius schebella wrote:

oops, sorry for my last mail, did not get what you were talking about... marius.

Miller Puckette wrote:

...

My settings are: tabs are 8 spaces indents are 4 spaces but to make things easier I always expand out tabs when releasing code; this is done with a shell script using the wonderful and (I think) universally available "expand" program. HC's tabs are hardwired to 4 spaces (old Next style, apparently still in use somewhere :) so to use HC's code I first run "expand -4" on it. Oh yes, in the latest CVS upload there are still 8-character tab stops in one file, u_main.tk, which I forgot to include in the detabbing script. I fixed the script since. cheers Miller On Wed, Sep 26, 2007 at 11:26:31AM -0400, Hans-Christoph Steiner wrote:

...

Hey all,

Has anyone ever tried to use indent or some tool to reformat code to match Miller's code formatting? It would be good to have a standard code format, and since the one that Miller uses it difficult to configure with many editors and non-standard, it would be quite useful to have some automated tool to make sure everything is in order.

.hc

---

---

You can't steal a gift. Bird gave the world his music, and if you can hear it, you can have it. - Dizzy Gillespie

---

PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev

---

PD-dev mailing list PD-dev@iem.at http://lists.puredata.info/listinfo/pd-dev

------------------------------------------------------------------------ ----

I spent 33 years and four months in active military service and during that period I spent most of my time as a high class muscle man for Big Business, for Wall Street and the bankers. - General Smedley Butler

Ah, ok, I didn't notice the switch. I've originally used the default Emacs settings for the indent. Now I think I now use stroustrup, because it was the closest to Miller's style that I found.

i generally avoid tabs in my source files with the following before-save-hook: (defun clean-code() "Remove trailing spaces, turn tab into spaces" (when (memq major-mode '(c-mode c++-mode emacs-lisp-mode python-mode)) (delete-trailing-whitespace) (untabify (point-min) (point-max))))

(add-hook 'before-save-hook 'clean-code)

if you then set c-basic-offset to 4 you are almost there ...

hth, tim

-- tim@klingt.org ICQ: 96771783 http://tim.klingt.org

Linux is like a wigwam: no windows, no gates, apache inside, stable.

On Wed, 2007-09-26 at 22:33 +0200, Frank Barknecht wrote:

Hallo, Tim Blechmann hat gesagt: // Tim Blechmann wrote:

...

...

Ah, ok, I didn't notice the switch. I've originally used the default Emacs settings for the indent. Now I think I now use stroustrup, because it was the closest to Miller's style that I found.

i generally avoid tabs in my source files with the following before-save-hook:

In vim it's called "set expandtab" in .vimrc

I *think* to get what Miller describes, the full vim settings would be:

set tabstop=8 set softtabstop=4 set shiftwidth=4 set smarttab set expandtab

If anyone wants to impose a formatting 'standard' on the Pd sources, why not just include the relevant editor commands at the bottom of the sources:

/* vim: ts=8 sts=4 sw=4 st et */ /* -*- Mode: C; c-basic-offset: 4 -*- */

...or whatever the right commands happen to be. I know not everyone uses vim or emacs, but this seems a useful way to indicate coding style.

Jamie

On Sep 26, 2007, at 5:51 PM, Mathieu Bouchard wrote:

On Wed, 26 Sep 2007, Hans-Christoph Steiner wrote:

...

Has anyone ever tried to use indent or some tool to reformat code to match Miller's code formatting?

As long as one level of indentation is more to the right than the enclosing level, formatting isn't so much of a big deal. What's a big deal is people who use multiple different interpretations of the tab character in the same file. Afair, this happened in devel_0_39 quite a bit.

...

It would be good to have a standard code format, and since the one that Miller uses it difficult to configure with many editors and non-standard

Miller's indentation style is pretty commonplace, and his brace placement is even more commonplace. I don't mean that I think that it's good to use it in general, but as long as you want to submit patches to Miller, yes, that's the one to use for sure.

...

it would be quite useful to have some automated tool to make sure everything is in order.

Personally I don't think that automatic formatting is good when it comes to communicating code between people who use the formatting to carry meaning; but between people who want to cancel the potential meaningfulness of formatting, an automatic formatter is the perfect tool, as you can't get any extra information out of anything completely predictable.

Having common code formats is standard practice in any well organized projects (check the Linux and GNU standards for examples). Many have it done autmoatically when you check your code in to the repository.

.hc

_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal QC Canada

------------------------------------------------------------------------ ----

Access to computers should be unlimited and total. - the hacker ethic

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

On Thu, 27 Sep 2007, Sergei Steshenko wrote:

1. if no formatting is enforced on a project, nobody is repelled, since

everybody has the possibility/freedom to write code the way he/she likes;

No, they can be repelled by the formatting that is already used in the project, and they have at least to keep existing code formatted the same way, because reformatting will be frowned upon at least to the extent that you do it as part of a cvs commit that is about something else than reformatting. I mean, if you use your own reformatter on whole files, you will have to undo its effect on the already existing code after you modify the code and before you submit, yes?

2. if formatting is considered necessary, it'd better be done automatically

in order not to repell contributors who prefer a different formatting style.

I consider formatting to be rather close to necessary and yet I employ a style of formatting that isn't close to being supported by any automatic formatting tool. I'm not sure when I will ever try to make a tool for it, but it isn't that likely that I'll ever try. That said, if someone sent me a diff that uses a different formatting, I wouldn't reject it (at least not for that reason!).

And, by the way, I have nothing against macros.

Excellent.

_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal QC Canada

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

On Wed, 26 Sep 2007, Hans-Christoph Steiner wrote:

On Sep 26, 2007, at 5:51 PM, Mathieu Bouchard wrote:

...

Personally I don't think that automatic formatting is good when it comes to communicating code between people who use the formatting to carry meaning; but between people who want to cancel the potential meaningfulness of formatting, an automatic formatter is the perfect tool, as you can't get any extra information out of anything completely predictable.

Having common code formats is standard practice in any well organized projects (check the Linux and GNU standards for examples). Many have it done autmoatically when you check your code in to the repository.

Yeah, I'm sorry, I don't know why I started talking about that, I could have guessed that you would be all about standards of other projects and not really enjoy talking about a communication theory of source code.

_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal QC Canada

On Thu, 27 Sep 2007, Hans-Christoph Steiner wrote:

Standardization is part of communications theory. If there are no common rules, then the structures are meaningless, except to the person who wrote those particular rules.

On one side you have rules of interpretation, which guide the way in which a meaning is encoded as a structure and a structure is decoded into a meaning, whereby the author has a choice and that the choice is assumed meaningful or capable of meaning;

On the other side you have rules of writing that leave no choice to the author other than whether to follow the rule or not, and in which the only meaning is whether the author respected the rules or not. Supposing that the author is required to follow the rules, there is no choice at all, so there cannot be any information within that choice.

"English" is a pretty well established standard, with lots of rules about formatting, indenting, etc.

Presuming that formatting does not include the basic semantic concepts of "a space", "a punctuation mark", "left-to-right" and "top-to-bottom", the formatting of the document is there to reinforce existing information, not to add any new one. In itself, if the "no choice" rules are followed, the formatting can be recreated from the basic formatting-less version of the text. To make the formatting essential, you'd have to remove enough critical information from the text so that the formatting becomes the only way to figure out that information, and then it wouldn't be "just" formatting anymore.

What I am advocating is more on the same level as using bold and italic to emphasise selected parts of the text. It's not the same kind of formatting, it's formatting with a choice, it's informative formatting. However I express this as special spacing, because that is the most visually effective tool for conveying that meaning; and that conflicts with the "no choice" formatting normally in use.

Is that clearer?

_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal QC Canada