deploy: 951fee0

Author: Logofile

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

@@ -3,5 +3,5 @@ Best Practices Specific to Editions Avoid applying editions features except when
 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>Updated for proto3. Patches welcome!
 This doc is a complement to Proto Best Practices. It&amp;rsquo;s not a prescription for Java/C++/Go and other APIs.
 If you see a proto straying from these guidelines in a code review, point the author to this topic and help spread the word.
-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.</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 1-1-1 best practice is to keep every proto_library and .proto file as small as is reasonable, with the ideal being:
-One proto_library build rule One source .proto file One top-level entity (message, enum, or extension) Having the fewest number of message, enum, extension, and services as you reasonably can makes refactoring easier. Moving files when they&amp;rsquo;re separated is much easier than extracting messages from a file with other messages.</description></item></channel></rss>
+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.</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>

best-practices/api/index.html

@@ -1,2 +1,2 @@
 <?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Protobuf Team Design Decisions on Protocol Buffers Documentation</title><link>https://protobuf.dev/design-decisions/</link><description>Recent content in Protobuf Team Design Decisions on Protocol Buffers Documentation</description><generator>Hugo</generator><language>en</language><atom:link href="https://protobuf.dev/design-decisions/index.xml" rel="self" type="application/rss+xml"/><item><title>No Nullable Setters/Getters Support</title><link>https://protobuf.dev/design-decisions/nullable-getters-setters/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://protobuf.dev/design-decisions/nullable-getters-setters/</guid><description>We have heard feedback that some folks would like protobuf to support nullable getters/setters in their null-friendly language of choice (particularly Kotlin, C#, and Rust). While this does seem to be a helpful feature for folks using those languages, the design choice has tradeoffs which have led to the Protobuf team choosing not to implement them.
-The biggest reason not to have nullable fields is the intended behavior of default values specified in a .</description></item></channel></rss>
+Explicit presence is not a concept that directly maps to the traditional notion of nullability.</description></item></channel></rss>