The curse of Dennis D. Spreen

> helps the seahawks win the Super Bowl (done)

if all would be that easy 🙂

What about those of us with a reading disability? I have overcome my problems with reading – but i typically break long sections of text into smaller chunks. This makes some programmers very “observant” of my code, as it looks more like C# or C++.
But i agree about the “if (something then begin”, that makes it so hard to analyze and understand large procedures (spaghetti code)

The IDE allows reformatting to your own (better readable) style, but when it comes to commiting your sources to a team server you should reformat them (by CTRL-D on a separate IDE for example) to the standard style before commiting – so you have your own style on your IDE but the others still have the standard code style.

And who sets this standard? Is it only valid for Embarcadero Delphi? Or does it cover FreePascal as well? What about Oxygene? Where can I find a document containing an “official standard” regarding, for example, passing closures? My XE5 likes to mess up stuff like TThread.CreateAnonymousThread(..).

Just declaring what your current IDE outputs after pressing CTRL+D seems a bit too easy for me. Arguing about whether a “begin” should be preceeded with a linebreak is like arguing whether to use tabs or spaces for indentation. The most important thing about a coding standard is that everybody involved sticks to it. And I strongly believe that when a team develops their very own coding style, there’s nothing wrong with it. So in the end: Yes, there is personal choice involved.

There is a DELPHI standard (I am not speaking about Oxygene or FPC) – which is defined by Embarcadero. Where? Take a look at the VCL sources. Take a look at the (rather old) code style doc on edn. Why should a Delphi Team follow the EMB-code style? Well, as I said: don’t your ever need to read the VCl sources? You have a hard time reading those if you’re used to read your own code style. Yes it is very easy to say “press ctrl-d” and that’s it. If the reformatter won’t work because of fluent interfaces, etc. and you have to reformat your source manually that’s quite ok. It’s the idea behind the code style: do not create your own, because there is already a standard. New team members have a hard time if you set a code style quite different to the standard (I’m not talking about minor changes, but indentation, spacing before and after variables and procedure calls/parameters and the position of “begin” and “end” is not a minor change for example).

Understood. But I honestly cannot accept the current Delphi RTL or VCL sources as a prime example of how you should format your sourcecode. I think a lot of that stuff is not readable at all. I’m probably too focued on the code itself rather than the formatting and the style itself.

Coming from C++ and Java, I have such a burning hatred for the omission of parentheses if a method has no parameters, it’s probably on the verge of a behavioural problem. We’re using camelCase, not PascalCase. And so on. I honestly do not consider strictly following a semi-official styleguide critical. To cut it short: Personally, I do not agree.

The “official” sources are horrible to read though I have to admit a lot of that is probably caused by the load of IFDEFS and bad code itself. We have adjusted to a formatting style that is way closer to the way everybody uses languages like C# or Java: camelCase for fields, PascalCase for properties (and freaking parentheses for methods!).

Cheers.

Hear, hear! I used to be a very vocal evangelist about some very specific code styles. Nowadays I just use what’s standard and can be forced on a team. Ctrl-D for me everywhere!

(Well, except when I use fluent interfaces.)

@Salmo: very interesting. I am using C# and C++ as well, and I’ll switch my code style while using that languages – in the very beginning I’ve written some macros which allowed me using BEGIN and END in C code, just because I was that used to see these as code block boundaries. But that was a looong time ago, and I have learned that you can adopt *any* code style even if you have used something very different for years – just try it and some “ugly” standard code will look quite normal after some weeks and you won’t ever return to your own style again.

@Leonardo: thank you!