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

Clean-up packet printing code in APRSsharp Program.cs #103

Open
4 tasks
CBielstein opened this issue Jan 13, 2022 · 1 comment
Open
4 tasks

Clean-up packet printing code in APRSsharp Program.cs #103

CBielstein opened this issue Jan 13, 2022 · 1 comment
Labels
code cleanliness Refactors, static analysis, etc. enhancement New feature or request

Comments

@CBielstein
Copy link
Owner

CBielstein commented Jan 13, 2022

Description

The code in Program.cs around handling and printing out packets needs some cleaning up. There's a decent amount of copy and paste, the position encoding isn't human readable, gridsquare printout doesn't print the right number of characters for the accuracy in the position object.

There are many ways of fixing this. A few potentials:

  • This could go all the way to implementing interfaces on the packet info field objects for each property (e.g. IPositionPacket and ITimestampPacket) and then just printing if the interface is implemented. That would be a really clean way to reduce duplicating logic on common properties. Though would require large refactors. Potentially beneficial to other client types (e.g. UI apps).
  • Alternatively, extension/helper methods to put the UI string printing to each (e.g. public static PrintPacket(this WeatherStatus packet).
  • A case could be made for overriding .ToString() on each packet type, though that risks mixing UI logic with application logic.

Potentially this is a mix of those methods.

This is split off of #80.
Related to, but different from, #118.

Acceptance Criteria

  • Output is clean and human readable
  • Code for printing packets has reduced copy/paste repeats
  • Code for printing packets is extensible for future packet types
  • Tests, as appropriate
@CBielstein CBielstein added enhancement New feature or request good first issue Good for newcomers code cleanliness Refactors, static analysis, etc. labels Jan 13, 2022
@CBielstein
Copy link
Owner Author

Split the content about configurable error logging levels to #118.

@CBielstein CBielstein removed the good first issue Good for newcomers label Apr 13, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
code cleanliness Refactors, static analysis, etc. enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

1 participant