Re^3: Speeding up RecDesent parser for Perl Code

Replies are listed 'Best First'.
Re^4: Speeding up RecDesent parser for Perl Code by Outaspace (Scribe) on Sep 07, 2006 at 16:55 UTC
Refactored it 2 times until now. But it is the main modul of an GUI-IDE with 2 years of work behind it and has about 130 subs (not to mention the anonymus ones). Futher refactoring would be serious work, that I have currently no time for. Andre	[reply]
Re^5: Speeding up RecDesent parser for Perl Code by merlyn (Sage) on Sep 07, 2006 at 21:15 UTC
How many tests do you have for those 130 subroutines? What's your code coverage look like? -- Randal L. Schwartz, Perl hacker Be sure to read my standard disclaimer if this is a reply.	[reply]
Re^6: Speeding up RecDesent parser for Perl Code by Outaspace (Scribe) on Sep 07, 2006 at 22:31 UTC
None and dont know the code coverage either. I think the perl modul tests cant be quite transfered to GUI programs, because most of those functions are callbacks from button and other controls and their behaviour depends on the current situation in the application and in some cases I can't test because I simply cant generate the neccesary case without actually pressing a mouse button (for example). Theire are even cases where the user can enter a Perl Regular Expression (or a sort function) that have to be evaled carefully. I know myself that the testing is a necesary process, but I think that automated testing mechanism create a false confidence, cause you never know what the user is going to to. Andre	[reply]
Re^7: Speeding up RecDesent parser for Perl Code by merlyn (Sage) on Sep 07, 2006 at 22:53 UTC
Re^8: Speeding up RecDesent parser for Perl Code by Outaspace (Scribe) on Sep 07, 2006 at 23:30 UTC
Some notes below your chosen depth have not been shown here
Re^5: Speeding up RecDesent parser for Perl Code by aufflick (Deacon) on Sep 11, 2006 at 01:41 UTC
Not to deprecate merlyn's excellent advice, but if you purely want to reduce the number of lines in the module to make it a bit easier to deal with, why not just cut the file into 5 or so separate files and include them all in the one master file. Hardly the "good design", but it might be a way to start. You could make the separate files contain conceptually separate code (even though to the compiler there would be no difference). These files could then be the basis for some real refactoring later.	[reply]