[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Use readonly wherever possible?

From: Maroloccio
Subject: Re: Use readonly wherever possible?
Date: Wed, 6 May 2020 12:04:08 -0300
User-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:68.0) Gecko/20100101 Thunderbird/68.7.0

I do as she does for positional argument renaming.

There are N parts to this:

1) I like `bar' better than `$1' as an identifier to refer to

2) Once you adopt 1), `local' seems like the right type of declaration

3) -r is expressive in intent, if you aren't going to change the value.
   The verbosity is an acceptable trade-off for that clarity, to me

4) Avoiding argument re-assignment is, by some linters and in some
   languages, even something that's watched for. I have no strong
   opinion about this per se, I just enjoy 3), but check out:


or general thoughts on marking explicitly as "const" what is
de-facto "const":


I think a good IDE and static analysis can provide the same visual signalling without the keyword if configured via colouring, underlining,
hovering pop-ups, etc. (as in the case of Java, where she probably got
her inspiration from). One gets used to picking up visual clues about
how identifiers are used in a certain scope, such as when you click on
one and see every place it gets used, etc.

Let it be, I would say. It does not harm, after all, and you do express
*more* to people reading the code, via it. Repetition-fatigue is very
context-specific, you'll get used to it and skip it if you dislike it.

On 06/05/2020 09:35, Greg Wooledge wrote:
On Wed, May 06, 2020 at 10:44:08AM +0200, D630 wrote:
Recently, I had to review one of my team members shell code. She is a Java
developer, and used to declare variables with the final keyword. So in shell
she was constanly using the readonly attribute like:

foo() {
        local -r bar=$1
        local -r lich=$2
        echo "$((bar * lich))"

I think that's unusual code in the shell-code universum. My first reflex was
to say "No, don't do that", but I hesitate with my answer, because I have no
idea what happens exactly in bash when a variable is declared readonly. So
is there any advantage in using readonly wherever possible?

Go with your instinct.  Readonly is bad news in bash.  It's not designed
to be a temporary shawl that you put over a variable.  It's designed to
be permanent.

We just had a similar discussion on bug-bash:

reply via email to

[Prev in Thread] Current Thread [Next in Thread]