I have an interesting set of refactoring ideas based on the following style philosophy.
I always try to reduce the scope and accessibility of code to the maximum extent possible, i.e. that the compiler with allow. In other words, if a variable or method can be made private without compile errors, then I make it private. If I can make a method static without compile errors, then I make it static. If I can declare variables inside an inner statement block rather than in the outer block without compile errors, then I move the variables for greater encapsulation. I have read several authors who prefer a style approach where methods are declared protected by default for convenience. However, I think this impedes self-documenting code. A method declared as private provides the reader with more information about how the method is used. You can see that a private method is not used by other classes. Whereas a method marked as protected but not used outside the class, is ambiguous and provides less information about its actual usage. This same principle can be applied to other scopes and accessibility modifiers. If you follow a policy of of restricting scope and accessibillity to the maximum extent possible, the reader will be able to interpret code with less ambiguity. I recommend a general refactoring feature that scans whole packages for opportunities to narrow scope and accessibility to the maximum extent possible. Then, while the user is writing client code, the IDE can provide a feature for doing things like accessing a private method and automatically upgrading the accessibility to the mininum necessary to allow access. For example, if you are trying to access a private method in a class from a another class in the same package, the IDE could prompt to change accessibility to default rather than public. This way, accessibility modifiers stay exactly in synch with actual usage, which increases readability and lowers ambiguity. The same techniques can be applied to scope. This kind of thing sort of transcends into auditing capabilities. It would be interesting to explore more features where the IDE looks for and suggests refactorings based on a set of audit rules. Unlike other auditing tools, it would be better if the IDE made suggestions while you type rather than after the fact. Some rules could be very simple. For example, if a method is too long or complicated, the tool could suggest that the method get broken down into smaller methods. Thanks, Juan Osuna _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com _______________________________________________ Eap-features mailing list [EMAIL PROTECTED] http://www.intellij.com/mailman/listinfo/eap-features
