5 ms·

Quoting from the source code: [[ $# -gt 0 ]] && while [ "${1:0:2}" == '--' ]; do OPTION=${1:2}; [[ $OPTION =~ = ]] && declare "BOCKER_${OPTION/=*/}=${OPTION

by soygul 7y ago

Quoting from the source code: [[ $# -gt 0 ]] && while [ "${1:0:2}" == '--' ]; do OPTION=${1:2}; [[ $OPTION =~ = ]] && declare "BOCKER_${OPTION/=*/}=${OPTION/*=/}" || declare "BOCKER_${OPTION}=x"; shift; done If the ambition is to write lines like this, you can make it into ~1 line of code.

lifthrasiir 7y ago
That roughly corresponds to the following C-like pseudocode: for (i = 0; i < argc && (arg = argv[i]).startswith("--"); ++i) if (sep = arg.find("=")) opts[arg[..sep]] = arg[sep+1..]; else opts[arg] = "x"; It might be too much for one line, but it doesn't seem to be super complicated either. In fact that line is (as of now, commit 0006330) only the second longest in that file.
- deleted 7y ago
  [deleted]
- oblio 7y ago
  I'd definitely refactor your C-like pseudocode to multiple lines :-D
  - lifthrasiir 7y ago
    Of course, in real projects I don't write such codes. But that's not because it is harder to read, but because it is harder to alter; say, if you have another condition for say `-v` vs. `--verbose` then you would have to reformat it to multiple lines. The meaning of the quoted line is not hard to figure out if you know a bit of bash, and that's all I would expect from a showcase.
    - kubanczyk 7y ago
      Of course what you fight for is readability and only readability. Especially in large projects. There will be literally 10 man-hours spent on reading this for each 1 man-hour of reading-followed-by-altering-it.
boobsbr 7y ago
I think a perl expert can write it even shorter.
- bliss 7y ago
  I love perl because it's fast, but it definitely follows the WORN pattern. Write Once Read Never. No matter how many commnets I leave for future me, it's always a voyage of discovery reading my own code, forget reading anyone else's :)
  - etripe 7y ago
    If that's really what you think and you think it's down to the language, look up Modern::Perl (0) and, if you're object inclinded, Moo (1), Mouse (2) or Moose (3). Then there's always perlcritic (4), too. In my mind, it's down to it having been popular, attracting many amateurs. You'll find equally unmaintainable bash or PowerShell scripts and definitely as much garbage, WORN JavaScript code. Writing maintainable code requires both knowledge and effort. [0]: https://metacpan.org/pod/Modern::Perl https://metacpan.org/pod/Modern::Perl [1]: https://metacpan.org/pod/Moo https://metacpan.org/pod/Moo [2]: https://metacpan.org/pod/Mouse https://metacpan.org/pod/Mouse [3]: https://metacpan.org/pod/Moose https://metacpan.org/pod/Moose [4]: https://metacpan.org/pod/perlcritic https://metacpan.org/pod/perlcritic
    - arkadiytehgraet 7y ago
      ALL of the listed above libraries are complete garbage, impossible to use productively among several developers. I worked in a company that had huge Perl codebase, which made extensive use of the Moose library. After trying to make sense of it, I gave up and used plain Perl, writing it as unidiomatic and simple as possible, so that hundreds of other devs, also new to Perl, would be able to understand the code I wrote. This was the common sentiment - most of the people followed the same path. The library is just a nightmare - Perl is dynamically typed, there is NO adequate IDE support (compared to the one statically typed languages have), so good luck with working out how the library works underneath. And if I cannot understand that, how on Earth will I understand what even my code is doing? (Never mind the others') In my mind, the amateurs are those that created the libraries without any idea on how they are going to be abused, thinking everyone should use unreadable incomprehensible syntax coupled with unapproachable internals. I apologize for the rant, I had no idea this topic moved me so much.
bawolff 7y ago
I dont even read or write bash shell scripts regularly and i can understand what that line is doing fine. I would not be able to understand if the entire thing was one line, so i think there is a significant difference. Just because something doesn't follow general rules for readable code, doesn't mean it is actually unreadable.
- eru 7y ago
  I don't think it's that hard to read, but breaking over multiple lines probably wouldn't hurt.
- viraptor 7y ago
  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.
  - bawolff 7y ago
    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.
    - organsnyder 7y ago
      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.
Xophmeister 7y ago
This isn't really that horrible; just condensing the boilerplate that comes with command line argument parsing. Sure it's quick-and-dirty, but it gets it done and moves focus your elsewhere. Interestingly, I didn't know you could do this without an `eval`: declare something${something_else}=whatever

by soygul 7y ago

lifthrasiir 7y ago

That roughly corresponds to the following C-like pseudocode: for (i = 0; i < argc && (arg = argv[i]).startswith("--"); ++i) if (sep = arg.find("=")) opts[arg[..sep]] = arg[sep+1..]; else opts[arg] = "x"; It might be too much for one line, but it doesn't seem to be super complicated either. In fact that line is (as of now, commit 0006330) only the second longest in that file.

deleted 7y ago
[deleted]
oblio 7y ago
I'd definitely refactor your C-like pseudocode to multiple lines :-D
- lifthrasiir 7y ago
  Of course, in real projects I don't write such codes. But that's not because it is harder to read, but because it is harder to alter; say, if you have another condition for say `-v` vs. `--verbose` then you would have to reformat it to multiple lines. The meaning of the quoted line is not hard to figure out if you know a bit of bash, and that's all I would expect from a showcase.
  - kubanczyk 7y ago
    Of course what you fight for is readability and only readability. Especially in large projects. There will be literally 10 man-hours spent on reading this for each 1 man-hour of reading-followed-by-altering-it.

boobsbr 7y ago

I think a perl expert can write it even shorter.

bliss 7y ago
I love perl because it's fast, but it definitely follows the WORN pattern. Write Once Read Never. No matter how many commnets I leave for future me, it's always a voyage of discovery reading my own code, forget reading anyone else's :)
- etripe 7y ago
  If that's really what you think and you think it's down to the language, look up Modern::Perl (0) and, if you're object inclinded, Moo (1), Mouse (2) or Moose (3). Then there's always perlcritic (4), too. In my mind, it's down to it having been popular, attracting many amateurs. You'll find equally unmaintainable bash or PowerShell scripts and definitely as much garbage, WORN JavaScript code. Writing maintainable code requires both knowledge and effort. [0]: https://metacpan.org/pod/Modern::Perl https://metacpan.org/pod/Modern::Perl [1]: https://metacpan.org/pod/Moo https://metacpan.org/pod/Moo [2]: https://metacpan.org/pod/Mouse https://metacpan.org/pod/Mouse [3]: https://metacpan.org/pod/Moose https://metacpan.org/pod/Moose [4]: https://metacpan.org/pod/perlcritic https://metacpan.org/pod/perlcritic
  - arkadiytehgraet 7y ago
    ALL of the listed above libraries are complete garbage, impossible to use productively among several developers. I worked in a company that had huge Perl codebase, which made extensive use of the Moose library. After trying to make sense of it, I gave up and used plain Perl, writing it as unidiomatic and simple as possible, so that hundreds of other devs, also new to Perl, would be able to understand the code I wrote. This was the common sentiment - most of the people followed the same path. The library is just a nightmare - Perl is dynamically typed, there is NO adequate IDE support (compared to the one statically typed languages have), so good luck with working out how the library works underneath. And if I cannot understand that, how on Earth will I understand what even my code is doing? (Never mind the others') In my mind, the amateurs are those that created the libraries without any idea on how they are going to be abused, thinking everyone should use unreadable incomprehensible syntax coupled with unapproachable internals. I apologize for the rant, I had no idea this topic moved me so much.

bawolff 7y ago

I dont even read or write bash shell scripts regularly and i can understand what that line is doing fine. I would not be able to understand if the entire thing was one line, so i think there is a significant difference. Just because something doesn't follow general rules for readable code, doesn't mean it is actually unreadable.

eru 7y ago
I don't think it's that hard to read, but breaking over multiple lines probably wouldn't hurt.
viraptor 7y ago
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.
- bawolff 7y ago
  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.
  - organsnyder 7y ago
    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.

Xophmeister 7y ago

This isn't really that horrible; just condensing the boilerplate that comes with command line argument parsing. Sure it's quick-and-dirty, but it gets it done and moves focus your elsewhere. Interestingly, I didn't know you could do this without an `eval`: declare something${something_else}=whatever