"Trust the Port or Pin Type!" - Often the name of the Type of an anonymous Port or Pin is completely sufficient to indicate its role, unless a clear indication of its direction or unique role is required.

Icon class
icon_class
far fa-sticky-note
icon_class_computed
far fa-sticky-note
Note kind
NAMING
POLICY
STYLE
UML keywords
NamedElement::name
Property
InstanceSpecification
Port
Keywords
One possible counter-argument to this recommendation concerns using the SysML Requirements system:
SysML: Non-anonymous (concise please) block property names and port names may help a little in tracing participation of properties and ports in requirements relationships and play nicely with current SysML callout style. Short role indicators are best!
Alternatively, if you must name a Port (because you need to for queries, for example):
Webel Best Practice: UML/SysML: In Internal Block Diagrams: Consider hiding the name of a named Port or Property in a Diagram if its Type is sufficient to indicate its role.
Webel Best Practice: Webel: If you must name your Ports or Pins, name them simply 'i', 'o', or 'io' (or 'oi') to indicate direction UNLESS you have to indicate a special role like 'iRole', 'oAuxiliary'. DO NOT use Port or Pin names like 'input', 'output', etc.
SysML/SysPhS-1.1: Anonymous Property or Action names may not be an option if: You are exporting to Modelica or Simulink; You absolutely need names for generated query reports (such as generated Interface Control Documents).
Relates to
BDD: Header1 on an Arduino Mega2560R3
BDD: Header3 on an Arduino Mega2560R3
BDD: Header2 on an Arduino Mega2560R3
IBD: Arduino Mega2560R3 - headers with pins and logical ports
IBD: Header1 on an Arduino Mega2560R3 - connections
IBD: Header3 on an Arduino Mega2560R3 - connections
Related notes
[NAMING, POLICY]{STRONG} "Trust the Namespace" - DO NOT repeat information in names of owned elements that can be gleaned from the owner or ancestor (and is usually easily shown using display options). It is WET, it breaks the DRY principle!
[NAMING, POLICY]{STRONG} Prefer anonymous Actions, or if they must be named, prefer code-like 'lowerCamelCase' or completely 'lower case' (if you do absolutely insist on having spaces in action names, but please no other punctuation).
[NAMING, POLICY]{STRICT} SysML: Naming: Always use either anonymous or first letter lower case for Property, ObjectNode and InstanceSpecification names; no exceptions (unless using names to "quote text")! Valid: 'lowerCamelCase' OR 'tla' vs TLA acronym OR 'uCC' vs UpperCamelCase
[NAMING, POLICY, STYLE]{STRONG} SysML: Webel: "Trust the Type!" - Often the name of the Type of an anonymous Property or instance-level element is completely sufficient to indicate its role - unless multiple Properties of the same Type have different roles within the same owner context!
[CAVEAT]{OPTION} SysMLv1: When using model queries (such as tables) for compliance with some older systems engineering docs you may not always be able to use anonymous Property names and anonymous instance level element names. Or try the owner context or the ID!
[DISPLAY, MODELLING, NAMING, STYLE]{TIP} UML/SysML: In Internal Block Diagrams: Consider hiding the name of a named Port or Property in a Diagram if its Type is sufficient to indicate its role.
[NAMING, POLICY]{STRONG} Use 'UpperCamelCase' (a.k.a. PascalCase) names for Classifiers such as UML Classes and SysML Blocks) to avoid confusion with 'lowerCase' Property names [see however special naming conventions for acronyms and SysML contract and flow Blocks]
Related notes (backlinks)
Related snippets (extracts)
Visit also
Visit also (backlinks)