From be402891cd78f484b7f67e486924975523516ced Mon Sep 17 00:00:00 2001 From: Ahmed Nassar Date: Mon, 14 Apr 2025 14:12:56 -0300 Subject: [PATCH] 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 | 6 +++--- docs/howto/custom-template-tags.txt | 4 ++-- docs/howto/initial-data.txt | 2 +- docs/howto/outputting-csv.txt | 2 +- docs/internals/deprecation.txt | 2 +- docs/intro/tutorial03.txt | 2 +- docs/intro/tutorial07.txt | 2 +- docs/ref/contrib/flatpages.txt | 2 +- docs/ref/contrib/sites.txt | 2 +- docs/ref/contrib/syndication.txt | 2 +- docs/ref/models/instances.txt | 2 +- docs/ref/templates/builtins.txt | 4 ++-- docs/releases/1.5.txt | 2 +- docs/releases/1.6.txt | 4 ++-- docs/releases/1.8.txt | 2 +- docs/topics/cache.txt | 2 +- docs/topics/class-based-views/generic-display.txt | 2 +- docs/topics/http/urls.txt | 2 +- docs/topics/testing/advanced.txt | 2 +- 19 files changed, 24 insertions(+), 24 deletions(-) diff --git a/docs/howto/custom-model-fields.txt b/docs/howto/custom-model-fields.txt index fefd8740e7..915c4e9c37 100644 --- a/docs/howto/custom-model-fields.txt +++ b/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)" diff --git a/docs/howto/custom-template-tags.txt b/docs/howto/custom-template-tags.txt index b5577eef7b..a7f413fca1 100644 --- a/docs/howto/custom-template-tags.txt +++ b/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, diff --git a/docs/howto/initial-data.txt b/docs/howto/initial-data.txt index a8c5a57726..d0d94ffd12 100644 --- a/docs/howto/initial-data.txt +++ b/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. diff --git a/docs/howto/outputting-csv.txt b/docs/howto/outputting-csv.txt index 8e4bd8108c..6f2eedf3ba 100644 --- a/docs/howto/outputting-csv.txt +++ b/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"), diff --git a/docs/internals/deprecation.txt b/docs/internals/deprecation.txt index 37730ca982..2e0dbb02e5 100644 --- a/docs/internals/deprecation.txt +++ b/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. diff --git a/docs/intro/tutorial03.txt b/docs/intro/tutorial03.txt index a19f9c949d..be6251f5f2 100644 --- a/docs/intro/tutorial03.txt +++ b/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. diff --git a/docs/intro/tutorial07.txt b/docs/intro/tutorial07.txt index a8d5e61b81..bf695d551c 100644 --- a/docs/intro/tutorial07.txt +++ b/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 diff --git a/docs/ref/contrib/flatpages.txt b/docs/ref/contrib/flatpages.txt index 3722aca2b4..3d0aca9156 100644 --- a/docs/ref/contrib/flatpages.txt +++ b/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 `:: +to hardcode their URLs in the :doc:`URLconf `:: from django.contrib.flatpages import views diff --git a/docs/ref/contrib/sites.txt b/docs/ref/contrib/sites.txt index d69e4c8e81..f6c39feff7 100644 --- a/docs/ref/contrib/sites.txt +++ b/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:: diff --git a/docs/ref/contrib/syndication.txt b/docs/ref/contrib/syndication.txt index d0a3cc41f7..a81b428d45 100644 --- a/docs/ref/contrib/syndication.txt +++ b/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. diff --git a/docs/ref/models/instances.txt b/docs/ref/models/instances.txt index e15e1c93bf..674626b23f 100644 --- a/docs/ref/models/instances.txt +++ b/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 diff --git a/docs/ref/templates/builtins.txt b/docs/ref/templates/builtins.txt index f3d967b153..1eb391d8c0 100644 --- a/docs/ref/templates/builtins.txt +++ b/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 diff --git a/docs/releases/1.5.txt b/docs/releases/1.5.txt index 76d41a9ab8..ac3be6cfbd 100644 --- a/docs/releases/1.5.txt +++ b/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 diff --git a/docs/releases/1.6.txt b/docs/releases/1.6.txt index 4e4309750f..f066f877c5 100644 --- a/docs/releases/1.6.txt +++ b/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. diff --git a/docs/releases/1.8.txt b/docs/releases/1.8.txt index bf4a81aa9d..d222888cbf 100644 --- a/docs/releases/1.8.txt +++ b/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. diff --git a/docs/topics/cache.txt b/docs/topics/cache.txt index ae880bbc2f..3f8c00d160 100644 --- a/docs/topics/cache.txt +++ b/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, diff --git a/docs/topics/class-based-views/generic-display.txt b/docs/topics/class-based-views/generic-display.txt index fd3f3c78c9..81c800e213 100644 --- a/docs/topics/class-based-views/generic-display.txt +++ b/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? diff --git a/docs/topics/http/urls.txt b/docs/topics/http/urls.txt index d8de9635ec..d92beb3394 100644 --- a/docs/topics/http/urls.txt +++ b/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. diff --git a/docs/topics/testing/advanced.txt b/docs/topics/testing/advanced.txt index 79d3f97f48..72373c6107 100644 --- a/docs/topics/testing/advanced.txt +++ b/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.