G'day vr,
"I'm asking for advice on style, rather than how to solve a problem. How a professional would do it? What's readable to others -- and myself, in a year? So, all answers are maybe just opinion based and are welcome :-)."
[That seems to somewhat contradict the title of your post. My response is based on what I've quoted from the body of your post.]
The first thing I suggest you do is read "perlstyle - Perl style guide". Everyone has their own preferred style, and that's fine; however, regardless of the style you choose, the ultimate goal is code, written in a consistent manner, that's easy to read.
Next, I'd recommend reading "perldsc - Perl Data Structures Cookbook". While I can generally work around the odd typo, there's so many inconsistencies here that I'm left wondering if you really understand the subject matter.
You start by saying you have an "AoHoAH": that's not a real thing; what's the "AH" part? Although I can assume a typo, I don't know whether there's an extra "A" (AoHoH); and extra "H" (AoHoA); or a missing "o" (AoHoAoH). None of that really matters though: on the very next line you present a HoA as the root structure!
You should be able to represent the structure (of whatever you really have) in such a way that it stands by itself without requiring a prosaic description. Take a look at the output of Data::Dumper or Data::Dump to see how they do it.
Hash elements are key-value pairs. There's three instances where you've named the key "value". That, in itself, is likely to cause confusion. You've exacerbated the situation by using the same key name (i.e. "value") in different places in the structure hierarchy and then using different datatypes for the values (that's the values of the keys, not the names of the keys). I'm getting confused just talking about it.
You talked about '"Items" hash': I see no code resembling "Items => {...}". There is a key called "type" with the value 'items': there's another associated key (called "value") whose value is an arrayref. The confusion just mounts.
You haven't used meaningful names. You've used almost identical names (cf. fooqux and fooquux): more potential confusion and errors here. You have some function names, in your code, in uppercase (SPLIT_FOO and SPLIT_IF_FOO) without any obvious reason for doing so; your description has another, SPLIT, which doesn't appear in your code. If you can't provide a meaningful name then you probably haven't described, to a sufficient degree, your problem, your solution, or both.
You've bunched up much of your code, reducing readability; you've also spread out other parts of your code (for no useful reason, as far as I can tell), in a non-standard fashion, further reducing readability. There is no direct correlation between code size (or perceived cleverness) and efficiency: use Benchmark where necessary.
You also wrote, "hopefully will do everything right". Don't hope, test. See Test::More.
On the whole, I'd say that what you've presented displays poor style; is unprofessional; fails in terms of readability; is highly error-prone; and is not easily maintainable. I'd scrap it completely and start again from scratch: I suspect that would be less time-consuming than attempting to fix every problem in situ. I'd also recommend revisiting, and perhaps reworking, your original design.
— Ken
In reply to Re: To splice or not to splice? What implementation is more readable, efficient, etc.?
by kcott
in thread To splice or not to splice? What implementation is more readable, efficient, etc.?
by vr
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |