Re: Use readonly wherever possible?

[Maroloccio]

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:

* 
https://pmd.github.io/pmd-6.1.0/pmd_rules_java_codestyle.html#methodargumentcouldbefinal
* https://eslint.org/docs/rules/no-param-reassign
* https://palantir.github.io/tslint/rules/no-parameter-reassignment/
* 
https://checkstyle.sourceforge.io/apidocs/com/puppycrawl/tools/checkstyle/checks/coding/FinalLocalVariableCheck.html

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

* https://isocpp.org/wiki/faq/const-correctness

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:
>
> https://lists.gnu.org/archive/html/bug-bash/2020-04/msg00200.html