deploy: c5d2eda

Author: Logofile

best-practices/1-1-1/index.html

@@ -1,5 +1,4 @@
 <?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Proto Best Practices on Protocol Buffers Documentation</title><link>https://protobuf.dev/best-practices/</link><description>Recent content in Proto Best Practices on Protocol Buffers Documentation</description><generator>Hugo</generator><language>en</language><atom:link href="https://protobuf.dev/best-practices/index.xml" rel="self" type="application/rss+xml"/><item><title>Avoid Cargo Culting</title><link>https://protobuf.dev/best-practices/no-cargo-cults/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://protobuf.dev/best-practices/no-cargo-cults/</guid><description>Do not cargo cult settings in proto files. If you are creating a new proto file based on existing schema definitions, don&amp;rsquo;t apply option settings except for those that you understand the need for.
 Best Practices Specific to Editions Avoid applying editions features except when they&amp;rsquo;re actually necessary. Features in .proto files signal the use of either experimental future behaviors or deprecated past behaviors. Best practices for the latest edition will always be the default.</description></item><item><title>Proto Best Practices</title><link>https://protobuf.dev/best-practices/dos-donts/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://protobuf.dev/best-practices/dos-donts/</guid><description>Clients and servers are never updated at exactly the same time - even when you try to update them at the same time. One or the other may get rolled back. Don’t assume that you can make a breaking change and it&amp;rsquo;ll be okay because the client and server are in sync.
-Don&amp;rsquo;t Re-use a Tag Number Never re-use a tag number. It messes up deserialization. Even if you think no one is using the field, don’t re-use a tag number.</description></item><item><title>API Best Practices</title><link>https://protobuf.dev/best-practices/api/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://protobuf.dev/best-practices/api/</guid><description>This doc is a complement to Proto Best Practices. It&amp;rsquo;s not a prescription for Java/C++/Go and other APIs.
-Note These guidelines are just that and many have documented exceptions. For example, if you&amp;rsquo;re writing a performance-critical backend, you might want to sacrifice flexibility or safety for speed. This topic will help you better understand the trade-offs and make a decision that works for your situation. Precisely, Concisely Document Most Fields and Messages Chances are good your proto will be inherited and used by people who don&amp;rsquo;t know what you were thinking when you wrote or modified it.</description></item><item><title>1-1-1 Best Practice</title><link>https://protobuf.dev/best-practices/1-1-1/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://protobuf.dev/best-practices/1-1-1/</guid><description>The &amp;ldquo;1-1-1&amp;rdquo; best practice advocates structuring definitions with one top-level entity (message, enum, or extension) per .proto file, corresponding to a single proto_library build rule. This approach promotes small, modular proto definitions. Key benefits include simplified refactoring, potentially improved build times, and smaller binary sizes due to minimized transitive dependencies.
+Don&amp;rsquo;t Re-use a Tag Number Never re-use a tag number. It messes up deserialization. Even if you think no one is using the field, don’t re-use a tag number.</description></item><item><title>1-1-1 Best Practice</title><link>https://protobuf.dev/best-practices/1-1-1/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://protobuf.dev/best-practices/1-1-1/</guid><description>The &amp;ldquo;1-1-1&amp;rdquo; best practice advocates structuring definitions with one top-level entity (message, enum, or extension) per .proto file, corresponding to a single proto_library build rule. This approach promotes small, modular proto definitions. Key benefits include simplified refactoring, potentially improved build times, and smaller binary sizes due to minimized transitive dependencies.
 The 1-1-1 best practice is to keep every proto_library and .proto file as small as is reasonable, with the ideal being:</description></item></channel></rss>