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.

Sign up for GitHub

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

Jump to bottom

Toolshed coding conventions #210

Open
wants to merge 1 commit into
base: master
Choose a base branch
from
Open

Toolshed coding conventions #210

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
18 changes: 18 additions & 0 deletions src/en/general-development/codebase-info/conventions.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -420,6 +420,24 @@ For things such as DoAfter, always use events instead of async.
Async for any game simulation code should be avoided at all costs, as it's generally virulent, cannot be serialized (in the case of DoAfter, for example), and usually causes icky code.
Events, on the other hand, tie in nicely with the rest of the game's architecture, and although they aren't as convenient to code, they are definitely way more lightweight.

## Toolshed

### Code structuring
Toolshed commands should always be defined under a `Toolshed` subdirectory and namespace.

### Naming
- Always suffix toolshed command classes with `Command`.
Example: `PlayerCommand`, `StationCommand`
NOT: `PlayerCommands`, `PlayerToolshed` ...

- Toolshed commands that have subcommands should always be singular form.
Example: `station:list`
NOT: `stations:list`

- Toolshed commands should be all lowercase without underscores.
Example: `station:largestgrid`
NOT: `station:largest_grid`, `station:largestGrid`
Comment on lines +437 to +439
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

can we fix everything to use snake_case instead for readability reasons, thanks.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I agree snake_case would help with readability. I based these conventions of what was more common, since I only found a single case of a command being snake_case.

Toolshed currently uses all lowercase when autogenerating command name from the class name, so this would have to be changed, along with renaming all subcommands and updating docs.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I agree snake_case would help with readability. I based these conventions of what was more common, since I only found a single case of a command being snake_case.

Toolshed currently uses all lowercase when autogenerating command name from the class name, so this would have to be changed, along with renaming all subcommands and updating docs.

yes, i know what toolshed does; i wrote it and I was wrong and would much prefer we fix that.


## UI

### XAML and C#-defined UIs
Expand Down
Loading