Is there a reason why you shouldn't use 'integration variables'?

Question

I tend to create a variable whenever I need an uncircumstantially same value as to that of an earlier value more than once (the values are not happening to be the same by chance rather they actually have to be the same). I think of them as the integration variables, as their particular value may have of no importance but the lines after depend on the value.

Here's what I mean, whenever I write code such as this (where the folder value has no particular importance, it is temporary to the scope of the script etc.):

mkdir my_dir
...
touch my_dir/my_words.txt

I prefer writing:

folder_name=my_dir
mkdir $folder_name
...
touch $folder_name/my_words.txt

instead. Is there a downside to that? I am asking because most developers I work with find that harder to understand. Whereas I find it easier to understand as it hints me that where $folder_name appears the values are in fact had to be the same and it's not a coincidence that they happen to have the same value. This is especially helpful in technologies I have little experience in as I can make the connection of the same values easier.

---

Please note that where magic strings or magic numbers may have value importance, the kind of variables I'm asking particularly for may not have a value important as themselves. For example, in a division operation 0 as a value is important by itself as it breaks the operation when on the denominator (division by 0 is invalid). However, consider:

x = x + 30
x = x - 30

operations back to back, 30 value is not important by itself (if you neglect the possibility of an overflow). It's just that in both operations it has to be the same, in case you want to have an unchanged x in the end.

---

Here's another example, a dockerfile:

ARG PROJ_NAME="MySubProject" # 1
ARG PUBLISH_FOLDER="/out" # 2

FROM mcr.microsoft.com/dotnet/sdk:2.1.815-alpine3.13 AS builder
ARG PROJ_NAME # 3
ARG PUBLISH_FOLDER # 4
COPY ./${PROJ_NAME} ./${PROJ_NAME}
RUN dotnet publish ./${PROJ_NAME}/${PROJ_NAME}.csproj -c Release -o ${PUBLISH_FOLDER}

FROM mcr.microsoft.com/dotnet/runtime-deps:2.1.27-alpine3.13
ARG PUBLISH_FOLDER # 5
COPY --from=builder ${PUBLISH_FOLDER} .
ARG PROJ_NAME # 6
ENV ENV_PROJ_NAME=${PROJ_NAME} # 7
ENTRYPOINT ./${ENV_PROJ_NAME}

here my colleauges tend not to use the top two ARGs that I tend to use, and find my approach dangerous? I fail to understand why. Whereas I find it very convenient that I can just modify the arg values for the next sub project, less room for mistakes in my opinion. However, the cost of not copy/pasting values here is 7 lines in total, I tried to mark them.

Also note that, PUBLISH_FOLDER is, in my perspective, a very good example to what I call the integration variables, its value has of no importance other than the runtime uses it to copy the entrypoint from the build.

---

While I agree most of the answers here, I also believe that some of the concerns can easily be overcame by version controlling, or rather diff checking, and editors such as having to rename a string everyplace at once etc. The answers still advocate the opposite of what I'm asking. I'm asking if there's any concern on the opposite side of the coin. For example, having an additional line, for defining a variable, makes it a tid bit harder to c/p and run the line of the code.

Another one would be that it may be that you're hiding a value that you know in runtime behind a variable, which may be unclear to the next reader. If they'd seen the value they'd recognize what it means but they may be unsure if it's behind a variable defined elsewhere (then again one could write down the expected value as a comment).

Answer 1

For example, having an additional line, for defining a variable, makes it a tid bit harder to c/p and run the line of the code.

Not really. In fact the definition of variables makes code far easier to reuse. It might not apply as well to shell scripting (which I believe is the context here) but assigning variable names to things is the first step to creating reusable functions or commands. Instead of copying sections of code, you can define a reusable components that you call. Effective use of this technique is what separates novices from intermediate developers.