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

docs/topics/db/examples/one_to_one.txt

@@ -126,7 +126,7 @@ You can query the models using :ref:`lookups across relationships <lookups-that-
     >>> Restaurant.objects.exclude(place__address__contains="Ashland")
     <QuerySet [<Restaurant: Demon Dogs the restaurant>]>
 
-This of course works in reverse::
+This also works in reverse::
 
     >>> Place.objects.get(pk=1)
     <Place: Demon Dogs the place>

docs/topics/db/managers.txt

@@ -135,9 +135,9 @@ With this sample model, ``Book.objects.all()`` will return all books in the
 database, but ``Book.dahl_objects.all()`` will only return the ones written by
 Roald Dahl.
 
-Of course, because ``get_queryset()`` returns a ``QuerySet`` object, you can
-use ``filter()``, ``exclude()`` and all the other ``QuerySet`` methods on it.
-So these statements are all legal::
+Because ``get_queryset()`` returns a ``QuerySet`` object, you can use
+``filter()``, ``exclude()`` and all the other ``QuerySet`` methods on it. So
+these statements are all legal::
 
     Book.dahl_objects.all()
     Book.dahl_objects.filter(title='Matilda')

docs/topics/db/models.txt

@@ -352,8 +352,8 @@ reference <ref-foreignkey>` for details.
 
 It's suggested, but not required, that the name of a
 :class:`~django.db.models.ForeignKey` field (``manufacturer`` in the example
-above) be the name of the model, lowercase. You can, of course, call the field
-whatever you want. For example::
+above) be the name of the model, lowercase. You can call the field whatever you
+want. For example::
 
     class Car(models.Model):
         company_that_makes_it = models.ForeignKey(
@@ -952,12 +952,12 @@ extend the parent's :ref:`Meta <meta-options>` class, it can subclass it. For ex
         class Meta(CommonInfo.Meta):
             db_table = 'student_info'
 
-Django does make one adjustment to the :ref:`Meta <meta-options>` class of an abstract base
-class: before installing the :ref:`Meta <meta-options>` attribute, it sets ``abstract=False``.
-This means that children of abstract base classes don't automatically become
-abstract classes themselves. Of course, you can make an abstract base class
-that inherits from another abstract base class. You just need to remember to
-explicitly set ``abstract=True`` each time.
+Django does make one adjustment to the :ref:`Meta <meta-options>` class of an
+abstract base class: before installing the :ref:`Meta <meta-options>`
+attribute, it sets ``abstract=False``. This means that children of abstract
+base classes don't automatically become abstract classes themselves. To make
+an abstract base class that inherits from another abstract base class, you need
+to explicitly set ``abstract=True`` on the child.
 
 Some attributes won't make sense to include in the :ref:`Meta <meta-options>` class of an
 abstract base class. For example, including ``db_table`` would mean that all

docs/topics/db/queries.txt

@@ -1201,8 +1201,8 @@ query you can use the following syntax::
 If ``EntryManager`` performed default filtering in its ``get_queryset()``
 method, that filtering would apply to the ``all()`` call.
 
-Of course, specifying a custom reverse manager also enables you to call its
-custom methods::
+Specifying a custom reverse manager also enables you to call its custom
+methods::
 
     b.entry_set(manager='entries').is_published()
 

docs/topics/db/sql.txt

@@ -64,9 +64,9 @@ You could then execute custom SQL like so::
     John Smith
     Jane Jones
 
-Of course, this example isn't very exciting -- it's exactly the same as
-running ``Person.objects.all()``. However, ``raw()`` has a bunch of other
-options that make it very powerful.
+This example isn't very exciting -- it's exactly the same as running
+``Person.objects.all()``. However, ``raw()`` has a bunch of other options that
+make it very powerful.
 
 .. admonition:: Model table names
 
@@ -206,9 +206,8 @@ argument to ``raw()``::
 ``params`` is a list or dictionary of parameters. You'll use ``%s``
 placeholders in the query string for a list, or ``%(key)s``
 placeholders for a dictionary (where ``key`` is replaced by a
-dictionary key, of course), regardless of your database engine.  Such
-placeholders will be replaced with parameters from the ``params``
-argument.
+dictionary key), regardless of your database engine. Such placeholders will be
+replaced with parameters from the ``params`` argument.
 
 .. note::
 

docs/topics/db/transactions.txt

@@ -355,8 +355,8 @@ Exception handling
 
 If one on-commit function within a given transaction raises an uncaught
 exception, no later registered functions in that same transaction will run.
-This is, of course, the same behavior as if you'd executed the functions
-sequentially yourself without :func:`on_commit`.
+This is the same behavior as if you'd executed the functions sequentially
+yourself without :func:`on_commit`.
 
 Timing of execution
 -------------------