On 2/9/11 7:08 AM, Stefan Monnier wrote:
- clean code (not obfuscated)
Obviously agreed. But there are likely disagreements about what is
"clean" and what is "obfuscated". Turning a oneliner sed into
a 10-liner read/while/case/set loop is usually not an improvement in my
book (as discussed previously). If you want to avoid forking a sed
process while keeping the code clean, you'll probably want to first
develop a library of sh functions that let you do things like `map' an
operation over a list of things.
It does NOT help to make a oneliner and 1000 users asks
themself: what does THIS line? [3]
sed code can be inscrutable, yes, but a single `s'ubstitution is not, no
matter how complex the regexp may be. This doesn't meant that
a oneliner sed script is necessarily the best option, just that it's
probably not the thing on which to concentrate.
But while we are at it:
- don't fork, if not needed. examples from /etc/init.d/compache:
[ "`cat /proc/swaps | grep 'ramzswap0'`" != "" ]&& swapoff /dev/ramzswap0
That's an obvious one, yes. It's even a great contender for the Useless
Use of Cat Award (http://partmaps.org/era/unix/award.html).
better use:
fgrep -q "ramzswap0" /proc/swaps || ...
Yes, *much* better. I'd even call it a bug-fix (think of the day
where /proc/swaps decides to start lines with a dash).
- use function_names to say what you want to do
Agreed.
- use better shell builtins, instead of invoking another language
(e.g. awk, sed, lua) - only if there is no other option
"No other option" is much too strong here: we want the code to be clean,
first and foremost, so if the awk code is cleaner I'd much prefer we use it.
- using of shell builtins, leads to lower mem usage and are (mostly) faster
Yes, but the shell's facilities are very primitive. Sometimes it's
a bit like writing assembly code. Hence the need for a good library of
shell functions that encapsulate the low-level code.
Well, yes and no. Bash has a lot better regexp and substitution capabilities
than dash.
-Philip
- make an official coding-style (at the moment much is mixed)
Fine. Might prove difficult, but it's a worthy experiment.
- make an offical way, how to solve typical problems in scripts
Seems to say the same as the previous point, so again: fine.
- make "base-files (experimental)" which can be selected in menuconfig
and i will maintain it. if people select it, they know the risk
I'll let OpenWRT maintainers decide if it's a good idea. But I don't
think it's particularly necessary: if you submit a patch which actually
improves the code (e.g. the cat|grep thingy above), I see no reason to
leave it in an "experimental" branch rather than in the normal files.
OTOH, if there's disagreement over whether it's an improvement, then it
just means it needs more work or should be dropped.
Then again, maybe some of the changes can't be made incrementally.
In that case, maybe a separate branch is in order.
Stefan
_______________________________________________
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
