Author Topic: Some (wild) feature requests  (Read 7532 times)

mike_pentney

  • Community Member
  • Posts: 8
  • Hero Points: 0
Some (wild) feature requests
« on: August 01, 2006, 04:46:50 PM »
I've been musing lately on IDEs and editors, and it seems to me that none really offer any facilities which actually help to design code; they all pretty much focus on helping programmers write stuff which they have designed elsewhere (on a whiteboard, in their heads, on post-it notes, whatever).

Wouldn't it be cool to create an editor that helps with the design as well?

Some features I can think of straight away are:
  • create function stubs from the (public and private) interface to a class
  • add the set of classes comprising a design pattern to a project
  • add unit test boilerplate to a class or function
  • add function stubs for overrides when deriving a new class
  • features to help design loops (using loop invariants), if statements (using truth tables) etc.

Even these suggestions don't really attack the design issue, but I don't know of any IDE or editor which implements them. Of course, this may be because I'm the only person on the planet who thinks this would be useful.

I'm sure others can think of many better features. Of course, almost all will be language and paradigm specific (I mainly work, think and dream in C++). But perhaps the SlickEdit team would be willing to look into this a bit (after all, the refactoring support is targeted mainly at C++).

I guess some of these things could be implemented using Slick-C, but I haven't really looked into it's capabilities yet. To be really useful you'd probably need to be able to parse existing code (e.g. the declaration of a C++ base class) and I don't think this capability exists in Slick-C (or any other IDE's scripting language).

Any comments?

jeffcobb

  • Community Member
  • Posts: 23
  • Hero Points: 1
Re: Some (wild) feature requests
« Reply #1 on: August 01, 2006, 08:48:06 PM »
I agree with much of what you say or more to the point, I disagree with none of it but wish to give added emphasis to the CASE-oriented aspects of your post.  Currently I get most of what you want by combining slickedit with a linux tool called Ubrello; essentially a UML tool that has CASE (code import/export) capabilties. The downside of this is that like most CASE tools I have worked with, they are great at the OO aspects and fall down hard on the editor front. The dream you are suggesting of course is the merging of a CASE tool with SlickEdit and in that regard, I wonder if they would be able to give away so much functionality for free. From another perspective though, the free alternatives are quickly closing the window on the kinds of things that SlickEdit can use to differentiate and justify the cost so we will have to see.

Whilst we are wishing for stuff of a CASE nature, I would like to see it have tight integration with the language default container classes and libraries. This is admittedly a C++-centric request although I understand something like the STL exists for Java and other languages already have the basics built in (Perl, python et al). Anyhow, this would allow you to visually model logic and data flow/storage with proper tools and data types generated automatically. If I didn't find the graphical end of coding this so boring, I would do it myself.

Dennis

  • Senior Community Member
  • Posts: 3992
  • Hero Points: 520
Re: Some (wild) feature requests
« Reply #2 on: August 01, 2006, 09:42:44 PM »
Some (coding oriented) suggestions:

1) "create function stubs..."   There is a command "implement-protos <classname>"
    that does this.  It is not exposed on the GUI, because it is a little rough.

2) "add the set of classes..."   Check out the template manager in 11.0.

3) "unit test..."   ditto

4) "add function stubs...deriving..."  When you type the class definition:

        class XXX: public AbstractBaseClass {

    As soon as you type "{", you should be prompted for what functions
    you want to override, with the abstract functions selected by default.
    Combine this with "implement-protos" you can whip out classes pretty fast.

5) "features to help design loops..."   You might want to define aliases
    for the different idiomatic loops and truth table constructs you like to use.

mike_pentney

  • Community Member
  • Posts: 8
  • Hero Points: 0
Re: Some (wild) feature requests
« Reply #3 on: August 01, 2006, 10:02:59 PM »
Gosh! Thanks, Dennis. Perhaps I should really RTFM...

But as I said in my post, these are still mainly editing features. Any thoughts on adding more CASE functions?