Xtce build follow up: make updates on closed PR #72

[GFMoraga]

Summary

This is a way to track the progress of updating the xtce files and parsing tools

Completed

• [x] We need to add pandas, openpyxl to poetry dependency list: added to dependencies, and not optional dependencies.
• [x] Made a new directory called 'tools' under the 'imap_processing', as well as 'tools/xtce_generation' which will house the files to make xtce
• [x] Fix linting issues
• [x] Moving docstrings around to be compliant with PEP257/numpydocs
• [x] Adding said documentation to the imap_processing docs (as well as any other outward-facing docs we want to add)
• [x] Utilizing** classes, config files, or argument parsing to abstract out parameters from the code
• [x] Make the code more generalized, generally speaking
• [x] Squash merge commits
• [x] Create for loop for each row in lengthInBits column and use that to create IntegerParameterType. That way, if there are int sizes greater than 32 or unique values after that, they would get created.
• [x] Fix Matthew's code suggestion on the ".org/space/xtce"

Requirements

The more specific the better.

• Review closed PR #72

Related tickets

72

[GFMoraga]

@bourque I copied your comment from the PR as a starter. I will go back and edit/update.

[bourque]

Thanks @GFMoraga. I am also happy to help out with some of this!

[GFMoraga]

@maxinelasp can you suggest names for classes? Or do you think these are fine? I am working on this comment:

"It is best practice to have the main function be really small and call out to other methods (IMO). Ideally, this would look something like:"

df = parse_excel_file(filename) header = generate_header() integer_parameter_types = generate_integer_parameter_types() codice_parameters = generate_codice_parameters() tree = generate_xml_tree(df, header, integer_parameter_types, codice_parameters) tree.write(...)

[GFMoraga]

@tech3371 how do I do this? "We need to add pandas, openpyxl to poetry dependency list" in poety.toml?

[maxinelasp]

Make sure your names are clear, with spelled out names (per the style guide). Ideally, it should be clear what the class is without other developers needing to read any documentation or comments. If you're having trouble describing a class in 2-3 words, that is a sign the class is too complicated and may need to be split down further.

Here's an interesting discussion that might help. Naming things is difficult and annoying 😆

[maxinelasp]

You can also look at space_packet_parser for examples of class names/structure.

[maxinelasp]

Also, per your poetry question, I will write up a document about using poetry which we can use as a start.

[GFMoraga]

Sounds good! I will take a look, and yes, naming things, I am learning is harder than I thought!

[tech3371]

@GFMoraga I found this book very helpful. I read first few chapters. Chapter 2 talks about how to name functions well. I hope it helps. https://github.com/jnguyen095/clean-code/blob/master/Clean.Code.A.Handbook.of.Agile.Software.Craftsmanship.pdf