Refs #30573 -- Rephrased "Of Course" and "Obvious(ly)" in documentation and comments.

1 files changed, 6 insertions, 6 deletions

diff --git a/docs/howto/custom-model-fields.txt b/docs/howto/custom-model-fields.txt
index 8a8da037f3..c31a5dbc4f 100644
--- a/docs/howto/custom-model-fields.txt
+++ b/docs/howto/custom-model-fields.txt
@@ -301,10 +301,10 @@ than disappearing if they take on the old default value.
 
 In addition, try to avoid returning values as positional arguments; where
 possible, return values as keyword arguments for maximum future compatibility.
-Of course, if you change the names of things more often than their position
-in the constructor's argument list, you might prefer positional, but bear in
-mind that people will be reconstructing your field from the serialized version
-for quite a while (possibly years), depending how long your migrations live for.
+If you change the names of things more often than their position in the
+constructor's argument list, you might prefer positional, but bear in mind that
+people will be reconstructing your field from the serialized version for quite
+a while (possibly years), depending how long your migrations live for.
 
 You can see the results of deconstruction by looking in migrations that include
 the field, and you can test deconstruction in unit tests by deconstructing and
@@ -451,8 +451,8 @@ time -- i.e., when the class is instantiated. To do that, implement
 Finally, if your column requires truly complex SQL setup, return ``None`` from
 :meth:`.db_type`. This will cause Django's SQL creation code to skip
 over this field. You are then responsible for creating the column in the right
-table in some other way, of course, but this gives you a way to tell Django to
-get out of the way.
+table in some other way, but this gives you a way to tell Django to get out of
+the way.
 
 The :meth:`~Field.rel_db_type` method is called by fields such as ``ForeignKey``
 and ``OneToOneField`` that point to another field to determine their database