Any pointers to approach being taken by this project? I think following XP (as far as UTs) goes is a good approach. Unfortunately might not be able to use pair programming :(
Thanks and Regards
KD
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I'm not sure a complete XP approach is viable for an opensource project. As you say pair programming is a bit problematic, along with onsite customer, etc.
Having said that, I'd like to keep some of the core practices like keeping it simple, you arent going to need it, unit tests, acceptance tests, frequent integrations, short iterations [in terms of small doses of functionality, not short time periods like three weeks. I suspect this isnt possible in opensource when everyone has a day job as well, not to mention other interests].
At the moment we're experimenting a bit with parsing, and some of the initial application structure. In this sense we're not completely following XP. If we were, we wouldnt be doing any up-front design, but I think that since we [particularly myself] dont have a lot of experience with parsers its not such a bad thing. I'm not considering it BDUF, just SDUF.
The other thing is that this is my first opensource project. I've worked in software teams for eighteen years, software development is nothing new. Even so, I'm learning something new, and it feels like it.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Anonymous
-
2002-07-02
I wouldn't say XP was the ultimate and heavenly for an Open Source project either.
Have you read the advice of Don Roberts and John Brant [Fowler: Refactoring - Improving the design of existing code]? Probably you have but just in case you've been living in a barrel, the chapter has it in a nutshell. How far along are you with your parsing experimentation anyway?
-c'ya, hostia-
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Sometime back I am toying around with this idea. The points I can recall during that time are the following:
1. We surely need a sort of parser for use with refactoring. I think we need to create a abstract syntax tree like structure.
2. It is easier to implement the refactoring in two parts. A non-terminal reference database and a refactoring tool that uses the database to perform actual refactoring.
3. Start with small refactorings (like rename variable/function etc.) and move upwards.
4. Construct the database structure based on the requirement for the refactoring currently under consideration.
5. Build part of the parser that can create the database that is required for the current set of refactorings.
6. Repeat the above steps.
Hope this helps.
Thanks and Regards
KD
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Thanks for asking. I would love to be a developer. Unfortunately, I can't spend too much time on this project - However I should be able to spend around 3-6 hours/week. Call them ideal hours.
Thanks and Regards
KD
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Refactoring goes beyond XP: it's something you do it almost every day to greater or lesser extent.
I'd love to have something for C++ like the Refactoring Browser: in an open developing environment tasks such as sniffing code IS a real pain even if you use a half-decent IDE like CodeWarrior, KDeveloper or similar - I have devised many clever strategies to track usage of member variables, to plot interface dependencies, etc. but they are tedious and not for the impatient programmer kind...
PS: I would be interested in helping you in whatever could be on my hands.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The most promising avenue of investigation I have found is the Tree structure that gcc produces.
It is possible ( if you correctly configure gcc at install time ) to get it to print the tree structure out. Moreover the documentation for the structure it is pretty good.
Currently, I'm writing a program to parse the output of the tree dump are recreate the tree. I hit an inconsistency, that makes me want to start coding in the gcc sources - but this limits you to C.
So instead, i'll continue the parsing and see if the resultant tree makes any sense compared to the code I put in.
This would mean we could deal with any code that gcc could deal with. gcc is a pretty good compiler - second only perhaps to the front end by the edison design group.
Just to let you know what i'm up to.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
sorry for the delay. The project is picking up speed again (still no code, but this will change soon). Check out the Developers' forum, and the Wiki referenced there.
Sven.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Any pointers to approach being taken by this project? I think following XP (as far as UTs) goes is a good approach. Unfortunately might not be able to use pair programming :(
Thanks and Regards
KD
I'm not sure a complete XP approach is viable for an opensource project. As you say pair programming is a bit problematic, along with onsite customer, etc.
Having said that, I'd like to keep some of the core practices like keeping it simple, you arent going to need it, unit tests, acceptance tests, frequent integrations, short iterations [in terms of small doses of functionality, not short time periods like three weeks. I suspect this isnt possible in opensource when everyone has a day job as well, not to mention other interests].
At the moment we're experimenting a bit with parsing, and some of the initial application structure. In this sense we're not completely following XP. If we were, we wouldnt be doing any up-front design, but I think that since we [particularly myself] dont have a lot of experience with parsers its not such a bad thing. I'm not considering it BDUF, just SDUF.
The other thing is that this is my first opensource project. I've worked in software teams for eighteen years, software development is nothing new. Even so, I'm learning something new, and it feels like it.
I wouldn't say XP was the ultimate and heavenly for an Open Source project either.
Have you read the advice of Don Roberts and John Brant [Fowler: Refactoring - Improving the design of existing code]? Probably you have but just in case you've been living in a barrel, the chapter has it in a nutshell. How far along are you with your parsing experimentation anyway?
-c'ya, hostia-
Here are my two cents for whatever it is worth.
Sometime back I am toying around with this idea. The points I can recall during that time are the following:
1. We surely need a sort of parser for use with refactoring. I think we need to create a abstract syntax tree like structure.
2. It is easier to implement the refactoring in two parts. A non-terminal reference database and a refactoring tool that uses the database to perform actual refactoring.
3. Start with small refactorings (like rename variable/function etc.) and move upwards.
4. Construct the database structure based on the requirement for the refactoring currently under consideration.
5. Build part of the parser that can create the database that is required for the current set of refactorings.
6. Repeat the above steps.
Hope this helps.
Thanks and Regards
KD
Much of what you've mentioned we've discussed on the developers forum.
Are you interested in being a developer?
Thanks for asking. I would love to be a developer. Unfortunately, I can't spend too much time on this project - However I should be able to spend around 3-6 hours/week. Call them ideal hours.
Thanks and Regards
KD
Refactoring goes beyond XP: it's something you do it almost every day to greater or lesser extent.
I'd love to have something for C++ like the Refactoring Browser: in an open developing environment tasks such as sniffing code IS a real pain even if you use a half-decent IDE like CodeWarrior, KDeveloper or similar - I have devised many clever strategies to track usage of member variables, to plot interface dependencies, etc. but they are tedious and not for the impatient programmer kind...
PS: I would be interested in helping you in whatever could be on my hands.
The most promising avenue of investigation I have found is the Tree structure that gcc produces.
It is possible ( if you correctly configure gcc at install time ) to get it to print the tree structure out. Moreover the documentation for the structure it is pretty good.
Currently, I'm writing a program to parse the output of the tree dump are recreate the tree. I hit an inconsistency, that makes me want to start coding in the gcc sources - but this limits you to C.
So instead, i'll continue the parsing and see if the resultant tree makes any sense compared to the code I put in.
This would mean we could deal with any code that gcc could deal with. gcc is a pretty good compiler - second only perhaps to the front end by the edison design group.
Just to let you know what i'm up to.
Can anyone give me an update on this project please?
Thanks
Mike
Mike,
sorry for the delay. The project is picking up speed again (still no code, but this will change soon). Check out the Developers' forum, and the Wiki referenced there.
Sven.
see the cpptool 'LIST' entries for development discussion.