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:

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

FROM mcr.microsoft.com/dotnet/sdk:2.1.815-alpine3.13 AS builder
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
COPY --from=builder ${PUBLISH_FOLDER} .

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).

  • 2
    You appear to be describing magic numbers. No, it is not a bad practice to ensure that a value appears once. It may not be a big deal in very small scripts, which bash scripts tend to be. Commented Nov 29, 2021 at 17:57
  • @VincentSavard I used sh script syntax as I'd assume more people are familiar with it but in fact I've seen friction in over 200 lines of GitHub Action Workflows for example.
    – Nae
    Commented Nov 29, 2021 at 17:59
  • 1
    Does this answer your question? What is wrong with magic strings? Commented Nov 29, 2021 at 18:38
  • 1
    It seems you already know any "cons", so don't overthink this.
    – Doc Brown
    Commented Nov 29, 2021 at 19:02
  • 1
    Any computer programmer will be in your camp when it comes to the choice between using literal values and variables. But $folder_name as an identifier is not particularly helpful. Your variable names should be meaningful and tell what the values that are assigned to them are for. Commented Dec 2, 2021 at 20:11

1 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.

  • 2
    Yes, variables are a first step in abstraction: loops and functions are next.
    – Erik Eidt
    Commented Nov 29, 2021 at 21:50
  • 2
    It applies very well to shell scripting, primarily with the example OP gave (a directory name). I've created a lot of scripts that use %CONFIG_DIR%, %OUTPUT_DIR%, %BUILD_CONFIGURATION%, etc. that are defined right at the top of the file and used 20+ times within. If (when) you need to change a directory there is only one spot to change.
    – JMekker
    Commented Nov 30, 2021 at 1:49
  • 1
    @JMekker Right. It definitely applies but what I mean is that this is the first step towards creating parameters that can be passed to abstractions. While that is definitely relevant to scripting, it's not as frequently done, in my experience as it is in application development.
    – JimmyJames
    Commented Nov 30, 2021 at 15:41

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.