diff --git a/docs/topics/class-based-views/mixins.txt b/docs/topics/class-based-views/mixins.txt
index b6552b9108..84d7417233 100644
--- a/docs/topics/class-based-views/mixins.txt
+++ b/docs/topics/class-based-views/mixins.txt
@@ -34,7 +34,7 @@ interface to working with templates in class-based views.
 :class:`~django.views.generic.base.TemplateResponseMixin`
     Every built in view which returns a
     :class:`~django.template.response.TemplateResponse` will call the
-    :meth:`~django.views.generic.base.TemplateResponseMixin.render_to_response`
+    :meth:`~django.views.generic.base.TemplateResponseMixin.render_to_response()`
     method that ``TemplateResponseMixin`` provides. Most of the time this
     will be called for you (for instance, it is called by the ``get()`` method
     implemented by both :class:`~django.views.generic.base.TemplateView` and
@@ -44,7 +44,7 @@ interface to working with templates in class-based views.
     it. For an example of this, see the :ref:`JSONResponseMixin example
     <jsonresponsemixin-example>`.
 
-    ``render_to_response`` itself calls
+    ``render_to_response()`` itself calls
     :meth:`~django.views.generic.base.TemplateResponseMixin.get_template_names`,
     which by default will just look up
     :attr:`~django.views.generic.base.TemplateResponseMixin.template_name` on
@@ -60,9 +60,9 @@ interface to working with templates in class-based views.
 :class:`~django.views.generic.base.ContextMixin`
     Every built in view which needs context data, such as for rendering a
     template (including ``TemplateResponseMixin`` above), should call
-    :meth:`~django.views.generic.base.ContextMixin.get_context_data` passing
+    :meth:`~django.views.generic.base.ContextMixin.get_context_data()` passing
     any data they want to ensure is in there as keyword arguments.
-    ``get_context_data`` returns a dictionary; in ``ContextMixin`` it
+    ``get_context_data()`` returns a dictionary; in ``ContextMixin`` it
     simply returns its keyword arguments, but it is common to override this to
     add more members to the dictionary.
 
@@ -107,7 +107,7 @@ URLConf, and looks the object up either from the
 on the view, or the
 :attr:`~django.views.generic.detail.SingleObjectMixin.queryset`
 attribute if that's provided). ``SingleObjectMixin`` also overrides
-:meth:`~django.views.generic.base.ContextMixin.get_context_data`,
+:meth:`~django.views.generic.base.ContextMixin.get_context_data()`,
 which is used across all Django's built in class-based views to supply
 context data for template renders.
 
@@ -152,7 +152,7 @@ here would be to dynamically vary the objects, such as depending on
 the current user or to exclude posts in the future for a blog.
 
 :class:`~django.views.generic.list.MultipleObjectMixin` also overrides
-:meth:`~django.views.generic.base.ContextMixin.get_context_data` to
+:meth:`~django.views.generic.base.ContextMixin.get_context_data()` to
 include appropriate context variables for pagination (providing
 dummies if pagination is disabled). It relies on ``object_list`` being
 passed in as a keyword argument, which :class:`ListView` arranges for
@@ -286,15 +286,16 @@ One way to do this is to combine :class:`ListView` with
 for the paginated list of books can hang off the publisher found as the single
 object. In order to do this, we need to have two different querysets:
 
-**``Publisher`` queryset for use in ``get_object``**
+``Publisher`` queryset for use in
+    :meth:`~django.views.generic.detail.SingleObjectMixin.get_object()`
     We'll set the ``model`` attribute on the view and rely on the default
     implementation of ``get_object()`` to fetch the correct ``Publisher``
     object.
 
-**``Book`` queryset for use by ``ListView``**
-    The default implementation of ``get_queryset`` uses the ``model`` attribute
+``Book`` queryset for use by :class:`~django.views.generic.list.ListView`
+    The default implementation of ``get_queryset()`` uses the ``model`` attribute
     to construct the queryset. This conflicts with our use of this attribute
-    for ``get_object`` so we'll override that method and have it return
+    for ``get_object()`` so we'll override that method and have it return
     the queryset of ``Book`` objects linked to the ``Publisher`` we're looking
     at.
 
@@ -641,10 +642,10 @@ For example, a simple JSON mixin might look something like this::
     information on how to correctly transform Django models and querysets into
     JSON.
 
-This mixin provides a ``render_to_json_response`` method with the same signature
+This mixin provides a ``render_to_json_response()`` method with the same signature
 as :func:`~django.views.generic.base.TemplateResponseMixin.render_to_response()`.
 To use it, we simply need to mix it into a ``TemplateView`` for example,
-and override ``render_to_response`` to call ``render_to_json_response`` instead::
+and override ``render_to_response()`` to call ``render_to_json_response()`` instead::
 
     from django.views.generic import TemplateView
 
@@ -693,5 +694,5 @@ that the user requested::
 Because of the way that Python resolves method overloading, the call to
 ``super(HybridDetailView, self).render_to_response(context)`` ends up
 calling the
-:meth:`~django.views.generic.base.TemplateResponseMixin.render_to_response`
+:meth:`~django.views.generic.base.TemplateResponseMixin.render_to_response()`
 implementation of :class:`~django.views.generic.base.TemplateResponseMixin`.