Code folders decomposition

[misova]

Currently, there only 2 places (folder Indicators or Strategy),
where can put common code for working with dates, files, utilities...

There is always a problem, where to put the some general routines,
that are not related to any strategy nor indicator.

When I am implementing some utility class for working with dates,
do I have to put inti Indicator folder or into Strategy folder?

The folder structure should be decomposed better and include
something like Shared folder, where we can put all the codes,
that are not logically linked with any Strategy or Indicator.

[koganam]

Currently, there only 2 places (folder Indicators or Strategy),
where can put common code for working with dates, files, utilities...

There is always a problem, where to put the some general routines,
that are not related to any strategy nor indicator.

When I am implementing some utility class for working with dates,
do I have to put inti Indicator folder or into Strategy folder?

The folder structure should be decomposed better and include
something like Shared folder, where we can put all the codes,
that are not logically linked with any Strategy or Indicator.

Place it in Indicators and make it static. That way, you do need an object instance before you can access the construct.

[NinjaTrader_PatrickH]

Hello misova,

Thank you for your post.

The next major release will improve upon several aspects of NinjaScript. You can view the enhanced features list at the following link: http://www.ninjatrader.com/downloads...njaTrader8.pdf

Please let me know if you have any questions.

[misova]

I have read all improvement in the PDF quickly,
but could not find any concrete improvement related
to the structure of the codebase.

Am I missing something in the PDF file?

Hello misova,

Thank you for your post.

The next major release will improve upon several aspects of NinjaScript. You can view the enhanced features list at the following link: http://www.ninjatrader.com/downloads...njaTrader8.pdf

Please let me know if you have any questions.

[misova]

Place it in Indicators and make it static. That way, you do need an object instance before you can access the construct.

Thankx,

Currently I am doing it the same way as you suggested and it works.
It is easy to handle this issue with workaround - I just don't like it, because it is so ugly
to put things into the Indicator folder and use it in context of strategies and vice-versa.

When the logical structure is missing, it is very unprofessional and also harder to maintain.
Systematic solution is easy, so let's improve in the future.

[koganam]

Thankx,

Currently I am doing it the same way as you suggested and it works.
It is easy to handle this issue with workaround - I just don't like it, because it is so ugly
to put things into the Indicator folder and use it in context of strategies and vice-versa.

When the logical structure is missing, it is very unprofessional and also harder to maintain.
Systematic solution is easy, so let's improve in the future.

Not really. Indicators are the primary user class, and can be contained and referenced by strategies. Whereas indicators are not exactly a subclass, strategies and indicators cannot reference strategies, so holding most things that have to do with both classes in the indicators folder is kind of logical.

That having been said, I agree with you that a "common" folder is much neater.