Any reason for the line break before the "{"? IMO, it looks ugly and wastes space.FunctionsLookLikeThis(int i_am_a_variable)
{
code...
}
OpenTTD Coding Style and Guidelines
Moderator: OpenTTD Developers
Because that's what the style says. Live with it.
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
It lines up with the } a the other end. You might think it's ugly, and it wouldn't work in a language with LISP-like syntax, but it's the chosen coding style. Changing the coding style with this much code already in the base is never a good idea, so don't pin your hopes on seeing it change. It won't.iNVERTED wrote:Any reason for the line break before the "{"? IMO, it looks ugly and wastes space.FunctionsLookLikeThis(int i_am_a_variable)
{
code...
}
If you dislike it, code in your own preferred manner, then convert it with indent before submitting it.
PGP fingerprint: E66A 9D58 AA10 E967 41A6 474E E41D 10AE 082C F3ED
And we like it. Period.Brianetta wrote:It lines up with the } a the other end. You might think it's ugly, and it wouldn't work in a language with LISP-like syntax, but it's the chosen coding style. Changing the coding style with this much code already in the base is never a good idea, so don't pin your hopes on seeing it change. It won't.iNVERTED wrote:Any reason for the line break before the "{"? IMO, it looks ugly and wastes space.FunctionsLookLikeThis(int i_am_a_variable)
{
code...
}
If you dislike it, code in your own preferred manner, then convert it with indent before submitting it.
Brianetta: indent sucks ass
![Razz :p](./images/smilies/icon_razz.gif)
![Sad :(](./images/smilies/icon_sad.gif)
First of all, it isn't inconsistent, it makes the code more consistent as lines have their own brackets.iNVERTED wrote:Well, that's inconsistent. You never have things like:Brianetta wrote:It lines up with the } a the other end.
*snip*
Second, it exists, I don't know if the (old) OTTD source has this kind of things but TRoS does it that way.
Don't panic - My YouTube channel - Follow me on twitter (@XeryusTC) - Play Tribes: Ascend - Tired of Dropbox? Try SpiderOak (use this link and we both get 1GB extra space)
![Image](https://www.tt-forums.net/download/file.php?id=114248)
OpenTTD: manual #openttdcoop: blog | wiki | public server | NewGRF pack | DevZone
![Image](https://www.icheckmovies.com/signature/76254/100+greatest+sci-fi-small.png)
OpenTTD: manual #openttdcoop: blog | wiki | public server | NewGRF pack | DevZone
![Image](https://www.icheckmovies.com/signature/76254/general-small.png)
![Image](https://www.icheckmovies.com/signature/76254/top+250-small.png)
![Image](https://www.icheckmovies.com/signature/76254/reddit+250-small.png)
![Image](https://www.icheckmovies.com/signature/76254/all+time+box+office-small.png)
![Image](https://www.icheckmovies.com/signature/76254/icm+most+checked-small.png)
![Image](https://www.icheckmovies.com/signature/76254/sci-fi-small.png)
![Image](https://www.icheckmovies.com/signature/76254/100+greatest+sci-fi-small.png)
Huh?XeryusTC wrote:First of all, it isn't inconsistent, it makes the code more consistent as lines have their own brackets.iNVERTED wrote:Well, that's inconsistent. You never have things like:Brianetta wrote:It lines up with the } a the other end.
*snip*
Second, it exists, I don't know if the (old) OTTD source has this kind of things but TRoS does it that way.
In OTTD source, the only place where { goes on a line by itself is in functions. The if/while/whatever all had the { on the same line as the statement. Or maybe my memory just sucks.
![Razz :P](./images/smilies/icon_razz.gif)
Yes, that is consistent. For all functions the braces are on a new line, for all else it's on the same line. Consistent.iNVERTED wrote:In OTTD source, the only place where { goes on a line by itself is in functions. The if/while/whatever all had the { on the same line as the statement. Or maybe my memory just sucks.
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."
it's indeed consistent, but still... yuckDarkvater wrote:Yes, that is consistent. For all functions the braces are on a new line, for all else it's on the same line. Consistent.iNVERTED wrote:In OTTD source, the only place where { goes on a line by itself is in functions. The if/while/whatever all had the { on the same line as the statement. Or maybe my memory just sucks.
![Razz :P](./images/smilies/icon_razz.gif)
Creator of the Openttd Challenge Spinoff, Town Demand patch
After action reports: The path to riches, A dream of skyscrapers
After action reports: The path to riches, A dream of skyscrapers
*smacks forehead*Darkvater wrote:Yes, that is consistent. For all functions the braces are on a new line, for all else it's on the same line. Consistent.iNVERTED wrote:In OTTD source, the only place where { goes on a line by itself is in functions. The if/while/whatever all had the { on the same line as the statement. Or maybe my memory just sucks.
With the addition of C++ code to OpenTTD we will update the coding styles for C++ style constructs (overload, member variable, visibility, parameter, etc.).
Expect an updated opening post in the near future.
Expect an updated opening post in the near future.
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."
Re: OpenTTD Coding Style and Guidelines
Hi!
Found a goto while reading openttds code, so yesterday i searched the code for goto statements.... found 147!!! I hope you all know that using goto produces really really messy and bad bad code. Now there's 3 possibilities:
1. You didn't notice.
2. You don't care about bad code.
3. You don't have time for fixing it.
So, could you tell me which of these applies?![Wink ;)](./images/smilies/icon_wink.gif)
Remember: Knowing what goto does is fine, but do not actually use it!
knuff
Found a goto while reading openttds code, so yesterday i searched the code for goto statements.... found 147!!! I hope you all know that using goto produces really really messy and bad bad code. Now there's 3 possibilities:
1. You didn't notice.
2. You don't care about bad code.
3. You don't have time for fixing it.
So, could you tell me which of these applies?
![Wink ;)](./images/smilies/icon_wink.gif)
Remember: Knowing what goto does is fine, but do not actually use it!
knuff
Re: OpenTTD Coding Style and Guidelines
It's #3 that applies and "if it ain't broke, don't fix it".
Re: OpenTTD Coding Style and Guidelines
None of the above. Gotos are occasionally the best way to do things. Blind adherence to the rules causes code just as bad as blind flaunting of the rules. They even appear in the Linux kernel.Knuff wrote:So, could you tell me which of these applies?
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
Re: OpenTTD Coding Style and Guidelines
For example if you have 3 nested for cycles and you want to break out of two inner levels. Without goto impossible ("break;" will only break one level), or at least impossible without setting some flags and issuing things like if (break_flag) break; at more levels. Which is ineffective. Though these situations hapen relatively rarely.DaleStan wrote:Gotos are occasionally the best way to do things.
If you need something, do it yourself or it will be never done.
My patches: Extra large maps (1048576 high, 1048576 wide) (FS#1059), Vehicle + Town + Industry console commands (FS#1060), few minor patches (FS#2820, FS#1521, FS#2837, FS#2843), AI debugging facility
Other: Very large ships NewGRF, Bilbo's multiplayer patch pack v5 (for OpenTTD 0.7.3)
My patches: Extra large maps (1048576 high, 1048576 wide) (FS#1059), Vehicle + Town + Industry console commands (FS#1060), few minor patches (FS#2820, FS#1521, FS#2837, FS#2843), AI debugging facility
Other: Very large ships NewGRF, Bilbo's multiplayer patch pack v5 (for OpenTTD 0.7.3)
Re: OpenTTD Coding Style and Guidelines
Another case, which actually can be done without any extra variables, is this:
Using a label instead of the while and a goto instead of the continue means I can leave off the whole "while (true) { /*do stuff*/ break; }" thing. Is that insanity really preferable to a goto, Knuff?
Code: Select all
while (true) {
// code
// more code
// with lots and lots of nesting
if (rare_condition_requiring_restart) continue; // This happens maybe 1% of the time.
// still more code
// and some more
break;
}
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
Re: OpenTTD Coding Style and Guidelines
Not to mention if the "rare_condition_requiring_restart" would be nested in some for or while cycles, then the continue won't work, as it will "restart" only the inner cycle. Then you'll need either goto or something really horrible to handle that without goto. I guess goto would be fine in that case :)DaleStan wrote:Using a label instead of the while and a goto instead of the continue means I can leave off the whole "while (true) { /*do stuff*/ break; }" thing. Is that insanity really preferable to a goto, Knuff?
If you need something, do it yourself or it will be never done.
My patches: Extra large maps (1048576 high, 1048576 wide) (FS#1059), Vehicle + Town + Industry console commands (FS#1060), few minor patches (FS#2820, FS#1521, FS#2837, FS#2843), AI debugging facility
Other: Very large ships NewGRF, Bilbo's multiplayer patch pack v5 (for OpenTTD 0.7.3)
My patches: Extra large maps (1048576 high, 1048576 wide) (FS#1059), Vehicle + Town + Industry console commands (FS#1060), few minor patches (FS#2820, FS#1521, FS#2837, FS#2843), AI debugging facility
Other: Very large ships NewGRF, Bilbo's multiplayer patch pack v5 (for OpenTTD 0.7.3)
Re: OpenTTD Coding Style and Guidelines
Really really messy and bad code is produced by programmers, not the goto. Generally people will try to avoid gotos because they can make code harder to read and maintain, but as DaleStan says, occasionally they are the best way to do something.Knuff wrote:I hope you all know that using goto produces really really messy and bad bad code.
I have seen an example of throwing an exception as a means of avoiding the use of a goto. Now that is.. let's say "creative".
"continue" and "break" are effectively restricted goto statements anyway, so not really that much cleaner even if the example hadn't been this extreme.DaleStan wrote:Using a label instead of the while and a goto instead of the continue means I can leave off the whole "while (true) { /*do stuff*/ break; }" thing. Is that insanity really preferable to a goto, Knuff?
When it is not necessary to make a decision, it is necessary not to make a decision - Lord Falkland (1610 - 1643)
Re: OpenTTD Coding Style and Guidelines
It's like anything else, use it badly and it screws things up. Use it badly enough and people avoid it when it should really be used.
As an example, many programmers shy away from PHP because there are so many bad, insecure systems made with it. It's not that PHP is bad, in fact you can build things as good or better than any comparable language, but it's a mental thing.
Gotos, breaks and continues are at times the best way to do something. In functions, if I have the choice of an if(condition) break; twice, or a double nested if-else, I'll take the break.
When working as a community, consistent is more important than right.
As an example, many programmers shy away from PHP because there are so many bad, insecure systems made with it. It's not that PHP is bad, in fact you can build things as good or better than any comparable language, but it's a mental thing.
Gotos, breaks and continues are at times the best way to do something. In functions, if I have the choice of an if(condition) break; twice, or a double nested if-else, I'll take the break.
When working as a community, consistent is more important than right.
Jon
Who is online
Users browsing this forum: Argus and 26 guests