Page 1 of 3

OpenTTD Coding Style and Guidelines

Posted: 23 May 2004 10:00
by ludde
Coding Style can be found at http://wiki.openttd.org/Coding_style.

Posted: 31 Oct 2005 15:04
by Brianetta
What's the style for loops? I'm assuming it's like that of if in the example above. Am I correct?

Posted: 31 Oct 2005 22:59
by Darkvater
Brianetta wrote:What's the style for loops? I'm assuming it's like that of if in the example above. Am I correct?
yes.

Code: Select all

for (i = 0; i != 10; i++) {
  bla;
  bla;
}

Posted: 18 Nov 2005 11:06
by Graphite
I think the style for switch-statements is still missing, which seems a rather important one to me because that's one that can be done in many different ways.

Posted: 15 Feb 2006 03:14
by Buggi
I'm partial to blocking my code as it was intended...

Code: Select all

if (*v->Blahness() == Blah())
{
  *v->Jiggles++;
}

That way stuff really is "blocked" as it should. Plus the extra linebreak and carriage return doesn't bloat the filesize. :wink:

Posted: 15 Feb 2006 05:58
by DaleStan
I'm partial to blocking my code as it was intended...

Code: Select all

if(a)for(b=0;b<10;i++)while(c){doit();dootherthing();}
And the saved vertical space means that you can get so much more code on a single screen.

This is why we have a coding style. It helps forestall holy wars. And, unless you want to reformat something like 10 MB of source, the current style is the way it will stay.
Even if you do reformat all the code, I still don't think the style will change.

Posted: 15 Feb 2006 18:33
by Brianetta
Dalestan, I'm sure you could have saved still more space on the semicolon near the end.

Buggi, if the coding style really bugs you, and you can't work with such offensive style rules, you can always use indent with two sets of rules. One to format the code so that you like working on it, and one to change it back to the OpenTTD style before you commit changes/submit patches/whatever.

Posted: 15 Feb 2006 21:22
by hertogjan
DaleStan wrote:(...)
And the saved vertical space means that you can get so much more code on a single screen.
(...)
But that is not necessarily a benefit. Books aren't printed over the full width of the paper because it would be hard to read otherwise (instead you will see a "wall of words"). Some people have shown that the ideal width of a line is about 70 characters. If it is longer or shorter, it is harder to read. For the same reason, newspapers use columns.
Making computer code more compact may cause the legibility to decrease. The use of line wrapping and indentation will make the code more readable. Overuse of those things will destroy legibility again. So you have to find some ideal line length.
Your example could be part of a "wall of computer code".

Posted: 15 Feb 2006 23:54
by Brianetta
* Brianetta hands hertogjan a replacement sarcasmometer

Yours seems to be failing.

Posted: 16 Feb 2006 00:38
by Buggi
I seem to be on the receiving end of most of Dale's anger these days. :(

Posted: 16 Feb 2006 09:10
by DaleStan
I'm afraid I tend to get angry when people suggest that OTTD should lose support for one of my two favourite programming languages.
Or even when I think that people want OTTD to quit supporting that language.

It really didn't help that the first post I specifically noticed was yours was this one. I now see it wasn't intended this way, but my luser-o-meter went off, and first impressions are hard to break. You're doing quite well at forcing me to adjust my opinion (in this case, that's a good thing); keep it up.

Posted: 16 Feb 2006 10:30
by bobingabout
i don't think OTTD should stop support of newGRF, even if what i said makes it saound that way, but i do think the 32bpp stuff might need a bit more of a kick than newGRF supports.

Posted: 16 Feb 2006 13:20
by Brianetta
How would the graphical bit depth affect the "kick" of newgrf?

Posted: 16 Feb 2006 13:25
by bobingabout
because its actually 34bits, because you require a 32bpp image and a 2bpp CC overlay, which means each sprite requires 2 seperate images.

Posted: 16 Feb 2006 13:29
by Brianetta
Still not sure why you need to handle it any differently from the 8 bit graphics. I was under the impression that newgrf was fairly agnostic toward bit depth and graphics format. Anyway, this is dragging a fairly important sticky off topic, and there are already some threads covering this subject.

Posted: 08 Apr 2006 08:01
by Darkvater
*updated starting post with 'coding guidelines'

Posted: 14 Jul 2006 13:35
by DaleStan
I don't see anything mentioned here about using

Code: Select all

enum {
  FOO = 0,
  BAR = 1,
  BAZ = 2,
  END = 3
};
instead of

Code: Select all

enum {
  FOO,
  BAR,
  BAZ,
  END
};
Most of the enums I've seen in the OpenTTD source are in the former format, not the latter. I can see lots of disadvantages to the former, but no advantages, and the use of the former format has caused bugs that would be complete non-issues were the explicit values not present.

Is it just a matter of someone sitting down with grep, removing all the explicit values, and posting a patch on Flyspray, or is there some reason that the enums must have explicit values?

Posted: 14 Jul 2006 13:43
by richk67
DaleStan wrote:Is it just a matter of someone sitting down with grep, removing all the explicit values, and posting a patch on Flyspray, or is there some reason that the enums must have explicit values?
I think there are occasions where explicit enums are better; eg. in any list where the value is saved (airport heading states being one). However, yes, in general non-explicit enums are better.

The bug you link to is an awkward one for enumeration; not every item in the graphic list has an enumerated value. So the enumerated values jump with fairly large gaps between them. (These correspond to values in station_land.h). It was a typo, nothing more.

Posted: 14 Jul 2006 14:16
by DaleStan
So just use the explicit values where they are needed, and leave all the others out. If typos can be eliminated by removing code, then I'm of the opinion that said code should be removed posthaste.

Even if only END loses its explicit value, that acheives most of the desired result, while still making it difficult to break the savegames by inserting a value in the middle of the list.

Posted: 22 Aug 2006 09:58
by TrueBrain
Coding Style have been slightly altered. Please do pay attention to them.