Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

Naming rules for struct/class/bus

Open
#3 1 comment 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Assessment

Difficulty
5/5
Estimated time
Over a week
Newbie friendliness
35/100
Issue type
Documentation
Clarity
Mostly clear
Activity status
Stale
Tech stack
matlab
Domain
documentation

Research direction

Start by reading the existing “Defining structs” guidance and the Model Advisor naming guidelines referenced in the issue. Compare conventions for MATLAB struct and class fields with Simulink.Bus elements and document a consistent recommendation that resolves the described bus-to-MATLAB Function naming mismatch.

Written by the indexing model from the issue text.

Description

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?

Dominant language
No language data
Stars
139
Forks
11
PR merge metrics
No merged PRs in 30d

Contributor guide

No contributing guide indexed for this repository

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from mathworks/MATLAB-Coding-Guidelines

All issues in mathworks/MATLAB-Coding-Guidelines

Similar issues

More Documentation issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.