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

Remove dead code and clean up formatting #2

Open
HunterZ opened this issue Apr 3, 2022 · 2 comments
Open

Remove dead code and clean up formatting #2

HunterZ opened this issue Apr 3, 2022 · 2 comments

Comments

@HunterZ
Copy link
Owner

HunterZ commented Apr 3, 2022

There's a bunch of dead code in the codebase:

  • Commented / #ifdef'd out stuff
  • Porting hacks/variations for platforms I no longer want to support
  • Unused macros/methods/variables?

Also need to get down to one common implementation that supports Windows, Mac, and Linux, with no/minimal macrobatics. This means leaning on BearLibTerminal for I/O as much as possible, and trying to stick to ANSI C as much as possible for everything else (file I/O etc.).

@HunterZ
Copy link
Owner Author

HunterZ commented Apr 4, 2022

Formatting and style guide:

Basic text formatting:

  • no tabs anywhere, only spaces
  • 2 spaces per indent level
  • try to line wrap around 76-ish characters

Basic code formatting:

  • use only slash-star /*...*/ comment style
  • curly braces on their own lines as a general rule
  • try to align stuff for readability where practical

Flow control formatting/structure:

  • always use curly brace blocks under while/if/etc. if they contain multiple lines of indented code under them (original codebase would nest a loop inside another loop, and not use braces under the outer loop - no!)
  • if a while/if/etc. contains only one line, prefer putting them on the same line if they'll fit together
  • use curly brace blocks with a one-line else following a multi-line if and vice versa, etc.
  • check the positive condition first in an if...else, to avoid the else being a double-negative
  • avoid unnecessary else blocks around code that follows an if block ending in a break/continue/return statement
  • use break/continue/return where possible to avoid unnecessary else blocks
  • goto is long out of vogue, so try to avoid/eliminate it

Loop/increment/decrement semantics:

  • prefer counting up to counting down, especially when zero is one of the boundaries (as this may only be safe with signed types)
  • prefer pre-increment/decrement (++i) to post-increment/decrement (i--)

Pointer/array semantics:

  • prefer array semantics to pointer increment/decrement for readability

Code structure:

  • prefer reusable functions to code duplication
  • prefer checking sad-path up-front and bailing out early versus nesting happy-path ifs
  • define local variables at the beginning of functions
  • provide one blank line between local variable definitions and the start of a function's actual logic

Variables/types:

  • setting default variable values is encouraged (maybe want to revisit this as a cleanup item), but nontrivial values should be set where they're used versus up-front
  • avoid spaces between casts and what they apply to
  • (revisit? not my preferred style) pointer type designator asterisk * goes next to the variable name, not the type (exception: *const because there's no alternative)

Functions:

  • (revisit if pedantic compiler warnings appear?) don't use (void) to swallow return values - it makes the code overly verbose
  • use const arguments where possible

Macros:

  • prefer #ifdef to #if defined() when checking a single macro condition
  • prefer #if...#elif...#else...#endif to nesting when possible

@HunterZ
Copy link
Owner Author

HunterZ commented Apr 5, 2022

Regarding ANSI C:

  • Update function signatures from K&R to ANSI style, including header prototypes.
  • Try to move away from POSIX-heavy stuff and towards ANSI C stuff as much as possible, as Windows support of POSIX API is dicey at best.
  • Can't really get away from access() for now, but it's pretty compatible and simple on Windows.
  • It's kind of silly, but I want to avoid C99, C++, etc. for now (maybe on a later pass through the codebase, during or after Restructure the codebase #3).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant