Submit ideas for Improving F´ Code Consistency #3599
Replies: 18 comments 27 replies
-
I am in favor of all of these adjustments. For log/events, I like the idea of allowing a separate but FPP supported mechanism for local textLog output. The use case is primarily for debugging: it would be nice to be able to print true log-like statements that leverage the same time source and component to emit the text logs that don't need to be EVRs. Bringing the conventions for parameters and commands in-line with each other would also be nice. |
Beta Was this translation helpful? Give feedback.
-
From @timcanham: "Modify component command/channel/etc names to remove component names that used to be part of the command and are now instances." |
Beta Was this translation helpful? Give feedback.
-
Run code formatter on all F Prime core code. |
Beta Was this translation helpful? Give feedback.
-
Beta Was this translation helpful? Give feedback.
-
Location of port and type definitions is inconsistent. A solution: move port definitions to a Port directory and types definitions to a Types directory. Perhaps defined these directories in Drv and a separate one in Svc? |
Beta Was this translation helpful? Give feedback.
-
Replace |
Beta Was this translation helpful? Give feedback.
-
We have |
Beta Was this translation helpful? Give feedback.
-
Regarding parameters, it autogenerates a SAVE command but it's misleading. The SAVE command just sends the new parameter to PrmDb. The SAVE command should be something like SEND |
Beta Was this translation helpful? Give feedback.
-
We use the term "Deployment" both to refer to a build of a specific topology into a specific binary, AND as a generic term for the support needed for a platform. I would like the term "Deployment" to only have ONE meaning. |
Beta Was this translation helpful? Give feedback.
-
Here is my wish list:
|
Beta Was this translation helpful? Give feedback.
-
Most obvious win in my opinion is making Fw.Time and Fw.TimeInterval FPP structs instead of abstract types. Second one would be to switch all unit tests to using GTest fixtures. Big pain point is the "buffer circus": Second biggest pain point is the "string circus". Not going to enumerate them all but there are like 10 different string types, and they all just seem to have different max sizes. My suggestion is using type aliases to make EventString an alias for StringSizeXYZ, etc |
Beta Was this translation helpful? Give feedback.
-
There are inconsistencies in the naming of standard port types throughout components in Buffer Manager
CmdDispatcher
This also extends to |
Beta Was this translation helpful? Give feedback.
-
FPrime code files are not namespaced. i.e. one includes |
Beta Was this translation helpful? Give feedback.
-
Consistent use of private vs PRIVATE -- do we still want PRIVATE? |
Beta Was this translation helpful? Give feedback.
-
I still would like us to look at potentially eliminating the rate group context argument. I haven't seen any practical use for |
Beta Was this translation helpful? Give feedback.
-
I'd like to suppress the wall of text coming from dictionary generation:
|
Beta Was this translation helpful? Give feedback.
-
Can Fw.Buffer use a FwSizeType size and not a U32? |
Beta Was this translation helpful? Give feedback.
-
Could event throttling be limit at most X Events per Y seconds? |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
-
Call for Comments
Dear Community,
As part of the improvements we are targeting to introduce with the v4.0.0 Release, we would like to solidify the consistency of our code base (naming scheme, code style, etc.).
If you have suggestions for improvements, please respond to this Discussion with your own!
Here are a few examples:
log
(e.g.log_**()
function to emit an event,LogPackets
/LogBuffer
types, etc.)serialize()
call. Sometimes it's<element>.serialize(<buffer>)
, while sometimes it's<buffer>.serialize(<element>)
serializeTo()
deserializeFrom()
where applicable for clarityfieldA
, the autocoded getters/setters aresetfieldA
/getfieldA
set_*
/get_*
insteadTHIS_CASE
, others useThatOne
. For RateGroup ports, there are 3 different namesrun
/schedIn
/Run
.As you may have noticed, this kind of changes will cause a lot of (somewhat simple to fix, but still tedious) breaking changes. The rationale is that we aim for v4.0 to introduce as many breaking improvements as possible, to have a stable and consistent product going forward. If you have comments with regards to that, please do comment.
Beta Was this translation helpful? Give feedback.
All reactions