3 ms·
I remember a VS developer once saying that they'd love to include more refactoring functionality; it's just that they want to be very, very sure that it cannot
by ygra 13y ago
I remember a VS developer once saying that they'd love to include more refactoring functionality; it's just that they want to be very, very sure that it cannot ever destroy your code. Eclipse doesn't seem to have that restriction and manages to mangle my code from time to time. Choosing names for automatically-generated members that clash with variables or fields already there (I know you are in rename mode afterwards, but this shouldn't strictly be necessary), or not recognizing the difference between this and SomeClass.this when extracting a method (it puts it in the wrong class).
Perhaps there are people who take working refactorings over those that sometimes need massaging to prevent semantic and syntactic errors.
(That being said, I probably never really used that much of what Eclipse offers in refactoring apart from Extract Method, Rename and Extract Local Variable. And I do understand that refactoring for C++ code is downright hard, if not impossible in the general case.)
- nextw33k 13y agoI find it really short sighted to say the IDE should never destroy code. Yes in an ideal world. However we have VCS to ensure our code is never lost. Before and after any refactoring you should be checking in. If the IDE got it wrong I'd revert and submit a bug report, no biggie. I want my IDE to be stable, fast and do as much for me as possible.
- pmr_ 13y agoI think the problem is refactored code that still compiles but fails in subtle ways now. Of course testing should catch that, but we have to accept that the reality of most testsuites is very different from the ideal.
- flipchart 13y agoI'm constantly refactoring my code. Yes, not all of them are solution-wide changes, but it would be a huge drain on productivity to check in my code between each refactor. I need to be able to trust my IDE that it will refactor properly and not destroy my code
- CraigJPerry 13y agoProbably an impedance mismatch here, i think the parent is thinking in terms of git (or a.n. other DVCS) where constantly making atomic commits is very natural. I suspect from what you're saying you're using something else. E.g. day to day i use subversion. It's possible to adopt this workflow in subversion but it definitely takes more effort on my part.
- SolarNet 13y agoI think that's a problem of still using text and the filesystem as our codebase storage format. Databases have transactions, query languages, backup capabilities, and a number of other extraneous features which can be removed or replaced with generally simpler versions (clustering with version control for example). If code is data, why arn't our codebases databases?
- btown 13y agoOf course, the flippant answer to this is that our codebases are already databases - the filesystem is our storage engine, commits are our transactions, etc. But is this the optimal way to store information? It would be very interesting to look at code as a graph database (of the https://github.com/tinkerpop/blueprints/wiki https://github.com/tinkerpop/blueprints/wiki family, for instance). In a way, one could see how a functional programming language defines entities and their relationships, and how a function is just a composition of other functions to which it could be linked. But do we want to write a graph operation every time we want to make an edit or add a feature to our code? Perhaps the textual codebases we have are the most easily editable visualization of the underlying "graph."
- SolarNet 13y agoIf the database is the model, then add a controller (IDE) and view (textual representation) and you may start to see how that could work. Also I should have said, "why aren’t are codebases like modern databases".