Naming rules for struct/class/bus

[af-roos]

I noticed there isn’t yet an explicit guideline for struct names and, in particular, for struct field names. The only related reference I found, “Defining structs”, includes an example where the struct members use UpperCamelCase. Should these be UpperCamelCase? And if so, should the same convention apply to Simulink.Bus elements?

I’m asking because this can create a mismatch with some Model Advisor naming guidelines. For example, suppose I have a Simulink Inport of type Bus, with elements Signal1 and Signal2, which has been created from a MATLAB struct or class. If I use a Bus Selector to extract Signal1 and feed it into a MATLAB Function block, where the corresponding function parameter is named signal1 (lowerCamelCase, following MATLAB function parameter conventions), Model Advisor will trigger a violation because the bus element name (UpperCamelCase) doesn’t match the block input name (lowerCamelCase).

Is there any recommendations on how to harmonize these conventions?

[michellehirsch]

We went back and forth on what standard to apply to struct field names. We ultimately recognized that the use cases for structs vary enough that we decided to not include a standard.

For those of us who spend a lot of time designing objects, am obvious place to start is to apply object property naming standards to struct fields – MixedCase. That makes sense if you return a struct as a function output that could otherwise be an object. But as you point out, there are lots of other use cases for structs. If a struct is a container for a bunch of variables, it’s reasonable to name the fields using variable naming standards.

We could consider adding a guideline giving advice to this extent, but the design space is so open-ended that we weren’t sure if it would add sufficient value.