[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. If you do not want to receive messages from ros-users please use the unsubscribe link below. If you use the one above, you will stop all of ros-users from receiving updates. ______________________________________________________________________________ ros-users mailing list ros-users@lists.ros.org http://lists.ros.org/mailman/listinfo/ros-users Unsubscribe: