Fixed #36311 -- Unified spelling of "hardcode" and its variants in docs.

Co-authored-by: Natalia <124304+nessita@users.noreply.github.com>

docs/howto/custom-model-fields.txt

@@ -432,10 +432,10 @@ that is, when you retrieve data using QuerySet methods like ``get()``,
 Some database column types accept parameters, such as ``CHAR(25)``, where the
 parameter ``25`` represents the maximum column length. In cases like these,
 it's more flexible if the parameter is specified in the model rather than being
-hard-coded in the ``db_type()`` method. For example, it wouldn't make much
-sense to have a ``CharMaxlength25Field``, shown here::
+hardcoded in the ``db_type()`` method. For example, it wouldn't make much sense
+to have a ``CharMaxlength25Field``, shown here::
 
-    # This is a silly example of hard-coded parameters.
+    # This is a silly example of hardcoded parameters.
     class CharMaxlength25Field(models.Field):
         def db_type(self, connection):
             return "char(25)"

docs/howto/custom-template-tags.txt

@@ -904,7 +904,7 @@ Notes:
   any syntax error.
 
 * The ``TemplateSyntaxError`` exceptions use the ``tag_name`` variable.
-  Don't hard-code the tag's name in your error messages, because that
+  Don't hardcode the tag's name in your error messages, because that
   couples the tag's name to your function. ``token.contents.split()[0]``
   will ''always'' be the name of your tag -- even when the tag has no
   arguments.
@@ -1223,7 +1223,7 @@ Here's how you'd use this new version of the tag:
     with context in other blocks.
 
 But, there's a problem with ``CurrentTimeNode2``: The variable name
-``current_time`` is hard-coded. This means you'll need to make sure your
+``current_time`` is hardcoded. This means you'll need to make sure your
 template doesn't use ``{{ current_time }}`` anywhere else, because the
 ``{% current_time %}`` will blindly overwrite that variable's value. A cleaner
 solution is to make the template tag specify the name of the output variable,

docs/howto/initial-data.txt

@@ -2,7 +2,7 @@
 How to provide initial data for models
 ======================================
 
-It's sometimes useful to prepopulate your database with hard-coded data when
+It's sometimes useful to prepopulate your database with hardcoded data when
 you're first setting up an app. You can provide initial data with migrations or
 fixtures.
 

docs/howto/outputting-csv.txt

@@ -121,7 +121,7 @@ Here's an example, which generates the same CSV file as above::
             headers={"Content-Disposition": 'attachment; filename="somefilename.csv"'},
         )
 
-        # The data is hard-coded here, but you could load it from a database or
+        # The data is hardcoded here, but you could load it from a database or
         # some other source.
         csv_data = (
             ("First row", "Foo", "Bar", "Baz"),

docs/internals/deprecation.txt

@@ -1073,7 +1073,7 @@ details on these changes.
 
 * The ``CACHE_MIDDLEWARE_ANONYMOUS_ONLY`` setting will be removed.
 
-* Usage of the hard-coded *Hold down "Control", or "Command" on a Mac, to select
+* Usage of the hardcoded *Hold down "Control", or "Command" on a Mac, to select
   more than one.* string to override or append to user-provided ``help_text`` in
   forms for ManyToMany model fields will not be performed by Django anymore
   either at the model or forms layer.

docs/intro/tutorial03.txt

@@ -166,7 +166,7 @@ commas, according to publication date:
 
     # Leave the rest of the views (detail, results, vote) unchanged
 
-There's a problem here, though: the page's design is hard-coded in the view. If
+There's a problem here, though: the page's design is hardcoded in the view. If
 you want to change the way the page looks, you'll have to edit this Python code.
 So let's use Django's template system to separate the design from Python by
 creating a template that the view can use.

docs/intro/tutorial07.txt

@@ -422,7 +422,7 @@ The template to customize is ``admin/index.html``. (Do the same as with
 ``admin/base_site.html`` in the previous section -- copy it from the default
 directory to your custom template directory). Edit the file, and you'll see it
 uses a template variable called ``app_list``. That variable contains every
-installed Django app. Instead of using that, you can hard-code links to
+installed Django app. Instead of using that, you can hardcode links to
 object-specific admin pages in whatever way you think is best.
 
 When you're comfortable with the admin, read :doc:`part 8 of this

docs/ref/contrib/flatpages.txt

@@ -89,7 +89,7 @@ to place the pattern at the end of the other urlpatterns::
     matched.
 
 Another common setup is to use flatpages for a limited set of known pages and
-to hard code their URLs in the :doc:`URLconf </topics/http/urls>`::
+to hardcode their URLs in the :doc:`URLconf </topics/http/urls>`::
 
     from django.contrib.flatpages import views
 

docs/ref/contrib/sites.txt

@@ -137,7 +137,7 @@ For example::
             # Do something else.
             pass
 
-It's fragile to hard-code the site IDs like that, in case they change. The
+It's fragile to hardcode the site IDs like that, in case they change. The
 cleaner way of accomplishing the same thing is to check the current site's
 domain::
 

docs/ref/contrib/syndication.txt

@@ -715,7 +715,7 @@ This example illustrates all possible attributes and methods for a
             Takes an item, as returned by items(), and returns a boolean.
             """
 
-        item_guid_is_permalink = False  # Hard coded value
+        item_guid_is_permalink = False  # Hardcoded value
 
         # ITEM AUTHOR NAME -- One of the following three is optional. The
         # framework looks for them in this order.

docs/ref/models/instances.txt

@@ -863,7 +863,7 @@ URL, you should define ``get_absolute_url()``.
 
 
 It's good practice to use ``get_absolute_url()`` in templates, instead of
-hard-coding your objects' URLs. For example, this template code is bad:
+hardcoding your objects' URLs. For example, this template code is bad:
 
 .. code-block:: html+django
 

docs/ref/templates/builtins.txt

@@ -777,7 +777,7 @@ will be displayed if the value has not changed:
 Loads a template and renders it with the current context. This is a way of
 "including" other templates within a template.
 
-The template name can either be a variable or a hard-coded (quoted) string,
+The template name can either be a variable or a hardcoded (quoted) string,
 in either single or double quotes.
 
 This example includes the contents of the template ``"foo/bar.html"``:
@@ -1386,7 +1386,7 @@ given view and optional parameters. Any special characters in the resulting
 path will be encoded using :func:`~django.utils.encoding.iri_to_uri`.
 
 This is a way to output links without violating the DRY principle by having to
-hard-code URLs in your templates:
+hardcode URLs in your templates:
 
 .. code-block:: html+django
 

docs/releases/1.5.txt

@@ -591,7 +591,7 @@ sequences automatically together with the database flushing actions described
 above.
 
 This has been changed so no sequences are implicitly reset. This can cause
-:class:`~django.test.TransactionTestCase` tests that depend on hard-coded
+:class:`~django.test.TransactionTestCase` tests that depend on hardcoded
 primary key values to break.
 
 The new :attr:`~django.test.TransactionTestCase.reset_sequences` attribute can

docs/releases/1.6.txt

@@ -648,7 +648,7 @@ Help text of model form fields for ManyToManyField fields
 
 HTML rendering of model form fields corresponding to
 :class:`~django.db.models.ManyToManyField` model fields used to get the
-hard-coded sentence:
+hardcoded sentence:
 
   *Hold down "Control", or "Command" on a Mac, to select more than one.*
 
@@ -668,7 +668,7 @@ widget is :class:`~django.forms.SelectMultiple` or selected subclasses.
 
 The change can affect you in a backward incompatible way if you employ custom
 model form fields and/or widgets for ``ManyToManyField`` model fields whose UIs
-do rely on the automatic provision of the mentioned hard-coded sentence. These
+do rely on the automatic provision of the mentioned hardcoded sentence. These
 form field implementations need to adapt to the new scenario by providing their
 own handling of the ``help_text`` attribute.
 

docs/releases/1.8.txt

@@ -1783,7 +1783,7 @@ remove usage of these features.
   ``django.middleware.cache.UpdateCacheMiddleware`` despite the lack of a
   deprecation warning in the latter class.
 
-* Usage of the hard-coded *Hold down "Control", or "Command" on a Mac, to select
+* Usage of the hardcoded *Hold down "Control", or "Command" on a Mac, to select
   more than one.* string to override or append to user-provided ``help_text`` in
   forms for ``ManyToMany`` model fields is not performed by Django anymore
   either at the model or forms layer.

docs/topics/cache.txt

@@ -726,7 +726,7 @@ Additionally, ``cache_page`` automatically sets ``Cache-Control`` and
 Specifying per-view cache in the URLconf
 ----------------------------------------
 
-The examples in the previous section have hard-coded the fact that the view is
+The examples in the previous section have hardcoded the fact that the view is
 cached, because ``cache_page`` alters the ``my_view`` function in place. This
 approach couples your view to the cache system, which is not ideal for several
 reasons. For instance, you might want to reuse the view functions on another,

docs/topics/class-based-views/generic-display.txt

@@ -316,7 +316,7 @@ Dynamic filtering
 -----------------
 
 Another common need is to filter down the objects given in a list page by some
-key in the URL. Earlier we hard-coded the publisher's name in the URLconf, but
+key in the URL. Earlier we hardcoded the publisher's name in the URLconf, but
 what if we wanted to write a view that displayed all the books by some arbitrary
 publisher?
 

docs/topics/http/urls.txt

@@ -556,7 +556,7 @@ in their final forms either for embedding in generated content (views and assets
 URLs, URLs shown to the user, etc.) or for handling of the navigation flow on
 the server side (redirections, etc.)
 
-It is strongly desirable to avoid hard-coding these URLs (a laborious,
+It is strongly desirable to avoid hardcoding these URLs (a laborious,
 non-scalable and error-prone strategy). Equally dangerous is devising ad-hoc
 mechanisms to generate URLs that are parallel to the design described by the
 URLconf, which can result in the production of URLs that become stale over time.

docs/topics/testing/advanced.txt

@@ -357,7 +357,7 @@ Advanced features of ``TransactionTestCase``
                 self.assertEqual(lion.pk, 1)
 
     Unless you are explicitly testing primary keys sequence numbers, it is
-    recommended that you do not hard code primary key values in tests.
+    recommended that you do not hardcode primary key values in tests.
 
     Using ``reset_sequences = True`` will slow down the test, since the primary
     key reset is a relatively expensive database operation.