Zitat von Vinzent Hoefler <[EMAIL PROTECTED]>: > On Monday 21 January 2008 13:54, Marco van de Voort wrote: > > > On Monday 21 January 2008 11:59, Marco van de Voort wrote: > > > > > > > Nor does an editor. It can only help. I also think being to focussed > > on coding standards (to the point of enforcing) is counterproductive. > > > > > As an example where most tools just put out nonsense, consider this: > > > |type > > > | CPU_Ins = (Add, Sub, Mul, Div, > > > | Jnz, Jz, Jnc, Jc, > > > | Call, Ret, > > > | Push, Pop, > > > | ...); > > > > > > Now, as you can see, the instructions are laid out tabular (a lot > > > of tools [yes, including "elastic tabstops"] I've seen so far are > > > unable to handle even that simple case). > > > > Then you'll add a tool switch to make enums tabbable. That's actually > > an easier example than Graeme's original. > > Oh, come on. What if you encounter an enum that does *not* require > such "tabbing" inside the same source file. > > Of course you can do it all configurable until the tool formats as you > would like it to format, but in the end this leads to one tool > configuration per source file. Also to be checked in into version > control in case the source file somehow changes and its formatting > configuration needs to be adjusted. > > > Note that this is the first time that I actually saw this enum > > formatting as an requirement. Do you have a criterium for this? > > I didn't say, it's a requirement. But I don't want a tool to reformat > code, which has been explicitely logically ordered for readability, a > better overview over the instruction set, and for easier extensionby > the coder. > > > > And even if the tool is a bit more intelligent and detects the > > > tabular design, how is it supposed to know which instructions are > > > more similar to the other and should appear in a row and which ones > > > not? > > > > If you make coding standards an artform, you'll need an artist. > > No. A simple set of rules is sufficient. The only problem with those > simple rules is that they can bend and there's no tool yet which knows > how far it may bend the rule for formatting a certain piece of > code... ;) > > The first universal rule is that the code needs to be readable. This > overrules any other rule anyway. > > > The only exception I can see is documentation, but then you'll need > > meta info to the formatter. Either in source, or out source > > (unitname.enumx.style:=tabular or something in some metafile) > > Yeah, great. Just like /*INDENT-OFF*/ in each and every C-source file > I've ever checked into the company's CVS before we threw out the whole > auto-formatting on check-in. > Ok, GNU-indent is probably not the best auto-formatter (in fact, it's > one of the worst I've ever seen), but you get the idea, I suppose. > > > > Code is primarily written for humans. Otherwise we wouldn't care > > > about the formatting. Interestingly, to format code properly you'd > > > need to understand it. And that's something that currently only a > > > human can do. > > > > Depends on your definition of "properly". > > There's only one: You need to easily understand it when you read it. > Even if you read it 10 or 15 years after it has been written. And > contrary to popular beliefs, there's a substantial amount of visual > appearance involved. > > In other words: Sexy code is easier to understand. ;)
That's true on a pascal list. Other languages care less. It seems, pascal programmers are people preferring readable code - not only when they write pascal. If I understand the thread correct, it is about 'a formatter is needed' and 'no formatter is perfect'. IMO the solution is context sensitivity: A formatter should not have one set of rules, but at least two. Some rules should be enforced and some should only be applied if manually started. For example: A hard rule could be: The line after a 'begin' should have at least the indent of the 'begin' line. A extra rule could be: The line after a 'begin' should be indented 2 spaces. The hard rule could be applied, when text is pasted. The extra rule is only applied if the user selects some text and uses the IDE function 'beautify selection'. And the rules must be project/package and language specific. Mattias _______________________________________________ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
