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

Decide on coding style and conventions #21

Open
16 of 21 tasks
trigger-segfault opened this issue Oct 14, 2021 · 0 comments
Open
16 of 21 tasks

Decide on coding style and conventions #21

trigger-segfault opened this issue Oct 14, 2021 · 0 comments
Labels
discussion Some input from team members is wanted. refactor A task that will improve code readability, without changing outcome.

Comments

@trigger-segfault
Copy link
Owner

trigger-segfault commented Oct 14, 2021

OpenLRR is in need of style guidelines, and an accompanied .editorconfig to enforce them.

Along with this, naming conventions should be decided upon. This includes how to handle the 20-year-old naming conventions of the GODS 98 engine, and conventions in LegoRR that are visible through similar practices seen in GODS (i.e. name tables reflect the names of real enum/flag values).

(this issue is a work in progress, and is still being written)


All of this is open for discussion. Please give feedback even if you believe your suggestions to be minor nitpicks.

Entries with an unchecked box, are still mostly undecided. Entries with a checked box and (final), are the only standards not open for discussion

Coding style

General formatting

  • Max line width: ?
  • Tabs or spaces: tabs
  • Indent size: 4 (final)
  • New line type: crlf (final)
  • Text encoding (of files): utf-8 (final)
  • BOM (byte order mark): no (final)

C/C++ formatting

Braces

  • Opening, Definitions: new line
    • Namespaces, functions, types
  • Opening, Assignment blocks: same line
    • Arrays, inline structs, initializer lists
  • Opening, Code blocks: same line
  • Closing keyword, do while: same line
    • Avoids ambiguity with while blocks.
    • Prefer empty line before closing block.
  • Closing keyword, else/catch/etc.: new line

Spacing

  • Between, block keyword/parentheses: yes
  • Between, function (keyword)/parentheses: no
  • Before, Open brace: yes
  • After, Closing brace: yes
  • Before, comma or semicolon: no
  • After, comma or semicolon: yes
  • Between, C-style casts: no

Fluff

  • Comma after final, enum value: yes
  • Comma after final, array definition value: yes
  • Comma after final, struct initializer value: ?
@trigger-segfault trigger-segfault added discussion Some input from team members is wanted. refactor A task that will improve code readability, without changing outcome. labels Oct 14, 2021
@trigger-segfault trigger-segfault pinned this issue Oct 14, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
discussion Some input from team members is wanted. refactor A task that will improve code readability, without changing outcome.
Projects
None yet
Development

No branches or pull requests

1 participant