Skip to main content

​
Naming Conventions

Consistent naming makes your graphs easier to understand and maintain. This reference defines naming conventions for all Cerulion Graph Editor components.

​
Overview

Naming conventions ensure:
  • Consistency - Same patterns across your project
  • Clarity - Names are self-explanatory
  • Maintainability - Easy to find and understand components
  • Collaboration - Team members understand the system

​
Schema Names

​
Format: PascalCase

Use PascalCase (capitalize first letter of each word): Good:
  • TemperatureReading
  • SensorData
  • Point3D
  • ImageMetadata
Bad:
  • temperatureReading (camelCase)
  • temperature_reading (snake_case)
  • TEMPERATURE_READING (SCREAMING_SNAKE_CASE)
  • temperature-reading (kebab-case)

​
Guidelines

  • Descriptive - Name describes what the schema represents
  • Noun phrases - Use noun phrases, not verbs
  • Specific - Be specific, not generic
  • No abbreviations - Spell out words (unless universally known)
Examples:
  • ✅ TemperatureReading (not TempRead or Data)
  • ✅ SensorConfiguration (not SensorConfig or Config)
  • ✅ Point3D (not Point or P3D)

​
Field Names

​
Format: camelCase or snake_case

Both formats are acceptable. Be consistent within a schema: camelCase: 
fields:
  temperature: float32
  sensorId: string
  timestampMs: uint64
snake_case: 
fields:
  temperature: float32
  sensor_id: string
  timestamp_ms: uint64

​
Guidelines

  • Descriptive - Name describes what the field contains
  • Consistent - Use same format throughout a schema
  • No abbreviations - Spell out words
  • Units in name - Include units when helpful (e.g., temperature_celsius, timestamp_ms)
Examples:
  • ✅ temperature_celsius (not temp or t)
  • ✅ sensor_id (not id or sid)
  • ✅ timestamp_milliseconds (not ts or time)

​
Node Names

​
Format: Descriptive Phrases

Use descriptive phrases that indicate the node’s purpose: Good:
  • Temperature Publisher
  • Data Processor
  • Celsius to Fahrenheit
  • Temperature Logger
Bad:
  • Node1, Node2 (not descriptive)
  • temp_pub (abbreviation)
  • processor (too generic)

​
Guidelines

  • Action-oriented - Describe what the node does
  • Specific - Be specific about the node’s role
  • Consistent patterns - Use consistent patterns for similar nodes
  • Spaces allowed - Can use spaces for readability
Patterns:
  • Publishers: [Data Type] Publisher (e.g., Temperature Publisher)
  • Processors: [Transformation] (e.g., Celsius to Fahrenheit)
  • Subscribers: [Action] [Data Type] (e.g., Log Temperature, Display Sensor Data)

​
Topic Names

​
Format: lowercase_with_underscores

Use lowercase with underscores (snake_case): Good:
  • temperature_readings
  • sensor_data
  • processed_temperatures
  • alert_messages
Bad:
  • TemperatureReadings (PascalCase)
  • temperature-readings (kebab-case)
  • temp (too abbreviated)
  • topic1 (not descriptive)

​
Guidelines

  • Descriptive - Name describes what data flows through
  • Plural for streams - Use plural for continuous data streams
  • Singular for events - Use singular for discrete events
  • Domain prefix - Optional prefix for organization (e.g., sensor_temperature, user_events)
Examples:
  • ✅ temperature_readings (continuous stream)
  • ✅ sensor_alert (discrete event)
  • ✅ user_login_events (domain-prefixed)

​
Port Names

​
Format: camelCase or snake_case

Match the convention used in your node code: camelCase:
  • temperatureIn
  • sensorDataOut
  • processedResult
snake_case:
  • temperature_in
  • sensor_data_out
  • processed_result

​
Guidelines

  • Direction indicator - Use _in/_out or In/Out suffix
  • Data description - Name describes what data flows through
  • Consistent - Use same format throughout a node
  • No generic names - Avoid input1, output1
Examples:
  • ✅ temperature_in, temperature_out
  • ✅ sensorDataIn, processedDataOut
  • ❌ input1, output1
  • ❌ in, out

​
Project Names

​
Format: lowercase-with-hyphens

Use lowercase with hyphens (kebab-case): Good:
  • temperature-monitoring
  • sensor-fusion-system
  • data-processing-pipeline
Bad:
  • TemperatureMonitoring (PascalCase)
  • temperature_monitoring (snake_case)
  • Temperature Monitoring (spaces)

​
Guidelines

  • Descriptive - Name describes the project’s purpose
  • Hyphenated - Use hyphens, not underscores or spaces
  • Lowercase - All lowercase for consistency
  • No abbreviations - Spell out words

​
File Names

​
Schema Files

Format: snake_case.yaml Examples:
  • temperature_reading.yaml
  • sensor_data.yaml
  • geometry.yaml

​
Node Files

Format: Match language conventions Rust: snake_case.rs
  • temperature_reader.rs
  • data_processor.rs
Python: snake_case.py
  • temperature_reader.py
  • data_processor.py
C++: snake_case.cpp / snake_case.hpp
  • temperature_reader.cpp
  • data_processor.hpp

​
Best Practices Summary

Be Descriptive

Names should clearly indicate purpose. “Temperature Publisher” is better than “Node1”.

Be Consistent

Use the same naming pattern throughout your project. Consistency aids understanding.

Avoid Abbreviations

Spell out words. “Temperature” is better than “Temp”. Exceptions for well-known abbreviations (e.g., “ID”, “3D”).

Use Domain Terms

Use terms from your problem domain. Domain experts should understand your names.

​
Common Patterns

​
Sensor Data

Schema: SensorReading
Topic: sensor_readings
Node: Sensor Publisher
Port: sensor_data_out

​
Processing Pipeline

Schema: ProcessedData
Topic: processed_data
Node: Data Processor
Port: raw_data_in, processed_data_out

​
Multi-Stage Processing

Stage 1: raw_data → Stage 2: filtered_data → Stage 3: processed_data
Topics: raw_data, filtered_data, processed_data
Nodes: Data Filter, Data Processor

​
Anti-Patterns to Avoid

❌ Generic names: Data, Node, Topic, Message ❌ Abbreviations: temp, proc, sub, pub ❌ Numbers only: node1, topic2, data3 ❌ Inconsistent formats: Mixing camelCase and snake_case ❌ Too long: VeryLongDescriptiveNameThatIsHardToRead ❌ Too short: x, d, t

​
Next Steps

Create a Schema

Apply naming conventions when creating schemas.

Add Ports

Use naming conventions for ports.

Schema YAML

See schema naming in YAML format.

Examples

See naming conventions in practice.