Refactor the Plot Module

What can we do to make ScottPlot better?

Current Plot.cs source file contain about 2500 lines of code. Each time working with such a huge file is difficult. Grouping by regions only partially solves the problem. Most of the code is API from which there is no escape.

It may make sense to split the current class into different files, at least we can move the PlotScatter, PlotSignal, etc API definitions to a separate file, or even better to a group of files.

Plot.cs

public partial class Plot
{
 // all definitions without Plottables API
  ....
}

PlotPlottablesAPI.cs

public partial class Plot
{
  public PlottableScatter PlotScatter(...)
  {
   ...
  }
  public PlottableSignal PlotSignal(...)
  {
    ...
  }
 ...
} 

[swharden]

Dropped out for a couple of days, sorry.

No worries!

It looks like you yourself decided everything in the best way.

I’m glad you agree with this direction 👍

if you dump all PlotPlotable into one file, it will still turn out to be huge, it would be great to split all existing Plotables into 3-5 logically related groups and implement the api of each of these groups in a separate file.

I like this idea! Perhaps we can break it into these groups. If we do this, perhaps we should move Plot.cs into Plot/Plot.cs and put all these files in that folder (without changing the namespace) to keep them together.

• Plot.PlotBar.cs - population, bar
• Plot.PlotFinance.cs - candle, ohlc
• Plot.PlotScatter.cs - scatter, point, line
• Plot.PlotSignal.cs - Signal, SignalXY, SignalConst
• Plot.PlotBitmap.cs - image, heatmap
• Plot.PlotText.cs - text, annotation
• Plot.PlotAxisLine - hline, vline, hspan, vspan
• Plot.PlotMisc.cs - errorbar, polygon, function, pie, radar, vector field

I could do a PR with everything else. Or do you have some other plans in this regard? The current state looks like it is stuck halfway.

Thank you for your offer, but I think it would be a good idea for me to do this. It has been a long time since I have looked at many of these methods and I would prefer to this carefully and slowly, refining each method one-by-one. I also want to make this change as I refactor the constructor of plottables to remove styling arguments.

The current state looks like it is stuck halfway.

Indeed! I’m experimenting with the best way to refactor plottable constructors, and I am only working on the bar plot until I figure out the best way. I hope to get the bar plot looking good in the next few days, then refactor the rest of the plottables to use a similar style.

we could try to generate the code of these API methods automatically

This may be possible, but I prefer the simplicity of having a few hand-crafted methods. If there were >100 plot types I would feel differently, but there are so few that I think it is easy to maintain them by hand.

I will continue to work on this over the weekend! Thank you @StendProg, as always, for your valuable input.

[swharden]

Hi @StendProg, thank you for your insightful feedback! It has been very helpful discussing these topics with you.

Partial Classes

is typically not advised because if a class requires partial classes it means that class is too large

I think having a lot of API related methods allows this rule to be broken.

I like this conclusion. Typically classes should be small, but since this is the primary user-facing API it can be large. The files appear especially large because every argument is given its own line. I will split the Plot module like you suggest. I will probably name this file PlotAddAPI.cs.

EDIT: I researched this topic and found the recommended naming convention for extension methods is to add a period in the filename then words to describe its purpose. Plot.AddPlottable.cs makes sense here.

However, there is an alternative way to split this class… What if we put partial classes inside the files that define each plottable? The top of PlottableScatter.cs would have a small partial class to extend the Plot module with a method to create a scatter plot. This means adding new customizations to a plottable could be achieved by editing a single file, rather than editing the plottable file and also a large API file in another folder. I could begin implementing this change, one plottable at a time, with no breaking changes. What do you think of this strategy?

EDIT: I experimented with this and I no longer think this is a good idea. It does not separate concerns: files containing plot creation methods with long lists of optional arguments serve a distinctly different purpose than files which define plottable behavior and rendering. I think keeping the partial class out of the files that define plottables is a better idea.

Plot Module Structure

The new method requires exactly 2 times as many lines of code, I think this is a significant drawback.

it is necessary to leave the existing API … since it has already been written.

It is really very attractive to new users (especially those familiar with python as far as I can imagine).

It is wrong to solve developer problems at the expense of the user

These are all excellent points, and your message is very well-received. I will leave the existing methods are they are.

Simplifying Plottable Constructors

I still like the idea of refactoring to simplify the constructors of plottables so that they accept only data, and public properties customize styling and behavior. Changes like this will involve changing code inside methods in the plot module, and are unlikely to affect users (since users typically do not construct plottables themselves). This improvement will reduce complexity of plottables and have no effect on users, so it seems like it has benefits and no disadvantages.