[Jim C]

Good morning,

I've been using your State Machine since you unleashed it on the world and have happily noticed a great improvement in my coding efficiency, as well as readability/maintainability/scalability. But, as I've been writing larger programs, I find myself with many, many states (including one for each paragraph in the test specification document).

Is there a problem (style or otherwise) with having many states, apart from the inconvenience of having to scroll down a long list? Is there anything you folks do to address this?

Thanks,
Jim

[Omar Mussa]

Jim C, on Jun 16 2009, 11:11 AM, said:

Is there a problem (style or otherwise) with having many states, apart from the inconvenience of having to scroll down a long list? Is there anything you folks do to address this?

There isn't a real problem associated with having too many states. Right now, we don't have any tools to address having a lot of states, but we do find that there are a couple of tricks to making it easier to manage.

• If you have a lot of states, you may want to look at your design and see if you really should be using multiple state machines.
  
• Try to keep your states organized -- don't allow yourself to add states haphazardly to the case structure, make sure they are well grouped.
  
• Some people at JKI have used alphabetic naming schemes to make it easier to sort their states, but we haven't really adopted that as a standard -- I'm just throwing this out there.

[Jim C]

I'll think about how I can redesign things in the next project! This one isn't unwieldy, it just takes a while to scroll between states. Perhaps I just need a scroll bar on the state selection list!

Thanks for answering.

[Omar Mussa]

Jim C, on Jun 18 2009, 11:14 AM, said:

This one isn't unwieldy, it just takes a while to scroll between states. Perhaps I just need a scroll bar on the state selection list!

One other thing I've done recently in state machines with a lot of states is to avoid using the drop down for the state selection -- granted this only works in some situations... If you are working on a group of states that are related to each other you can use the 'next'/'previous' state arrow buttons rather than the state selection list. Its actually faster than trying to 'find' your current state and then find the nearby state that you want to navigate to. I find that occasionally this is helpful.

Good luck - I'm glad you've been able to use the JKI State Machine with success!

[Jim C]

Omar Mussa, on Jun 18 2009, 12:28 PM, said:

One other thing I've done recently in state machines with a lot of states is to avoid using the drop down for the state selection -- granted this only works in some situations... If you are working on a group of states that are related to each other you can use the 'next'/'previous' state arrow buttons rather than the state selection list. Its actually faster than trying to 'find' your current state and then find the nearby state that you want to navigate to. I find that occasionally this is helpful.

Good luck - I'm glad you've been able to use the JKI State Machine with success!

Another tip is to hold the control key and spin the mouse wheel.

As far as success with the JKI State Machine, it's fast becoming the standard here. Three of us use it (although one guy has ruined it) and I'm teaching other developers to start using it. You guys are the best.

[crelf]

Omar Mussa, on Jun 17 2009, 08:28 PM, said:

• Some people at JKI have used alphabetic naming schemes to make it easier to sort their states, but we haven't really adopted that as a standard -- I'm just throwing this out there.

I often use a delimted grouped string for stuff like this. Depending on your tastes, you can use a forward or reverse organizations. Say you had a group of states that turned a LED on, off, different colors, read it's state, etc:

LED.Set.Green
LED.Set.Red
LED.Set.Orange
LED.Set.Off
LED.Get.State

[Jim C]

Just in case anybody has the same problem I had and finds this post. There's a tool to solve this problem here.