[ros-users] [Discourse.ros.org] [Next Generation ROS] Relaxing ROS2 topic/service field name restrictions

[Nikolaus Demmel]

[quote="wjwwood, post:6, topic:6371"]

For me the obvious case solution is to provide a linter, enable it by default, and provide a convenient way to silence the linter in particular cases that youre unwilling to change, a la `# noqa` .

[/quote]





:+1: on this solution + maybe a "convention" disallowing this opt-out for new messages in core packages.



I'm still not convinced on the `CameraInfo` case. I do agree that consistency by itself is valuable in particular also for the core messages and maybe this is a good time to improve things, but from past experience with writing datatype converters between different systems (a few iterations of of ROS1 + X) I still believe that ease of transition in this particular case is more valuable. (But then again, I don't really know what overhead is really incurred by changing message and field names in this case, so it's hard to judge for me.)



[quote="Ingo_Lutkebohle, post:8, topic:6371"]

Still, for the future, why not ensure more consistency. No harm, right? There is no *advantage* of either naming convention over the other, we just have to pick one.

[/quote]



Fully agreed on no harm / only benefit, if we consider only new messages and leave legacy as they are.



[quote="Ingo_Lutkebohle, post:8, topic:6371"]

To get rid of the warnings, we can put messages on a legacy list or something like that.

[/quote]



"Legacy list" sounds like a centrally managed solution (probably you didn't mean that anyway), but we would need is an in-package per-message opt-out option (a la `# noqa` as William mentioned).



[quote="bgmoon, post:7, topic:6371"]

Why not make case and _ transparent so that they may be optionally used for documentation clarity, but from a programatic perspective these would all be the same:

[/quote]





Not sure about this, sounds to me like more potential for things going wrong, as IMHO it is a surprising convention for people that are not already familiar with the rules and thus is likely to result in tools / scripts that work in many cases, but break in surprising ways since this rule was not accounted for.



Even very simple things like topic names `foo/bar` and `/foo/bar` not being treated equal has caused me many a headache in rosbag processing.











---

[Visit Topic](https://discourse.ros.org/t/relaxing-ros2-topic-service-field-name-restrictions/6371/9) or reply to this email to respond.