Difficult to read roles::test-utils::mining-device in single file

[rrybarczyk]

The roles::test-utils::mining-device crate has all of its logic in a single file. There are several data types and standalone functions in this file. It can be overwhelming for a user to read in this format. After #1163 is merged, this crate should be modularized into multiple files for clarity.

• Each data type and impl in its own file
• Make sure all imports are imported at top of file instead of directly referenced in the logic
• Rust doc comments
• Add some clarity to README.md (explain how to start the local pool to get the crate to work)

[Fi3]

Each data type and impl in its own file

nack if we start blindly following it we will end up with millions of file and things will be much harder to understand (not to talk about import and exports). A module can contains several data type that work together. This test mining-device is very simple I would leave everything in main. If we really want to split it for sure not one file for data type. And should be very low priority.

Make sure all imports are imported at top of file instead of directly referenced in the logic

ack. Most of the time agree, some time make sense to import something in a different namespace (if we have conflicts), keep that in mind.

Rust doc comments

ack

Add some clarity to README.md (explain how to start the local pool to get the crate to work)

ack

[rrybarczyk]

Each data type and impl in its own file

nack if we start blindly following it we will end up with millions of file and things will be much harder to understand (not to talk about import and exports). A module can contains several data type that work together. This test mining-device is very simple I would leave everything in main. If we really want to split it for sure not one file for data type. And should be very low priority.

Make sure all imports are imported at top of file instead of directly referenced in the logic

ack. Most of the time agree, some time make sense to import something in a different namespace (if we have conflicts), keep that in mind.

Rust doc comments

ack

Add some clarity to README.md (explain how to start the local pool to get the crate to work)

ack

I really disagree. I don't see a downside in having multiple files. I think it breaks up the logic very nicely and the user knows exactly what to expect in each file.

I am open to other suggestions tho. What other options are you thinking of?

[Fi3]

the downside is to have too many files and make thing even harder to read as I said above. Also is very common to have multiple struct that work together and to expose only one; in that case what you propose? To add a directory with a module and a file for each struct? Remember that every time that you add a directory and you nests files you make the project a little bit harder to explore. I don't think that blindly following the rule of one file per struct will bring us in a better place.