End of Year G'MIC gmic-community code review

Software G'MIC
1

I’ll only be reviewing active authors’ code review in gmic-community. So, for now, I will review @garagecoder code, and @afre if he plans to get back any time soon. I won’t be doing joan_rake or others since they won’t be here to review their code or look at this feedback. I’ll also be looking into reviews of my own code and see where I can do improvement.

For garagecoder:

  1. If there is any slow GUI filters, then _persistent should be somewhere here or there if possible. It’s hard to work with _persistent in some case, but the boost is interactivity is worth it. For a example of how difficult it is to write with _persistent at time, see my GUI filter named Lavander Binary Map and theorize a version without _persistent. Without _persistent, a lot less code, but also, you don’t have the benefit of storing the results in memory, so you’d have to do calculation again.
  2. If there is any inaccurate previews, then there should be a * denoting full-size preview on the title portion of #@gui filters.
  3. On filters with repeat $! l[$>] done done, these can be replaced with foreach {} blocks. gcd_aurora is one of them that doesn’t have this replacement. It seems that there can be more cases of { } blocks instead of done in the end sentences. This makes it easier for one to use text editors that automatically select the other brackets to understand the code structure.
  4. More new lines should be placed. In the case of code as large as fx_gcd_layeretch, it would be easier to parse if there was more new lines. gcd_hsl is more of a example of what I see as more understandable.
  5. gcd_force_rgba seems to be redundant when to_rgba exists. There’s also to_automode to look at (not the same command or function, but it’s nice to know we have a command that automatically reduces image to lowest spectrum count without changing the image.

Other than those, I do think the algorithm are sound and the usage of C++ calls are all perfect.

1 Like
2

That’s very noble, code review can often be a slog. Reviewing my own past filters is on the todo already, but only to fix actual errors or problems. So although any tips (and code style etc.) are appreciated, actual bugs are by far the most useful. I say that, because refactoring can create yet more bugs… that’s time I could spend on other things!

1 Like
3

I left you a PM with some better structured code for you to look at. May be easier to find sources of bugs too. I didn’t do everything though. Just 15 minutes fix is all I did.

I agree, and I prefer to leave that during the middle of the year of the end of the year. Mostly looking into syntax is what matters.

Refactoring shouldn’t do that if done correctly.

1 Like
4

My code has been stale for 1.5 years. Much of it is broken or not working as intended. That could be because I maintain personal *.gmic files and neglect to update the community file. I also have a bad habit of deleting them by accident, so any brilliance is ephemeral. Embarrassing indeed. Coding and math don’t come naturally to me. The brain fog only gets worse with time.

The good thing is that many of my ideas live on in other people’s code inspired by the public and private conversations I have with you all.

So, while I appreciate a review, I am in a similar boat as @garagecoder. I will have to sit down one day, clear out the chaff, put everything under testing and rewrite things.

1 Like