Pencil2d Coding Styles for Non-Implemented Features

Development
1

Hey Folks,
Sorry about going dark, I just been busy with life and tying to find time refactoring the polyline.

I’ve been seeing a huge amount of commits fixing broken stuff which is is nice to see.

So it’s going to be a while till I have something for users to play with the refactored polyline, When I get to that point, for some alpha testing, I’m sure that there will be stuff that will still need to be implemented.

So… that leads me to this post.

When I do development in C#, I generally with throw a non-implemented exception of some feature that needs to be built. Many times this feature isn’t needed yet, so I can leapfrog around building out most of the framework of the application. When the feature is needed, I get an non-implemented exception being thrown so I know it’s not a logic error but something needing to be coded. I see the call stack and fix it. By the time, I’m ready for user testing I have the code sections implemented or handled in the non-implemented exception so it doesn’t crash for the user. This style works fine for applications that are sucking data out of an ERP system but I could see users really getting irked if there app crashes and looses a 1/2 hour or more of work on a non-implemented feature that I missed not handling, I don’t want to inflict that pain on a user if it can be avoided.

In C# another method of handling non implemented features is that instead of throwing an exception is to a Debugger.break() in to stop the application when the IDE is running so you can see the call stack, but it continues to run otherwise. I’ve got to think there is some rough equivalent to that in qt.

Does this project have a preferred style for handling non-implemented features which won’t crash the app for the user but would break for the developer when running debug in the IDE?

@chchwy @feeef et al, I was reading exception handling behavior is not necessary consistent from platform to platform so I’m thinking my coding style for handling non-implemented methods in MS/C# style may not be appropriate for this project.

I’m anticipating/hoping that the re-factored polyline functionality will be slicker than whale doo-doo in an ice-flow, so I like to get it rolled out for alpha testing sooner than later. I think it would benefit the project if we had a standard way of handling non-implemented features. Since Qt/c++ isn’t my primary language, any advice, pearls of wisdom, thoughts for the day… etc… would be appreciated.

2

@jonasthomas Don’t worry about it man, we all have a life as well. Thank you for letting us know that you’re still with us :slight_smile:

I changed the name tags for Matt and François, since they weren’t correct (Matt username is chchwy and François’ is feeef)

I think this is a critically important discussion for all the current and future devs so I’ll sticky it to the forum. Have a nice week guys!

3

@feeef

I’ve been trying to follow the activity in the github posts…(there’s been alot in the last few weeks) In one of your posts, it sounded like you where seeing light at the end of a tunnel for a 0.6 release. When you think we’re there, please let me know and I’ll load it up for my daughter. She was really frustrated by pencil2d back in December. I don’t think she has the patience for alpha testing, but she might get a kick out of being a beta-tester for final testing prior to the “official” release.

4

Sorry for the late reply @jonasthomas, I have bern busy lately. We still need to fix a few bugs for the 0.6 release but we are almost there.

Actually, if you are able to build the app, you could already pull master from the main repository and make a binary for your daughter.

The bugs we still need to fix shouldn’t change much from this current version. The main thing I will be working on before the release is speed. I have setup an old powerbook with debian jessie on it for testing purpose. This machine is from 2003 and if Pencil2D is working fast on it, it should be working fast everywhere else.