 |
History
| Log In
|
|
|
|
It does sound like a useful feature but one that could be tricky to implement. Simply performing in-editor on-the-fly reformatting would, for example, break debugging (since line numbers are stored in the compiled class files). Not an insurmountable problem, of course, but probably not a trivial one either.
I don't see how this would effect debugging. essencially, all this is - normalizing checked in code to a single standard. Checked out code can be anything. The only caveat is that when running a diff between check-out and checked-in code, both have to be normalized )to a common format (probably the checked-out format).
I agree with Mark, line numbering could be an issue, the trick would be to not actually add line numbers when doing on-the-fly reformatting but rather. Keeping line numbers consistent is also important when doing code review or sending comments on code to coworkers.
And I agree again with Mark when it comes to debugging. Not all running code is recompiled before running, one example would be core classes or external libraries. When debugging through such files the on-the-fly reformatting will format the source so that it's easy to read (according to your preferences) but line numbers won't change and ruin the debugger. I also think that reformat on check-out / check-in is a bad idea, I rather see that the code is just visually altered in the editor, this would be true when viewing the diff as well and it would actually behave as expected. Reformatting the actual source code is a problem when other developers are using other tools (e.g., Eclipse) to do it, because the results are not identical. It may be harder to implement, but I would rather be able to display a virtual format as suggested here:
http://www.intellij.net/forums/thread.jspa?threadID=270305#5201239 -1
I hate to be the rain bringer to this parade, but ... I think resources could be better spent in other areas. I agree that this is a pain, but it is not an editor problem. There needs to be one entity that sets the code style in your shop. If not, then it is a management problem. If you don't agree with the designated coding conventions, then that is a personal problem. Either way, it is not an IntelliJ problem. It is just the way things are, adjust and move on. Asking the editor to maintain a physical document AND a logical document because developers do not want to adjust to a coding convention is asking a lot. I can imagine the complaints the developers would get (JetBrains and myself) when we are trying to track down exceptions, etc that mention line numbers that do not match up with our own person view of the code. Have you ever heard of the Sun Java Coding Convention (http://java.sun.com/docs/codeconv/ Don't take this personally, it is coming from a person who has fought and won and fought and lost these same arguments. Did you see my comment about NOT altering the line numbering when doing this?
And I do think this could be The Big Thing when it comes to getting more users, this feature would definitely be something not found in other editors. And of course it would be an option to use this or not so you shouldn't worry too much about getting complaints as you would have it turned off any way I'm not saying it would be painless to implement, but neither is code refactoring so my guess is that the team could do it and do it good. Norris, respectfully, couldn't disagree more with you on that.
The reason we keep fighting about some coding preferences is exactly because the tools aren't smart enough yet to shield us from these arguments. A tool, a piece of software should be is there to work for me, not the other way around. I don't want to adjust to the way it works, I want it to adjust to my preferences and idiosyncrasies. If I like my braces on new lines and a guy next to me likes them at the end of a line. I like 3 space indents and the guy next to me like 5 spaces. It is ridiculous to force either one to adjust when the tool can make this issue irrelevant. Equally pointless is wasting management resources setting and enforcing these preferences. Every company has to deal with this any time there is a major change in a team makeup or management. Again, it would be much cheaper to have this resolved once and for all by a tool. As far as Java Coding Conventions go. Some of the conventions sprung from the fact that historically tools could not cater to the individual developer working in a group. Now we are getting to a point where it might be possible. Once this happens, I can see that subset of conventions fading away. Thus, I don't accept the presence of the Conventions as an argument against the need for the tools. >There needs to be one entity that sets the code style in your shop. If not, then it is a management problem.
And what if you are working with a different 'shop', which you have no control over, and who has a very uncomfortable coding convention? For instance, we work alongside customers who use a different coding convention, and who want all code written for them to adhere to it. But simultaneously working on our own code base in the same project using our own standard makes things complicated. I understand where you're coming from Norris, I just think your view is a bit idealistic - the real world is a bit more complex, and it would be great to have our tools help to manage these issues. ps. tracking down exceptions and line numbers not matching up is a problem already faced when using obfuscators, for which there is already a solution implemented. |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
 |
|
New Feature
Open
Major
Different Auto-Code-Reformats with CheckIn and CheckOut
Also something that is not mentioned in the OP is that the visual diff should take into account auto-reformat - when showing a diff, no changes due to autoformat should be shown, and real changes should be adapted for the reformat.