| Coding style of Graphiti plug-ins [message #723326] |
Thu, 08 September 2011 10:52  |
 Velganesh Subramanian
Messages: 69
Registered: July 2009 |
Member |
|
|
I have been working on RCP for a while - most of work involved around SWT and JFace and I just moved to graphical editing. I started exploring Graphiti as the screenshots and the documentation impressed me a lot.
As any other developer, I create debug points within org.eclipse.jface and few other platform plug-ins. I love platform code and I am gradually changing my coding style to be same as Eclipse's. But I was very disturbed when I looked at Graphiti code and am posting this to ask if the style is intentional.
- Javadoc - Most classes and interfaces have "The Class <class name>" and "The Interface <interface name>" as the only documentation. Though the names convey some meaning, it is not easy to know more about it.
- Variable names - abbreviations and abbreviations. Few examples - dtp for DefaultFeatureProvider, pe for PictogramElement, pes for a collection of PictogramElement, fp for IFeatureProvider, ret for any type of object to be returned from a method, T as the name of a class (actually meant for tracing), etc.
- Sentence-like method names - getAllBusinessObjectsForPictogramElement, getBusinessObjectForPictogramElement
- Forward tracing - log statements upon entry and exit of methods
- Debug flags - uses system property instead of debug flags in .options file. PDE UI has a good pattern for logging exceptions and can be followed here.
- Use of @noimplement and @noextend even for internal classes.
Is the code bad just because Graphiti is in incubation? It would be of great service to Eclipse community if code sanity is maintained.
|
|
|
| Re: Coding style of Graphiti plug-ins [message #723345 is a reply to message #723326] |
Thu, 08 September 2011 11:33  |
Michael Wenz
Messages: 1931
Registered: July 2009
Location: Walldorf, Germany |
Senior Member |
|
|
JavaDoc is surely something we need to improve, but at least APIs are widely
documented. As we are working on the code we always try to improve the
coding and the documentation along. Just let us know if you stumble over any
pressing issues and we will address them.
Michael
"Velganesh Subramanian" schrieb im Newsbeitrag
news:j4a64u$gkm$1@news.eclipse.org...
I have been working on RCP for a while - most of work involved around SWT
and JFace and I just moved to graphical editing. I started exploring
Graphiti as the screenshots and the documentation impressed me a lot.
As any other developer, I create debug points within org.eclipse.jface and
few other platform plug-ins. I love platform code and I am gradually
changing my coding style to be same as Eclipse's. But I was very disturbed
when I looked at Graphiti code and am posting this to ask if the style is
intentional.
Javadoc - Most classes and interfaces have "The Class <class name>" and "The
Interface <interface name>" as the only documentation. Though the names
convey some meaning, it is not easy to know more about it.
Variable names - abbreviations and abbreviations. Few examples - dtp for
DefaultFeatureProvider, pe for PictogramElement, pes for a collection of
PictogramElement, fp for IFeatureProvider, ret for any type of object to be
returned from a method, T as the name of a class (actually meant for
tracing), etc.
Sentence-like method names - getAllBusinessObjectsForPictogramElement,
getBusinessObjectForPictogramElement
Forward tracing - log statements upon entry and exit of methods
Debug flags - uses system property instead of debug flags in .options file.
PDE UI has a good pattern for logging exceptions and can be followed here.
Use of @noimplement and @noextend even for internal classes.
Is the code bad just because Graphiti is in incubation? It would be of great
service to Eclipse community if code sanity is maintained.
|
|
|
|
Powered by
FUDForum. Page generated in 0.03262 seconds
] 
Search
Help
Register
Login
Home
