On 2014-09-24 21:10:11 -0300, Raphaël Droz wrote:
> I had a quick look at Friebel's version. Indeed it implements the
> above requested features. Anyway, I found it much less readable that
> Gentoo's version.
I agree that it isn't much readable. Well, not that exactly. The
main problem is that it lacks comments / internal documentation.
This didn't prevented me from doing some local changes.
> It actually used functions, but too many of them (although simple
> wrappers). I couldn't tell if its "overkill" or "flexible" enough,
> but from a code readability POV it's seems more difficult.
>
> - Things like cmd_exist(), filecmd(), msg() or show() seems more annoying
> than really useful.
cmd_exist() is useful to avoid spurious errors when a command hasn't
been installed (the "&& return 0 || return 1" is probably useless,
though, except if the goal was to make it work with "set -e").
I wonder why filecmd() isn't merged with filetype(). Otherwise it
is useful.
msg() seems to be new (I still use an old version, where it isn't
present).
I don't think that show() is useless: it has recursive calls.
> - All the things like: ${rest1#$sep}, ${rest11%%$sep*}, or
> ${rest11#$file2} in show(), while valid bash-expression makes the code
> less readable.
I completely disagree. This is standard POSIX shell syntax, which
can be found in many shell scripts, and I had never heard of any
complaint. It's faster than invoking sed.
As a comparison, zsh internal scripts are really unreadable, because
this kind of transform is often done in a nested way, with various
flags that change the behavior.[*] But here, this is simple enough.
[*] As examples:
lopts+=("${^tmp[@]}":${${${opt//:/-}//\[/(}//\]/)})
"$tmpargv[(I)(|\([^\)]#\))(|\*)${opt}(|[-+]|=(|-))(|\[*\])(|:*)]"
\${tmp#\${(j(${sep}))~\${(@)\${(@)keys[2,(rn:num:)\$key]}/*/*}}${~sep}}
> - All the istar(), isdvi(), ... 1 to 5 lines wrappers does not make
> lesspipe more friendly as are the if/elif constructs. In this regard
> the clear and simple "case" construct of the Gentoo version is more
> readable and maintainable for features equality.
Yes, a "case" construct may be better.
--
Vincent Lefèvre <[email protected]> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
--
To UNSUBSCRIBE, email to [email protected]
with a subject of "unsubscribe". Trouble? Contact [email protected]
