Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Refactoring of Vehicle::AddToShared/RemoveFromShared and OrderList::AddVehicle/RemoveVehicle #5029

Closed
DorpsGek opened this issue Jan 30, 2012 · 5 comments
Labels
flyspray This issue is imported from FlySpray (https://bugs.openttd.org/) patch from FlySpray This issue is in fact a Patch, but imported from FlySrpay

Comments

@DorpsGek
Copy link
Member

Rhamphoryncus opened the ticket and wrote:

This is a refactoring of Vehicle::AddToShared/RemoveFromShared and OrderList::AddVehicle/RemoveVehicle. Specifically, the former are removed in favour of the latter. This lets OrderList manage more of the linked list it exists for.

Comments:
I wavered on style of single-statement if-statements. In the end I used the form I preferred, which of course might not be preferred for the rest of the codebase.

Vehicle didn't like me friend'ing individual methods in OrderList, I think due to a header conflict (I was probably doing something wrong), So I friend'd the whole OrderList class instead.

Vehicle::FirstShared irks me. It should always be the first vehicle in the chain, so the only reason it seems to use this->First() is to avoid const-casting this for the return value.

Testing has been limited. It passes "make test", but I haven't put any play time in.

Attachments

Reported version: trunk
Operating system: All


This issue was imported from FlySpray: https://bugs.openttd.org/task/5029
@DorpsGek
Copy link
Member Author

michi_cc wrote:

OpenTTD coding style is at http://wiki.openttd.org/Coding_style. You should avoid changing existing code, especially if it is properly formatted like in OrderList::RemoveVehicle().


This comment was imported from FlySpray: https://bugs.openttd.org/task/5029#comment10839

@DorpsGek
Copy link
Member Author

Rhamphoryncus wrote:

That came across a little harsh. I made the function consistent with itself, but since only a single line wasn't rewritten by me that means matching the style I felt looks best.


This comment was imported from FlySpray: https://bugs.openttd.org/task/5029#comment10840

@DorpsGek
Copy link
Member Author

michi_cc wrote:

Okay, yes. Still doesn't change the fact that anything going into trunk has to confirm to trunk coding style.


This comment was imported from FlySpray: https://bugs.openttd.org/task/5029#comment10842

@DorpsGek
Copy link
Member Author

Rhamphoryncus wrote:

I knew that already. I mentioned it because I expected it'd be something to fix.


This comment was imported from FlySpray: https://bugs.openttd.org/task/5029#comment10843

@DorpsGek
Copy link
Member Author

andythenorth closed the ticket.

Reason for closing: Won't implement

Mass closure of patch tickets with no commentary for >5 years. Goal is to reduce patch queue as an experiment to see if it aids faster reviewing and rejection/acceptance (it may not). If this offends you and the patch is maintained and compiles with current trunk, discuss with andythenorth in irc. (andythenorth has no ability to review patches but can re-open tickets).


This comment was imported from FlySpray: https://bugs.openttd.org/task/5029

@DorpsGek DorpsGek added Core flyspray This issue is imported from FlySpray (https://bugs.openttd.org/) patch from FlySpray This issue is in fact a Patch, but imported from FlySrpay labels Apr 7, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
flyspray This issue is imported from FlySpray (https://bugs.openttd.org/) patch from FlySpray This issue is in fact a Patch, but imported from FlySrpay
Projects
None yet
Development

No branches or pull requests

1 participant