What Delphi coding standards document(s) do you follow?

Question

What Delphi coding standards document(s) do you follow?

Our company is looking at putting some better coding standards in place, to improve our code’s readability, reviewability, and maintainability. We’ve come across CodeGear’s “Object Pascal Style Guide”, but it hasn’t been touched in quite a while and I imagine a number of people have made some local improvements or additions. I’ve come across some published variations and other documents, which I will list, below.

NB: I do not want to start a style war. I just want to know what standards you follow, and why.

Thanks.

---

UPDATE: Well, the "JCL Delphi Language Style Guide" seems to be the clear winner! Thanks!

Answer 1

CodeGear’s “Object Pascal Style Guide”

http://edn.embarcadero.com/article/10280

Answer 2

JCL Delphi Language Style Guide

(An extension of CodeGear’s “Object Pascal Style Guide”)

http://jcl.delphi-jedi.org/documents/styleguide.html

(Thanks, Jeroen Pluimers, for noticing that the original borland.com link had died and for providing the new link.)

Answer 3

JVCL-extended version of CodeGear’s “Object Pascal Style Guide”

(This looks just like the JCL version, to me.)

http://jvcl.delphi-jedi.org/StyleGuide.htm

(Thanks go to Jeroen Pluimers, for providing the new link.)

Answer 4

Econos – Coding Standard Document

(Subtitled “Delphi 4 Developer's Guide Coding Standards Document”.)

http://www.econos.de/delphi/cs.html

Answer 5

CodeGear’s “Hungarian peanut butter”, for naming identifiers

http://dn.codegear.com/article/27983

Answer 6

About.com’s “Delphi Identifier Naming Conventions”

http://delphi.about.com/od/standards/l/bldnc.htm

Answer 7

It really doesn't matter as long as you pick one and stick to it. A coding standard is like a dialect, and as long as everyone on the team speaks the same dialect, you're fine.

That said, why not pick the same standard as your runtime library (VCL) and documentation use? Then you will all be speaking the same dialect and you will have an easier time reading the runtime library code. And there are plenty of code examples to illustrate coding conventions.

Answer 8

There can be a tendency to over-engineer coding standards to the point where they get in the way of writing code.

I agree with Jozz’s comment. You can look at all the recommended standards, pick one and force it upon your coders or you can get your team involved in the process.

In my experience, the best way to get a team engaged is to have the team come up with the idea and the benefits of adoption. Your existing talent is your best resource. Likewise, they can be your ultimate enemy if you force them down a path they don’t buy into.

So, take a look at your existing coding variants and get the team together for some vibrant discussions on:

• The reasons for adopting a coding standard.
• Essential considerations in standardization.
• Surfacing any insecurities in the team surrounding this issue.
• Finding a point of agreement. What's important and what's not.
• Establishing some corporate objectives so everyone feels like they are working towards a common goal.
• Get the team to sell the benefits of standardization to themselves.

The most important objective must be to establish a ‘standard’ that best serves your team and your company.

Answer 9

For some inane historical reason, the coding standard at my work is to have all keywords in uppercase, in both delphi and sql. Thank god for caps lock.

Answer 10

As if it's hard to forget, for classnames it's always