I don't think soygul is so much challenging the readability of the line, but rather pointing out the hazards of focusing on the # of lines of code as a unit of simplicity/complexity.

Do you actually know what it's doing, or are you guessing and inferring from patterns? There's a difference when you actually need to read the source for details rather than a quick skim.

I can definitely guess the pattern and I do write bash regularly, but I see at least 2 things I'd need to double-check the man page for the behaviour.

If you are asking if i have memorized bash syntax fully and know that everything he did was valid, than the answer is no. However the intent of the code and what each component is supposed to do is clear, which is what i'm looking for when reading code.

Heck, by this definition i'm not sure any code is really good enough. In my job i have to write php daily, i still need to regularly look at docs to figure out order of arguments for various library functions. I wouldn't be able to tell if explode($a, $b) in php has the right argument order at a glance without looking it up. But i understand the intent and generally assume the superficial aspects of the code are right unless that part appears not to work.

And furthermore, adjusting the number of newlines isn't going to help with the question of if that piece of code is using bash syntax correctly.

I don't see anyone claiming that the syntax is incorrect. But it definitely causes me to have to stop and do some mental processing (mainly thinking about order of operations) to make sense of it.

Admittedly, PHP is kinda legendary for having accidentally ended up with all sorts of odd argument orders.

Other languages seem to've made things at least somewhat more predictable.

(and then, being software, suck in different ways of course)

Good code should not only be "readable", but it should be as easy to read as possible. Potentially a lot of people will read this code, and all of them will need to spend extra-time processing it because it's hard to read. Long lines are usually harder to read, which is why most coding guidelines recommend limiting lines length to 80 chars, this one is 178.

If you pick bash as your programming language, don't you already throw "readable" out of the window?

Perl gets a lot of flak for being unreadable, but I personally have more difficulty understanding bash code than perl (not implying that perl is super readable).

Lets say you write in bash like this:

  if [[ $OPTION =~ = ]]
  then
      declare "BOCKER_${OPTION/=*/}=${OPTION/*=/}"
  else
      declare "BOCKER_${OPTION}=x"
  fi

Going from here, if you rewrite this in golang you'd probably improve readability.

But the readability has not been "thrown out of the window" yet, like in this case:

  [[ $OPTION =~ = ]] && declare "BOCKER_${OPTION/=*/}=${OPTION/*=/}" || declare "BOCKER_${OPTION}=x"

Oh I see your point.

Yeah, that was unnecessary. Ironically now I remember that I was once frustrated by someone who was using Boolean logic to emulate if/else in Python.

It would take very little effort to put it in multiple lines, which would probably make it more readable.

I don't think it's that hard to read, but breaking over multiple lines probably wouldn't hurt.