Refactor a composition

Discussions
, , ,
1

Hi,

Wanted to share my thoughts on refactoring a composition and what helps me, hoping to get some feedback or ideas from you. Sorry if this seems like a splitting hairs.

Attached is my composition that calculates the 0 <= numbers <= 3, for example, and calculates the sum of those numbers…

What (in my opinion) refactoring a Vuo composition should include:

  1. Efficient use of nodes to avoid repetition and use of unnecessary nodes yourself (where possible): sometimes directly translating an algorithm from paper might not be the best way due to available higher level nodes that does the job (requires getting accustomed to them). The attached example is a direct translation of my algorithm written out in the comment of the composition - you’re welcome to refactor the composition and make it smaller.
  2. Consistent use of colour: grouping the nodes into coloured classes,
  3. Arranging nodes in a compact left to right and top-bottom arrangement that best illustrates the flow of data and events and the algorithm structure that was pre-planned.
  4. Looped nodes should be aligned on-top of each while keeping to 3 above.
  5. Use of comment boxes to group nodes into general categories of function in large compositions (I’ve not done this in the attached) and to summarise the node data outputs when helpful.

I’d like to get your thoughts or the best practices that you have learned through experience. Any advice on how to refactor the attached would be most appreciated.

sum_final-2.vuo (6.44 KB)

4 Likes
2

All these sound like a good set of best practices, sure, why not. I might add for #6: “keep it loose”. :-)

I’d also want to add something to account for my messy and mental long list of mistakes and creative tangents when trying to figure something out. Come to think of it, let’s just call it iterative design, with the credo “it’s good to fail”, where mistakes are made and the broken parts are picked up again and reassembled, hopefully by showtime.  

2 Likes
3

Nice @jersmi thank you

4

A couple more ideas:

1 Like
5

I’m definitely in the MOIST camp apparently :sweat_smile:. I’m struggling to understand the point of the composition. If the point is to count down from 3 to 0, then sum the countdown, I’d just do as in the attached composition (but would probably not comment it that much if it wasn’t for the task). It does pretty much the same thing, and is by the looks of it a tad bit faster at it. I got <.03333 seconds for the attached comp repeatedly at ideal conditions VS <.050000… seconds in the original. These are based on frame times though, and can be impacted quite a bit by other open windows and overlays so a couple grains of salt is needed for that timer. I did get outliers at .16 and .18 respectively sometimes for both of them.

I use node naming a lot when building my own stuff rather than comments. Trying to make it easily readable/understandable from the nodes and structure itself is less time consuming than excessive commenting. When noodling intensifies, focus on commenting quickly looses its importance. I look at it as a tradeoff between getting things done and getting things done correctly. That can depend on who is paying the bill. If it’s a one-off exported app, it doesn’t matter much. If it’s a repeated task, a commented subcomp is usually better (to then drop into small exports). If I’m the only one that looks under the hood, and I can understand what’s going on from node names and colors, I wouldn’t care much about comments. If it’s for others to see, use and modify - comments are very necessary.

Refactored.vuo (3.68 KB)