Is there a standard Coding style for FreePascal (Pascal) available which programmers should use ?
It is for my boss :)

Damien Gerard wrote

Is there a standard Coding style for FreePascal (Pascal) available which programmers should use ? It is for my boss :)

No, there isn't. I follow Borland coding style, but some others don't. You cannot force everyone to use the same style. And you should not.

Michael.

I follow Borland coding style too but we need the same coding style. Thanks. Just to be sure.

Damien Gerard ha scritto:

these are the FPC documents:
http://wiki.freepascal.org/Coding_style
http://wiki.freepascal.org/DesignGuidelines

but since FreePascal is Object Pascal, the Delphi guidelines should be equivalent:

There are a couple of docs in the codegear repository, this is one: http://dn.codegear.com/it/article/10280

Anyway, this nice document is still online:
Delphi 4 Developer's Guide Coding Standards Document http://www.econos.de/delphi/cs.html

try a google search like this: pascal delphi "guidelines", and you will surely find something interesting...

tiziano

Thanks.

Michael Van Canneyt wrote

No, there isn't. I follow Borland coding style, but some others don't. You cannot force everyone to use the same style. And you should not.

That's why we need a editor that supports 'elastic tab stops'. ;-) It's a brilliant idea, but might make your processor work a bit harder (but considering that most CPU's sit at idle 90% of their life, that's not really an issue).

For more information on 'elastic tab stops' see the following website. He has a simple java demo editor showing it in action. http://nickgravgaard.com/elastictabstops/

Regards,
- Graeme -

_______________________________________________
fpGUI - a cross-platform Free Pascal GUI toolkit
http://opensoft.homeip.net/fpgui/

Such schemes have been tried before, but usually fail since that makes source only (practically) editable with one editor, which most users loath. I don't see what's so different about this one.

Also think about e.g. the trouble with RCS, patch systems etc.

I personally would spend my time improving source beautifiers like our own ptop (and you could make them to automatically find these tabstops).

Marco van de Voort wrote

I personally would spend my time improving source beautifiers like our own ptop (and you could make them to automatically find these tabstops).

Waste of time. Automated tools have never worked so far.

Sure, they can turn totally unreadable, terribly formatted code into something more understandable, but they can never *enforce* any kind of coding standard.

At best you can use them as tool to check against given guidelines and spit out a warning where the tool thinks some of the guidelines are violated (things like: "subprograms are not in alphabetical order", "wrong indendation", "comment starts at wrong column").

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).

So what does the tool do? Reformat it to some kind of coding standard like that:

type CPU_Ins = (Add, Sub, Mul, Div, Jnz, Jz, Jnc,
Jc, Call, Ret, Push, Pop, ...)

to destroy the programmer's initial intent - which was to put similar CPU instructions into a single row and also set them out in a tabular way to make them more distinct?

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?

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. At least to my knowledge.

Vinzent.

Okay, but did you actually try the example application to see how it works? I'll explain, as it was a bit confusing for me as well - I could see the point either (in the beginning).

Elastic tabstops saves the files with spaces, NOT tabs. So if you load those files with any editor that doesn't support Elastic Tabstops, they are formatted as normal, using spaces.

If you open that file with a editor supporting Elastic Tabstops if inserts tabstops to keep alignment correct. My inserting tabstops, I mean in the editor window, NOT the source code. It's like editing a document in OpenOffice or Word and using Left or Right Align tabstops. So for Elastic Tabstops to work, you need a editor component which supports tabstops - the Lazarus editor doesn't, so I couldn't implement it. So while you work with the file in the editor, tabstops are inserted, removed or move around to keep text alignment as pretty as can be. But once you save, it inserts the correct amount of spaces to keep that same alignment on file or (preferred) inserts the minimum spaces for standard indentation (Object Pascal uses two spaces for indentation). It doesn't use tab characters. The later option works best when you have people that prefer different indentation levels as the editor will automatically replace the two space indentation with a tabstop in the editor at the correct indentation level.

Version control software can all handle spaces without issue.

Elastic Tabstops works on the *visual appearance* of code in the editor window only, whereas other people tried the visual appears _and_ the saved appearance. Elastic Tabstops is actually a very cleaver idea.

Regards,
- Graeme -

_______________________________________________
fpGUI - a cross-platform Free Pascal GUI toolkit
http://opensoft.homeip.net/fpgui/

This is so easy to accomplish with 'elastic tabstops' (ET). ET is all about keeping alignment of text in columns. Trailing comments, column in code like you shown above etc..Just watch the flash demo of ET or try the Java example (though a bit dated I believe).

ET doesn't do this!

Regards,
- Graeme -

_______________________________________________
fpGUI - a cross-platform Free Pascal GUI toolkit
http://opensoft.homeip.net/fpgui/

Graeme Geldenhuys wrote

alignment as pretty as can be. But once you save, it inserts the correct amount of spaces to keep that same alignment on file or (preferred) inserts the minimum spaces for standard indentation (Object Pascal uses two spaces for indentation).

I still fail to see how it decides between new line of code (same indentation level) and continuation line (exceeded 80 characters on a line). Both case require different indendation.

It doesn't use tab characters.

At least. ;)

But how would it solve

|type
| FooBar = (Foo,
| Bar);

?

The three spaces before FooBar are surely standard indendation (I use three, yes), so I assume it can handle that, but the rest has to be filled up with spaces. So what happens if I insert a "soft" tab after the equal-sign? Would it automatically detect, that "Bar" should be aligned precisely below the "Foo", but without the parentheses?

Vinzent.

No, it ain't.

ET is all about keeping alignment of text in columns. Trailing comments, column in code like you shown above etc..Just watch the flash demo of ET or try the Java example (though a bit dated I believe).

I tried the Java example and the first thing which struck me was this:

|int someDemoCode( int fred,
| int wilma)
^^

To accomplish it's task of detecting tabular design, it inserts tabstops where no tabstops belong.

Tests:

1) If I remove the tab before "int fred", the "int wilma" is not even aligned anymore. Even worse.
2) If I put the tabstop "typographically correct" as it should be (that means: right before the parentheses)[1], it aligns "int wilma", but of course right after the tab stop, so it doesn't start below "int fred", but right below the parentheses. Wrong, again.

And that's what the Eclipse auto-formatter already did for years and the reason why we disabled it.
We simply came to the conclusion, that if we manually format with spaces we'll be typing faster, because we wouldn't have to fight the "tool" anymore.

Further, all this even bites with the "it only saves spaces". If it does in the end, then there's no way to detect where the tabs were supposed to be.

So, as I've mentioned already, that's another tool that fails the task. Not to mention, that I initially talked about automated tools, not mere "editor-plugins", that even seem to even fail on the first try to reload a saved file and display it the same as before I saved it.

Vinzent.

[1] In normal text( you don't write parentheses like that ), do you?

I use Borland style also, but for Tabs i like to convert tabs to 2 spaces for more compatible with other editors, you can read your file in Command Prompt using Type.

There is another code style most care and define it, a rules about it, as like not using GOTO, it is a rule for coding but not a style, for example i hate using Exit in my code i always change it
| if (somthing) then
| exit;
| ...

to

|  if (not somthing) then
|  begin
|    ...
|  end;

Look at the flash demo on the website for an example of this! Lets say gEdit (linux editor) has support for ET.

You would type

type
<tab>FooBar = (<tab>Foo,
<tab>Bar );

That would result in (if you email shows monospaced fonts):

type
   FooBar = ( Foo,
              Bar );

The other nice thing is, it's font independent. You can even use variable width fonts and it will still line up correctly. Whenever you press TAB, it tries to find the closest TabStop (a tabstop is NOT a tab character) normally from the lines before it. Then when you save, it can convert the alignment to spaces.

If the editor fully support ET then you can set the MinimumWidth (defaults to 40 pixels I think) and PaddingWidth (defaults to 16 pixels I think). As you can see it uses pixels and not character widths. ET changes the visual appears in the editor and it does this with editor TabStops and not inserted characters.

As I said, it took me a while to fully understand ET as well. :)

Regards,
- Graeme -

_______________________________________________
fpGUI - a cross-platform Free Pascal GUI toolkit
http://opensoft.homeip.net/fpgui/

Yes, that's what I figured. But that's wrong. Only legasthenic retards[1] put spaces at the inside of parentheses.

type FooBar = ( Foo, Bar );

Yes. And that's precisely what I *DON'T* want: Spaces to break the reading flow.
To be more clear on the subject: Parentheses are not operators, although a lot of people like to treat them so in source code while they miss to put the spaces around the real operators.[2]

The other nice thing is, it's font independent. You can even use variable width fonts and it will still line up correctly.

I know. I've read about this before (I think it was mentioned on the "Embedded Muse" a while ago).

> Whenever you press TAB, it tries to find the closest TabStop (a tabstop is NOT a tab character) normally from the lines before it. Then when you save, it can convert the alignment to spaces.

And when it reloads, everything "semantic" you put in with the tab stops, got lost. Effort wasted, file needs to be reformatted.

As I said, it took me a while to fully understand ET as well. :)

All I understood so far is the same as with all the other tools: If you write your code like a moron to suite the tool, the tool suits you.[3]

To put it more bluntly: Code formatting does not follow strict rules, there are always some heuristics involved.
So even two different formatting of the same code may not violate coding style. Now, a tool can choose whatever heuristic it wants, there *will* be corner cases where the tool will fail, no matter what heuristics it chooses. That's inherent to heuristics. Following stricter rules only leads to harder-to-read code (like the code with the misplaced parentheses).

Vinzent.

[1] No offense, it's not meant personally. But as someone who reads a whole Tom Clancy on a 5-hour train ride, I'm accustomed to a certain style. And that also means, any deviation from that slows me down considerably.
[2] Now that I know whose tool is responsible for that I can go and shoot the author. ;)
[3] Also see [1]. I don't need tools to slow me down.

Depends on you requirements.

Sure, they can turn totally unreadable, terribly formatted code into something more understandable, but they can never *enforce* any kind of coding standard.

Nor does an editor. It can only help. I also think being to focussed on coding standards (to the point of enforcing) is counterproductive.

Then you'll add a tool switch to make enums tabbable. That's actually an easier example than Graeme's original. Positioning comments, specially over block border is what these tools are generally bad at.

Note that this is the first time that I actually saw this enum formatting as an requirement. Do you have a criterium for this?

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.

For me it is mainly meant functional, and a tool suffices. My main gripe with ptop and h2pas are comment positioning. The rest pretty much suffices.

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)

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".

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.

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.

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. ;)

Vinzent.

Vinzent Hoefler wrote

Yes, that's what I figured. But that's wrong. Only legasthenic retards[1] put spaces at the inside of parentheses.

Padding can be adjusted in the editor supports ET customization so you wouldn't see the space.

To be more clear on the subject: Parentheses are not operators, although a lot of people like to treat them so in source code while they miss to put the spaces around the real operators.[2]

I know, Lazarus IDE does (or did) that. I had to tweak my editor settings to get it 'right'.

And when it reloads, everything "semantic" you put in with the tab stops, got lost. Effort wasted, file needs to be reformatted.

Nope, on reopening the file, formatting is exactly like it was the last time you edited it.
As for slowing you down. Using your code example, you would have had to type many spaces to align the code. ET would only need one keystroke. And as you insert more code in line above or below, all columns will shift together, whereas using spaces, you would manually have to realign all your columns. ET would bu much faster it that case.

Either way, Lazarus (which is my favourite programming editor) internal editor doesn't support TabStops, so I can't implement ET anyhow.

Regards,
- Graeme -

_______________________________________________
fpGUI - a cross-platform Free Pascal GUI toolkit
http://opensoft.homeip.net/fpgui/

Well, "require" or not is relative to begin with.

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.

Well, I'd say group of source files yes. And I wouldn't bother with it in the first place (which is the point with making it an artform).

The only exception that I make is if the source is your actualy product (if you sell components with source, or publish FPC RTL).

And e.g. FPC already has a metafile per sourcefile in the documentation, so having some formatting options there is not _THAT_ strange. Verbatim (don't touch) is then also an option.

(not that I plan to add this anytime soon)

Also to be checked in into version control in case the source file somehow changes and its formatting configuration needs to be adjusted.

That's the big advantage of doing it automatedly. You only do it periodically (e.g. on a big release), and for the rest you don't enforce, but just keep it minimally readable by hand.

Well, that is the problem indeed. You WANT too much :-)

Per enum decision to tabbed or not is not simple. If it requires human interpretation, it is not simple (and worse, will lead to differing opinions in a Team and possible style-wars).

That is btw also the reason why I tend to choose some tool, configure it once, and then declare it gold as far as configuring goes. And also discourage purely style guide related commits/thunks. If it ain't broke, then don't fix.

Everybody can check what the tool produces for themselves, end-of-discussion. Aspirant sourcecode-artists in my team can pick up painting in their own free time.

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... ;)

And worse, no person either, if you have several.

See above. I despise in-source metadata, which is why I like fpdoc so much.

Yes. But I go for the 80%, not the 100% in this case. And safe 50% in discussion in the process.

In other words: Sexy code is easier to understand. ;)

If you are attracted to THAT kind of sexy alone. Tastes vary.

I would see it in "vi", for example. No use to me, I often have to work on a plain console with no fancy UI. (That's the reason why I hate lines longer than 79 chars.)

And hell, once I'm starting to format code for a specific editor, I might as well start using binaries which are interpreted and turned into code by an editor which supports the "binary tabbed" feature. (Yes, I know, I'm exaggerating now. But I've had this kind of discussion many times already, so I'm kind of tired of it. Each time I proved the tool could be tricked to do something I didn't want it to do, he tweaked the options again (then the tool simply failed at a different location), or he tried to convince me to change my coding style to suit the tool's needs. Then I explained him that a tool is something that I want to work /with/, not /against/.

I doubt that. As far as I can see, the semantics is all in the tabs and if it does convert the tabs into spaces prior to saving the file, it will simply lose the semantics and may - at best - start guessing again.

As for slowing you down. Using your code example, you would have had to type many spaces to align the code.

Actually, no. What kind of editors are you using? Any decent editor stays in the column where the previous line begins, so after the second line I only need to press enter and I'm right there.

ET would only need one keystroke.

No. It wouldn't know where I want to align it. How? I'd need another keystroke a line before already. That means, my brain even needs to type ahead. No problem there, but if you want to count keystrokes...

In the end it's probably the same with or without "ET". Once I'm in the right column, I still only press Enter to jump to the next line (properly aligned already).

And as you insert more code in line above or below, all columns will shift together, whereas using spaces, you would manually have to realign all your columns.

Then you have the wrong editor. In my editor I can shift in or out any selected block as I want to.

So, all things you describe would be possible (or even faster) with those magic "elastic tabstops" - I am doing already without them.

And before we get carried away to much, as long as you use your single favourite editor, ET doesn't matter (except when you want to use proportional fonts for source code). Most, if not all indentation magic an editor does today, works with tabs, and spaces, or without them, no matter if those tabs are elastic, plastic or hard as a pen^Wstone.

The only difference seems to me, that without tabs the source code still looks the same, no matter if I look at it in "vi", "gedit", "kate", or "notepad". Once you start using tabs this isn't guaranteed anymore...

Vinzent.

Let me rephrase it: A tool would have destroyed information if it would have reformatted such code. That's simply not tolerable.

Well, I'd say group of source files yes. And I wouldn't bother with it in the first place (which is the point with making it an artform).

Well, it doesn't need an artist, it needs disciplined developers.

That's what the guy told us, too. It never worked out. Coders wrote code, checked it into CVS and it came out differently. The didn't even know their own code anymore, just five seconds after they committed it.

You only do it periodically (e.g. on a big release), and for the rest you don't enforce, but just keep it minimally readable by hand.

That's what an editor is for. It helps you to keep the general coding style by "suggesting" how to layout the code, but it should not force you. It should allow you to deviate from the usual rule - if that's justified (of course, *this* is a human decision). Running automated tools over the code destroys the information put in there exactly *by* deviating from the rule. If I did that, I did it for a reason.

Oh, common sense is too much already? :D

Per enum decision to tabbed or not is not simple.

Yes, it is: If it's done that way, it's probably meant to be that way, so don't touch it. The tool may check if the colums are correctly aligned then, though. ;)

But in no case it should reformat it.

If it requires human interpretation, it is not simple (and worse, will lead to differing opinions in a Team and possible style-wars).

As I said, code is for humans. If it doesn't require human interpretation it's probably auto-generated and then I don't care about the formatting. If humans come in contact with the code, it should be formatted for humans. The computer doesn't care about the number of spaces, blank, or comment lines... and it doesn't even care about the actual meaning of the code.

That is btw also the reason why I tend to choose some tool, configure it once, and then declare it gold as far as configuring goes.

And my previous paragraph is the reason, why I would never auto-format any code. I may use some tool to "preformat" code (code coming from a third-party using a totally different coding style or some terrible, historically grown, legacy code), but I would never try to destroy the original intend of the developer.

And also discourage purely style guide related commits/thunks. If it ain't broke, then don't fix.

If it's not understandable, it's broke.
If it clearly violates an important guide-line of the coding-style, it's broke.

Code is not only pure functionality in terms of bits and bytes. It's an intend expressed by someone.

Everybody can check what the tool produces for themselves, end-of-discussion. Aspirant sourcecode-artists in my team can pick up painting in their own free time.

It doesn't have to do with art. It's fricking documentation.

Well, as long as they obey the rules...

So why need the tool? If you can't trust the developers to maintain a certain style, how trustworthy is their code?

> In other words: Sexy code is easier to understand. ;) If you are attracted to THAT kind of sexy alone. Tastes vary.

I did it on purpose. Usually a discussion gets more attention after sex has been thrown into it. ;)

Vinzent.

I tried the example in action and its awefull.

I tried this:

if x = 1 then begin<TAB>// my comment on ifs
<TAB>y:= 2;<TAB>//yes y gets 2
end;

this was NOT what I wanted - to make it "better" i changed to:

if <TAB>x = 1 then begin<TAB>// my comment on ifs
<TAB>y:= 2;<TAB>//yes y gets 2
end;

not nice eighter - I am to stupid for those smart elastic tabs.

cheers,

Adrian.

Let me rephrase mine too, is it a requirement to have such code meta information in your system?

For me it is only a base readability line, but I have no desire what so ever to go into detail.

> Well, I'd say group of source files yes. And I wouldn't bother with > it in the first place (which is the point with making it an artform). Well, it doesn't need an artist, it needs disciplined developers.

If you find one, please notify me. Somehow developers can only be disciplined on schemes they thought up themselves.

Well, I never said I put it in a post commit event. I just do (did is a better word, currently I'm on my own again) it regularly by hand with an automated tool. Usually on what a human judges is a junction in the development ( a major release, addition of a major subsystem etc). Some files might be excepted from the process etc.

The developers are supposed to keep it basically readable, and periodically the automated tool over it catches their glitches, and erases artwork and other mistakes. This also means that a new developer can start without too much instruction (put begin and end always on a new line, indent two spaces, camel case identifiers but don't over do it, and don't do hungarian notation except for form components and exceptions. Ok, you can start now. If they have Delphi experience, it usually doesn't even generate questions)

The editor is primarily to get work done. Amelioration is a cost factor, and it should be minimized. Most of the gains are in the simplest of things

Yes. But there are two, maybe three reasons I don't want that, at least not in normal business code:

- the endless feuding over what constitutes the proper style (including writing complete books over coding style that nobody ever reads, except the person that wrote it in the first place)
- People constantly correcting minor glitches in style and committing those, poluting the RCS history.
- In general, don't spend too much time on style. Better invested on actual code quality commenting and readability than in how it is formatted.

Yes. Common sense is to variant amongst people. It is usually just a way to make "I'm right" sound like "we all agree on this"

_If_ I really encountered such a remote case, I'd extract it to an .inc (something so perfect warrants an own file), and exclude it from the automatic run, and assign its maintenance to one single person.

Yes. But you seems to assume that the amount of time invested in making it readable is linear with the benefit you get from it. It isn't.

If humans come in contact with the code, it should be formatted for humans

So? Why can't machine generated output not be human readable? I assume you have read text where the wordwrapping, hyphenation and linebreaking is done by a machine instead of a human? Why? Because a machine does a way more consistent job.

[snip]

Well, they will. The first two days.....

To have a clear baseline, and to not get caught up in continuous style fixes. The automated tool will get it at the end of the period anyway.

It is a requirement that the code should as self-explainable as possible, yes.

For me it is only a base readability line, but I have no desire what so ever to go into detail.

Ok, let me show you a real life example of "deviations from the rule":

1)
|   Ksi := Ksi + self.Weight[Pred (Layer), j, k] *
|                self.Value[Pred (Layer), j];
2)
|   Ksi := Ksi + self.Weight[Pred (Layer), j, k] *
|          self.Value[Pred (Layer), j];

What is more readable? Usually the next line should be aligned, true, but with the operator precedence the first variant just makes more sense.

If you find one, please notify me. Somehow developers can only be disciplined on schemes they thought up themselves.

No, they're usually disciplined on schemes they found senseful. That's different.

Well, that's what he tried to do to us. And not even because he was the senior software engineer, but because he happened to be the server admin.

Of course, the source code quality didn't match up. If you know that your code gets destroyed once you commit it, you don't take much care to do it right.

I just do (did is a better word, currently I'm on my own again) it regularly by hand with an automated tool.

As I expressed already: I have nothing against tools *checking* given guide-lines. But in the end it's the developers responsibility to follow those.
So if the developer decides to let the tool reformat his code and manually tweak those couple of lines where the tool gets it wrong, it's ok.

The developers are supposed to keep it basically readable, and periodically the automated tool over it catches their glitches,

It's not a glitch if code is laid out to be better understandable:

A matrix based filter calculation as written by the developer:

|Summe :=
|      Prev_D^[i - 1] + 2 * Prev_D^[i] +     Prev_D^[i + 1] +
|  2 * Cent_D^[i - 1] + 4 * Cent_D^[i] + 2 * Cent_D^[i + 1] +
|      Next_D^[i - 1] + 2 * Next_D^[i] +     Next_D^[i + 1];

The same code raped by "ptop" with default config:

|Summe :=
|         Prev_D^[i - 1] + 2 * Prev_D^[i] +     Prev_D^[i + 1] +
|         2 * Cent_D^[i - 1] + 4 * Cent_D^[i] + 2 * Cent_D^[i + 1] +
|         Next_D^[i - 1] + 2 * Next_D^[i] +     Next_D^[i + 1];

The whole layout is totally lost. Its definitely not readable anymore.

Work is done with paper and pencil. :P

Amelioration is a cost factor, and it should be minimized. Most of the gains are in the simplest of things

And as only 10% of a software project involves actually writing code, there's not much optimization potential here, anyway.

Being able to read the code is much more important after all.

Yes. But there are two, maybe three reasons I don't want that, at least not in normal business code:

See the example above. It's not about the decision if you should two, three, or four spaces or rather use tabs, or if the line length should be limited to 72, 80, 127, or even 4095 chars or if you put spaces around parentheses or not. Those are details you get accustomed to more or less (although it pays to not deviate too much from normal written text).

The point is: if I already have trouble reading code, how much trouble would I have actually understanding it?

- People constantly correcting minor glitches in style and committing those, poluting the RCS history.

Oh come on. History can be filtered. And I'd rather have a "typo and coding-style fixed" commit only, than this typo and code-style fix commited *together* with a totally unrelated change.

This does not only pollute the history, it pollutes the diff which is much more important.

- In general, don't spend too much time on style. Better invested on actual code quality commenting and readability than in how it is formatted.

You would wonder how much quality *can* be in formatting.

You're kidding. Such cases aren't even remote.

And you seem to assume that the time I am spending on formatting code actually matters. Even if it's 10% of the time I am spending on writing code, it's only 1% of my total development effort. But it may benefit 10 or 20 developers reading the code, which may save them a lot more than the time I spend making the code.

Most people seem to forget that software development is about yourself writing the code. That's wrong. It's about the psychopath hired after you, who inherited your code and knows where you life. If you write your code with that in mind, it'll be good. ;)

> If humans come in contact with the code, it should be formatted for > humans So? Why can't machine generated output not be human readable?

Call it experience. Usually it isn't:

|   String value[] = null;
|   int _len0 = istream.read_long ();
|   value = new String[_len0];
|   for (int _o1 = 0;_o1 < value.length; ++_o1)
|      value[_o1] = istream.read_string ();
|   return value;

Not even if it would have been properly formatted. So why bother?

I assume you have read text where the wordwrapping, hyphenation and linebreaking is done by a machine instead of a human? Why? Because a machine does a way more consistent job.

Oh really? And that's why it took D.E.Knuth took 20 years to develop TeX? Because it's all so fricking "easy"?

And it will occasionally destroy beautiful, perfect code on its course.

Vinzent.

Vinzent Hoefler wrote

The only difference seems to me, that without tabs the source code still looks the same, no matter if I look at it in "vi", "gedit", "kate", or "notepad". Once you start using tabs this isn't guaranteed anymore...

I hope this will be my last reply. Please take a look at the flash video on the ET website. There he uses two editors (gvim and gedit). And for the last time, tabs are NOT insert tabs into the source code - when you press the TAB key the editor creates a TabStop. TabStops are like what you get in OpenOffice or MS Office for aligning text. As the flash example on the ET website shows - once you save, it replaces the tabstops with spaces so that if you had to open it with another non-ET enabled editor, alignment would still be correct.

I've had better conversations with a rock. ;-) Either way, every developer for himself. Use the tools you prefer, it's your right!

Regards,
- Graeme -

_______________________________________________
fpGUI - a cross-platform Free Pascal GUI toolkit
http://opensoft.homeip.net/fpgui/

Graeme Geldenhuys wrote

I hope this will be my last reply. Please take a look at the flash video on the ET website.

I don't have flash, so I am bound to check out the Java example.

There he uses two editors (gvim and gedit).

With appropriate plugins/scripts, I suppose.

Yes, that's what I figured. What I don't get is how the editor extracts the information _back_ from the file after the "tabstop" information has been deleted (that's what it does once it gets replaced with spaces).

All this fuzz is of no use if you can't restore the information from the file.

IOW, how does it know that I set tabstops at those locations marked with <TS>

|function Foo<TS>   (const A :<TS>String) :<TS>Integer;
|function Foobar<TS>(const B :<TS>String) :<TS>Integer;

after it has been replaced with

|function Foo (const A : String)
|function Foobar (const B : String)

For me there's no way telling anymore. But probably this editor is so much smarter than a rock.

Vinzent.

On 21/01/2008, Vinzent Höfler wrote:

I'm breaking my own promise and replying again... :)

> I hope this will be my last reply. Please take a look at the flash > video on the ET website. I don't have flash, so I am bound to check out the Java example.

Ask a friend, it's worth seeing..

> There he uses two editors (gvim and gedit). With appropriate plugins/scripts, I suppose.

I guess, though his gedit plugin doesn't work with the latest gedit anymore. It seems gedit changed some or other API call (what I can gather from the console output error message).

Yes, that's what I figured. What I don't get is how the editor extracts the information _back_ from the file after the "tabstop" information has been deleted (that's what it does once it gets replaced with spaces).

I don't know! It just does! :-) Actually on a serious note, it uses pixel calculations based on the ET parameters you can specify: MinimumWidth, PaddingWidth etc... When viewed with a ET enabled editor, the text might shift by a few pixels (not spaces) but all alignment will still be intact. It's just that clever! :)

Regards,
- Graeme -

_______________________________________________
fpGUI - a cross-platform Free Pascal GUI toolkit
http://opensoft.homeip.net/fpgui/

Imo that plugin discussion is pretty useless. I'am coding in at least four different editors pascal (fp ide, joe, lazarus, ultraedit) and I fear there is no plugin for all editors I use :)

Florian Klaempfl wrote

Imo that plugin discussion is pretty useless. I'am coding in at least four different editors pascal (fp ide, joe, lazarus, ultraedit) and I fear there is no plugin for all editors I use :)

Same here, although the editors' names are a bit different. ;)

Vinzent.

Hmm. That either means it stores additional information about the file (something that also needs to get versioned then - which is problematic given that this data may even be plugin/editor specific) or it uses some heuristics based on the file/language. As it is the case with all heuristics it can go wrong - and Murphy dictates if it can, it will. So I don't know if it's of so much use unless I start using proportional fonts just for the fun of it. ;)

Vinzent.

Zitat von Vinzent Hoefler :

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

And what about math functions? Is "f (x)" more typographically correct than "f(x)"? ;-)

mm

Due to the lack of differently spaced spaces, yes. ;)

However, the function name and the parameters should also be visually distinct, so the former variant is to be preferred.

Especially if we start the tabular layout again, then
|function Random (l : LongInt) : LongInt;
|function Random (l : Int64)   : Int64;
|function Random               : Extended;

looks better than

|function Random(l : LongInt) : LongInt;
|function Random(l : Int64)   : Int64;
|function Random              : Extended;

because in the first variant there's a clear visual distinction between the function name and the parameter name.

But, either variant is still superior to "f( x )".

Vinzent.