Developer guidelines - midspace/SEToolbox GitHub Wiki

Naming conventions:

  • Camel case for syntax.
  • Private class members have prefix _ and next following letter lower case.
  • Method names always start with uppercase.
  • Constants and read-only structs are always with capital letters.
  • Avoid ugly words or short nonsensical words. Your code is visible not just to other developers but to the public also. Try to use descriptive names for variables if possible. They shouldn't be too long, but should still describe its purpose.

Development process:

  • When working on an issue or task, be it investigating, researching, coding, experimenting, assign it to yourself, so everyone else knows you are working on it.
  • If you have finished working on, or are not sure if you can continue working on an Issue, un-assign it to that we know you are no longer working on it.
  • If you have a question about the Issue even if you are working on it, post it to the Issue at hand, so that others can help and contribute.
  • If you are creating a new model, entity, configuration, functionality, etc, make sure to fully document it in code properly with the triple slash ///.
  • If you have changed existing functionality, make sure to update existing code comments. If there aren't any, ADD THEM.
  • Don't rely upon the old code as an official guide. Always try to improve upon new code, as much of the old code was written at a stage when Space Engineers was getting changed aggressively each week and much of the code was changed several times to keep up. And don't try to clean up code as part of your change. Small adjustments here and there are fine.
  • If a code cleanup is required, create an Issue for it as there may be more than just a few lines of code to be rearranged or refactored.
  • Document why you made a particular change in a particular manner either in the check in comments or in the Issues.

Miscellaneous:

One of the core features of SEToolbox is to preserve the save game and never to corrupt it. If you are writing a feature that could possibly corrupt the save game, then take a step back and review how you are going about it and see if there is a different way to approach it without corrupting the save game.

Source control:

  • Only commit stuff that is functional and has been tested.
  • Don't commit code just to try it. Make a branch in source control, as that is what it is there for.
  • Always use the #number when committing code so that it is properly associated. If you make a mistake, add it to the code comments immediately.

Texts:

Currently SEToolbox only officially supports English, but currently 99% of the application has Resource tags to support other languages. Currently there are no other translated versions. We are hopeful for some of the community will help in translating.

To view the application during design time with the local resources, the Configuration must be set to Any CPU. The WPFLocalizeExtension or XAMLMarkupExtensions appears to have issues if the application is set to x64. Otherwise it compiles and debugs fine in Visual Studio in either x64 or Any CPU.

The Satellite resources are grouped into three.

  • SEToolbox/Properties/Resources*.resx are for SEToolbox specific resources.
  • SEToolbox/Properties/MyTexts*.resx are for supporting Space Engineer content for languages that are not officially supported by the game.
  • SEToolboxSetup/Language*.wxl are for the SEToolbox MSI installer.

If you are adding a new text into a control that uses resources, then please follow the convention already in use for naming that Resource.

Ie., Functional Area, Control type, short name of the control's purpose.