You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I started working on #845 and the first crate I started was framing_sv2. The goal there is to document the code. Which means I first need to understand it.
But the code structure of src/framing2.rs is very confusing.
Basically, impl blocks for different structs are mixed together without a coherent structure.
As one example amongst many, take the Sv2Frame struct: it's impl block starts on line 17, while the struct itself is declared only on line 68 (after a declaration of trait Frame). Then, the impl Frame block for Sv2Frame happens on line 104, after declarations of NoiseFrame struct.
A refactor bringing a more structure and improving code readability is needed.
Structs and Enums like NoiseFrame, Sv2Frame and EitherFrame, as well as the Frame trait, should each get their own file under the framing module.
Note: opposed to what has been argued before, IMHO file size (e.g.: number of lines) should not be the main criteria for code modularization.
Logical cohesion and readability must always come first.
If some logical entity has very few lines, but does something very specific, it already deserves its own file.
The text was updated successfully, but these errors were encountered:
I don't agree in framin2 we define EitherFrame that is either an Handshake frame or a plain Sv2Frame both impl the trait Frame that is public. The file is less the 400 loc. In how many file do you want to split it? Following the above suggestion I would say at least 4, on for the Frame trait, one for the HandShakeFrame struct one for the Sv2Frame struct and one for EtitherFrame enum. Having 4 file with few lines of code for 4 things that are more or less the same thing, and maybe put them undeer another module called frame will only increase the complexity of the crate adding nothing. I
I started working on #845 and the first crate I started was
framing_sv2
. The goal there is to document the code. Which means I first need to understand it.But the code structure of
src/framing2.rs
is very confusing.Basically,
impl
blocks for different structs are mixed together without a coherent structure.As one example amongst many, take the
Sv2Frame
struct: it'simpl
block starts on line 17, while the struct itself is declared only on line 68 (after a declaration of traitFrame
). Then, theimpl Frame
block forSv2Frame
happens on line 104, after declarations ofNoiseFrame
struct.A refactor bringing a more structure and improving code readability is needed.
Structs and Enums like
NoiseFrame
,Sv2Frame
andEitherFrame
, as well as theFrame
trait, should each get their own file under theframing
module.Note: opposed to what has been argued before, IMHO file size (e.g.: number of lines) should not be the main criteria for code modularization.
Logical cohesion and readability must always come first.
If some logical entity has very few lines, but does something very specific, it already deserves its own file.
The text was updated successfully, but these errors were encountered: