OpenTTD Coding Style and Guidelines
Moderator: OpenTTD Developers
OpenTTD Coding Style and Guidelines
Coding Style can be found at http://wiki.openttd.org/Coding_style.
http://sf.net/projects/openttd/
Post all your patches and feature requests here.
Post all your patches and feature requests here.
yes.Brianetta wrote:What's the style for loops? I'm assuming it's like that of if in the example above. Am I correct?
Code: Select all
for (i = 0; i != 10; i++) {
bla;
bla;
}
TrueLight: "Did you bother to read any of the replies, or you just pressed 'Reply' and started typing?"
<@[R-Dk]FoRbiDDeN> "HELP, this litte arrow thing keeps following my mouse, and I can't make it go away."
<@[R-Dk]FoRbiDDeN> "HELP, this litte arrow thing keeps following my mouse, and I can't make it go away."
I'm partial to blocking my code as it was intended...
That way stuff really is "blocked" as it should. Plus the extra linebreak and carriage return doesn't bloat the filesize.
Code: Select all
if (*v->Blahness() == Blah())
{
*v->Jiggles++;
}
-Buggi
Programmer and TTD fan...
Programmer and TTD fan...
I'm partial to blocking my code as it was intended...
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.
Code: Select all
if(a)for(b=0;b<10;i++)while(c){doit();dootherthing();}
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.
To get a good answer, ask a Smart Question. Similarly, if you want a bug fixed, write a Useful Bug Report. No TTDPatch crashlog? Then follow directions.
Projects: NFORenum (download) | PlaneSet (Website) | grfcodec (download) | grfdebug.log parser
Projects: NFORenum (download) | PlaneSet (Website) | grfcodec (download) | grfdebug.log parser
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.
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.
PGP fingerprint: E66A 9D58 AA10 E967 41A6 474E E41D 10AE 082C F3ED
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.DaleStan wrote:(...)
And the saved vertical space means that you can get so much more code on a single screen.
(...)
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".
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.
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.
To get a good answer, ask a Smart Question. Similarly, if you want a bug fixed, write a Useful Bug Report. No TTDPatch crashlog? Then follow directions.
Projects: NFORenum (download) | PlaneSet (Website) | grfcodec (download) | grfdebug.log parser
Projects: NFORenum (download) | PlaneSet (Website) | grfcodec (download) | grfdebug.log parser
- bobingabout
- Tycoon
- Posts: 1850
- Joined: 21 May 2005 15:10
- Location: Hull, England
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.
JPG SUX!!! USE PNG!!!
There are times when JPG is useful, TTD screenshots is not one of them. Please use PNG instead.
[/url]
There are times when JPG is useful, TTD screenshots is not one of them. Please use PNG instead.
[/url]
- bobingabout
- Tycoon
- Posts: 1850
- Joined: 21 May 2005 15:10
- Location: Hull, England
because its actually 34bits, because you require a 32bpp image and a 2bpp CC overlay, which means each sprite requires 2 seperate images.
JPG SUX!!! USE PNG!!!
There are times when JPG is useful, TTD screenshots is not one of them. Please use PNG instead.
[/url]
There are times when JPG is useful, TTD screenshots is not one of them. Please use PNG instead.
[/url]
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.
PGP fingerprint: E66A 9D58 AA10 E967 41A6 474E E41D 10AE 082C F3ED
I don't see anything mentioned here about using
instead of
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?
Code: Select all
enum {
FOO = 0,
BAR = 1,
BAZ = 2,
END = 3
};
Code: Select all
enum {
FOO,
BAR,
BAZ,
END
};
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?
To get a good answer, ask a Smart Question. Similarly, if you want a bug fixed, write a Useful Bug Report. No TTDPatch crashlog? Then follow directions.
Projects: NFORenum (download) | PlaneSet (Website) | grfcodec (download) | grfdebug.log parser
Projects: NFORenum (download) | PlaneSet (Website) | grfcodec (download) | grfdebug.log parser
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.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?
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.
OTTD NewGRF_ports. Add an airport design via newgrf.Superceded by Yexo's NewGrf Airports 2
Want to organise your trains? Try Routemarkers.
--- ==== --- === --- === ---
Firework Photography
Want to organise your trains? Try Routemarkers.
--- ==== --- === --- === ---
Firework Photography
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.
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.
To get a good answer, ask a Smart Question. Similarly, if you want a bug fixed, write a Useful Bug Report. No TTDPatch crashlog? Then follow directions.
Projects: NFORenum (download) | PlaneSet (Website) | grfcodec (download) | grfdebug.log parser
Projects: NFORenum (download) | PlaneSet (Website) | grfcodec (download) | grfdebug.log parser
Who is online
Users browsing this forum: No registered users and 46 guests