Code feedback on this custom envelope panel

[Oli Ullmann]

@dannytaurus
That looks great!

@Christoph-Hart I also created my own panel because I had performance issues with theFlexEnvelope FloatingTile. It caused significant lag in the user interface and the interface of my DAW (Cubase).

[ustk]

@David-Healey said in Code feedback on this custom envelope panel:

I didn't know you could declare a function within a paint routine. Somehow that feels wrong to me :) I'd declare it outside, but if it works it works.

I tend to do it this way nowadays, inlining as many functions as I can for paintRoutines, mouseCB... And sub functions can be used elsewhere when necessary

MainPanel.setPaintRoutine(drawMainPanel);

inline function drawMainPanel(g)
{
	subFunction1();
	subFunction2();
}


inline function subFunction1()
{
	
}

inline function subFunction2()
{
	
}

[David Healey]

@ustk Yes that's my approach too.

A few things in my mind when writing code:

• Don't indent more than 2 levels - there are exceptions, for example when using nested loops.
• Make the code readable, even if it ends up a little more verbose.
• The code should be self documenting as much as possible, no need for comments
• Be consistent with naming, use of brackets, etc.

Basically the stuff I put in the style guide.

I also use type-safety for all my functions now, except in a few instances where I want to allow for undefined return types.

[ustk]

@David-Healey all the same except for type-safety which I didn't really see the gain for me now as I am very careful on the caller side... But I understand where it can help

[dannytaurus]

@ustk said in Code feedback on this custom envelope panel:

I tend to do it this way nowadays, inlining as many functions as I can for paintRoutines, mouseCB...

Is this mainly for readability and reusability? Or is there a performance improvement too?

[ustk]

@dannytaurus inline functions tend to perform better

[dannytaurus]

@ustk I thought inline functions were placed inline at their call spot during compilation, hence the name? Which would end up putting them all back where they were refactored out from.

Although I now think I remember Christoph saying recently that wasn't the case?

[David Healey]

@ustk said in Code feedback on this custom envelope panel:

@dannytaurus inline functions tend to perform better

For paint routines and mouse callbacks I'm not sure it makes a difference since the paint routine or mouse callback is still a regular function.

@dannytaurus said in Code feedback on this custom envelope panel:

Although I now think I remember Christoph saying recently that wasn't the case?

You remember correctly, he was lying to us this whole time :p

[dannytaurus]

@David-Healey @ustk I'm not against the concept of refactoring stuff out to inline functions at all, it's a very common pattern in Ruby. Lots of small well-named methods can make the code a lot easier to reason about.

Also helps with the self-documenting code idea.

@David-Healey

[ustk]

@David-Healey said in Code feedback on this custom envelope panel:

For paint routines and mouse callbacks I'm not sure it makes a difference since the paint routine or mouse callback is still a regular function.

Yes but the way I understand it (might be wrong though) is that it's faster to execute even if the outside part isn't inlined. The inline part containing locals, the code execution inside it seems faster especially for long paint routines or mouseCB. Then what happens after this isn't affected but at least the script part might be improved.