I agree there is always some exceptions. I did a search in my workspace “public interface” and I got ~200 matches. When I look at some project, most when not
all definition of the Interface start with an “I..”. Some projects like
Mylyn.task.core, mylyn.reviews.ui follows the convention, but when I look at mylyn.gerrit.core or mylyn.reviews.example.emf…, only one interface start with
an “I” and all the others don’t. May be it should be the opposite , only a subset might not follow the coding convention, not the majority
J Unless the standard is to not put the “I” at the beginning!
As the main project (Mylyn), it would be nice to follow its own coding standards
J and show the good way
From: mylyn-reviews-dev-bounces@xxxxxxxxxxx [mailto:mylyn-reviews-dev-bounces@xxxxxxxxxxx]
On Behalf Of Miles Parker
Sent: June-11-14 1:39 PM
To: Mylyn Reviews Project
Subject: Re: [mylyn-reviews-dev] Coding guidelines for Mylyn
There are always exceptions, of course. ;) (In general, Eclipse tends to be pretty interface averse, for reasons of API extensibility.)
On code conventions in general, it’s probably impossible to have a complete list of all conventions beyond the clear ones like naming conventions and so on. So I think some of these will always be defined and enforced culturally; that is
through the reviews process itself.
--
Miles Parker
Senior Software Engineer, Tasktop
Committer, Eclipse Mylyn, Virgo
http://tasktop.com
skype: milestravisparker
|