当前位置: 首页 > 知识库问答 >
问题:

中字段的命名约定不正确。protobuf net生成的proto文件?

薛楷
2023-03-14

我刚刚开始使用Google Protocol Buffers和Marc Gravell的很棒的protobuf net程序,有一件事我不明白,那就是生成的文件中字段声明的命名约定。原始文件。

以下是谷歌的建议:

“将下划线_分隔的_名称用作字段名称–例如,song_名称。”https://developers.google.com/protocol-buffers/docs/style

"请注意,方法名称总是使用camel-case命名,即使. proto文件中的字段名称使用带有下划线的小写(应该如此)。"https://developers.google.com/protocol-buffers/docs/reference/java-generated

"注意这些访问器方法如何使用camel-case命名,即使. proto文件使用了带有下划线的小写。"https://developers.google.com/protocol-buffers/docs/javatutorial

但是当我使用序列化程序时。protobuf net中的GetProto()方法

  [ProtoContract]
  public partial class AuthEntry
  {
     private string _windowsAccount = "";
     private string _machineNames = "*";

     [ProtoMember(1)]
     public string WindowsAccount
     {
        get { return _windowsAccount; }
        set { _windowsAccount = value; }
     }

     [ProtoMember(2)]
     public string MachineNames
     {
        get { return _machineNames; }
        set { _machineNames = value; }
     }
  }

我明白了:

message AuthEntry {
   optional string WindowsAccount = 1;
   optional string MachineNames = 2;
}

而不是像我预料的那样:

message AuthEntry {
   optional string windows_account = 1;
   optional string machine_names = 2;
}

我想这没什么大不了的,但以防万一...

共有1个答案

殷宇
2023-03-14

原始一代不会尝试应用这些约定,因为这样它就会进入消歧、冲突等军备竞赛——更不用说在CustomerIDResources等任意名称中查找单词中断的乐趣了(好吧,这是一个不太可能的例子,但你明白了)。如果您想自己控制它——在原型合同属性或原型成员属性上指定名称属性。

 类似资料:
  • 我使用JAXB根据定义的模式封送/解封xml文档。我注意到的是,JAXB在编组的xml中生成了不正确的名称空间。 以下是详细信息- soap.xsd-- 方案1.xsd-- schema2.xsd-- 我为jaxbMarshaller(在我的Spring配置中)定义了一个命名空间Prefix MapperImpl,它将URI映射到我定义的前缀名称。 编组的响应xml如下所示。请注意,JAXB在命名

  • 问题内容: 是否有用于命名jar文件的任何行业标准约定? 问题答案: 我一直在用 哪里: M = (在不必保持向后兼容性时更改) m = (功能添加等) b = (对于包含错误修复的版本)

  • 问题1我创建了一个文本字段,如上面的代码所示,并尝试使用TextBox.setValue(“测试值”)设置值;方法,但它给出的错误如下所示: 问题3 为了解决问题#2,我需要将NeedExceptions标志设置为true,如下所示,然后在PDF中正确显示该字段值。但是在这个解决方案之后,一旦用户改变了字段值,我们再次解析这个PDF字段,我就无法提取/解析PDF字段。 注意:-这个问题存在于Ado

  • 我有一个用例,我使用lambda函数生成有符号的网址上传到S3桶,我还在生成有符号的网址时设置了元数据值,我的boto3版本是boto3==1.18.35。以前,当我生成有符号的网址上传到桶时,网址看起来像这样: https://bucket-name.s3.amazonaws.com/scanned-file-list/cf389880-09ff-4301-8fa7-b4054941685b/6

  • 为了在跨API开发中向开发者提供一致的开发体验,所有的命名应该保证: 简单 直观 一致 这适用于接口、资源、集合、方法以及消息的命名。 因为很多开发者并非以英语作为母语,所以命名约定的目标之一是确保大多数开发者可以更容易理解 API。对于方法和资源,我们鼓励使用简单、直观和一致的单词来命名。 API 中的命名应该使用正确的美式英语。例如,使用美式英语的 license 而非英式英语的 licenc

  • 在本节,我们不会讨论适用于大规模和可维护的最佳 CSS 命名方案,因为这不仅仅超过了个人的能力范围,也不是一个Sass样式指南可以解决的问题。我个人推荐遵从 CSS Guidelines 的建议。 良好的命名对保持整体代码的一致性和可读性非常重要,在 Sass 中可以命名的地方如下: 变量; 函数; 混合宏。 由于 Sass 占位符遵循和类名相同的命名模式,因此被视为常规的 CSS 选择器,也就在