Standards or best practices or ....

Development
21

At work eslint keeps us pretty honest, but that’s of course only for javascript and typescript. I’ve always been a big believer in unit tests - I know some ppl do them for VCV, but probably most don’t. At work my group re-configured our pieces to require 100% code coverage, whereas the project as a whole it “only” set up to require 95%.

between typescript and lint it would find this issue. You would get a “build” error that would say that you are trying to dereference and object that may undefined. Assuming you declare the function correctly:

foo(x: number, y: string) : string | undefined {
}

Similarly it will tell you "you declared this function as returning a string, but only line xyz you are returning undefined. We have our projects set up so those errors are fatal.

22

I also insist people put the url in the comments they stole code from on Stack Overflow in case it ever gets updated :wink:

1 Like
23 
-- Installing into '/home/jackokring/Rack/plugins/Airwin2Rack/dep/cmake-build/dist'
-- Configuring incomplete, errors occurred!
See also "/home/jackokring/Rack/plugins/Airwin2Rack/dep/cmake-build/CMakeFiles/CMakeOutput.log".
make: *** [Makefile:32: dep/cmake-build/plugin.so] Error 1
24

Did you submodule update?

25

Type systems are great for correctness

Std optional is a wonderful way to force you to check for null tor instance just like std uniqueptr is a great way to avoid leaks and ownership bugs

Other languages are better at this but c++17 has great tools if you choose to use them

Totally agree on formatting. We fail ci if surge or surge rack have code which doesn’t match our clang format

And agree on testing in rack. Seems like something folks just don’t kinda have tooling for. I would love a module that adds and deletes another module 1000 times and so on

2 Likes
26

I just run my unit tests under address sanitizer, so no need for the thousand load test.

27

wow hold on you have unit tests which do full threaded ui creation and deletion with asset loads and everything? can I get those? that’s awesome!

28

oh! no, not at all, I’m still (was) using my old unit tests, which only test the part of the module that processes audio. I don’t have any tests at all up at the Widget level ;-(

29

Who else is a fan of #pragma ivdep?

EDIT: automatic vectorization can-o-worms…

30

ahh right

so we have pretty good unit tests down at the base of surge; but my rack surge bugs have all come when i wrap it in a module so i sort of need something like ‘open up this module and fire a random midi-like stream at these ports’ or ‘click this button faster than we respond to it’. those are things which have caught me out that I don’t know how to test which is why i thought of the stresser/fuzzer module.

2 Likes
31

To extern or not to extern that is the question. We bver it better ti’be an extern in plugin.hpp and an implementation in plugin.cpp for some I-cache locality code reuse, or to splurge on .hpp/.cpp file pairs per item of reuse?

EDIT: extern int maxPoly(Module *m, const int inMax, const int outMax); in particular (no auto auto)?

EDIT2: yes, I do like type before name prefix languages as filter before option is better. Or perhaps option auto filter append might be better? DSL transformers and the like.