chore!: major struct and enum naming refactoring

[nyurik]

To improve readability, and to avoid duplication in names, I tried to clean up the structs a bit. Note that these are even caught by Clippy:

• clippy::struct_field_names
• clippy::enum_variant_names

TBD

• in enum AttributeValue { U64(u64), I64(i64), Double(f64), String(String) }
  • Is it better to call I64/U64 as Signed/Unsigned, or maybe SignedInt/UnsignedInt?
• in Signal, should it be multiplexer_indicator or multiplex_indicator ?
• in SignalExtendedValueType, the IEEEfloat32Bit and IEEEfloat64Bit seems a bit too verbose... Would Float and Double suffice?
• in ValueDescription, the value_descriptions: Vec<ValDescription> in Signal and EnvironmentVariable seems excessive - would descriptions suffice?

Breaking Changes

• enum EnvType
  • EnvTypeFloat → Float
  • EnvTypeu64 → U64
  • EnvTypeData → Data
• struct SignalType
  • signal_type_name → name
• enum AccessNode
  • AccessNodeVectorXXX → VectorXXX
  • AccessNodeName → Name
• enum AttributeValuedForObjectType
  • RawAttributeValue → Raw
  • NetworkNodeAttributeValue → NetworkNode
  • MessageDefinitionAttributeValue → MessageDefinition
  • SignalAttributeValue → Signal
  • EnvVariableAttributeValue → EnvVariable
• enum AttributeValueType
  • AttributeValueTypeInt → Int
  • AttributeValueTypeHex → Hex
  • AttributeValueTypeFloat → Float
  • AttributeValueTypeString → String
  • AttributeValueTypeEnum → Enum
• struct ValDescription
  • a → id
  • b → description
• enum AttributeValue
  • AttributeValueU64 → U64
  • AttributeValueI64 → I64
  • AttributeValueF64 → Double
  • AttributeValueCharString → String
• struct ValueTable
  • value_table_name → name
  • value_descriptions → description
• enum Comment
  • Node: node_name → name
  • Message: message_id → id
  • Signal: signal_name → name
  • EnvVar: env_var_name → name
• struct EnvironmentVariable
  • env_var_name → name
  • env_var_type → typ
• struct AttributeDefault
  • attribute_name → name
  • attribute_value → value
• struct AttributeValueForObject
  • attribute_name → name
  • attribute_value → value
• enum ValueDescription
  • Signal: signal_name → name
  • EnvironmentVariable: env_var_name → name
• struct SignalGroups
  • signal_group_name → name (?)

[Copilot]

Pull Request Overview

This PR implements a breaking change to rename redundant names in the codebase to improve readability and comply with Rust Clippy lints. The changes systematically remove prefixes that duplicate the enum/struct type names.

• Renamed enum variants to remove redundant type prefixes (e.g., EnvTypeFloat → Float)
• Renamed struct fields to remove redundant type prefixes (e.g., signal_type_name → name)
• Updated field names to be more descriptive (e.g., a → id, b → description in ValDescription)

---

_{Tip: Customize your code reviews with copilot-instructions.md. Create the file or learn how to get started.}

[codecov]

Codecov Report

❌ Patch coverage is 96.84211% with 3 lines in your changes missing coverage. Please review.

Files with missing lines	Patch %	Lines
src/parser.rs	96.59%	3 Missing ⚠️

📢 Thoughts on this report? Let us know!

[tegimeki]

Tested with interfaces changes on dependent crate. There are a lot of places to update but it's mostly a mechanical process and the resulting names are better and more succinct. I can update dbc-data to match once available on crates.io.

[tegimeki]

Did you choose Double instead of F64 to match the IEEE/DBC nomenclature? I could go either way but using the file format convention as you have seems slightly better.

[nyurik]

I chose it mainly because int and other C-style integer type naming was not specific (on purpose, by the C standard), whereas float/double has always had much stricter size guarantees. On the other hand, f64 can be mis-read as i64, hence the name. I am ok to rename it to f64 if you think its better though, for consistency

[tegimeki]

I was always puzzled by a and b names, this is better