cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "A. Rothman" <>
Subject DOSGI - Naming conventions
Date Thu, 20 Jun 2013 23:27:23 GMT

In my recent review of the DOSGi codebase, one thing that stood out and 
made the code harder to follow, or at least more annoying, was 
inconsistent variable naming - even for the same types, used with the 
same meaning, within the same class. I'd like to propose to standardize 
on some naming convention so that the code will be more coherent and 
predictable and thus easier to maintain.

I'm not referring to names with added value or meaning in a particular 
context, which have their place, but just the interchangeable and 
generic type names which are by far the majority.

I'm also not advocating any particularly choice of names - any will do, 
as long as they are used consistently.

Here are some quick examples, with the number of occurrences of the most 
common names per type (the stats are not perfect [1], but make the point):

      22 endpoint
      18 ed
      17 epd
      10 sd
       6 ep
       3 endpointDescription

      68 sref
      19 reference
      13 sr
      13 serviceReference

      97 bc
      27 callingContext
      24 context
      24 bctx
      22 bundleContext
      21 dswContext
      10 dswBC
      10 ctx
       7 requestingContext
       2 bundlecontext
       2 bcontext

       9 sreg
       5 sr
       3 serviceRegistration
       3 registration
       2 reg

      16 zk
       5 zooKeeper
       3 zookeeper

And there are also meaning-specific names, such as Dictionaries used for 
services properties, which are named: props, p, m, config, serviceProps, 
svrProps, etc.

These are just a few types that came to mind, but the inconsistency is 
pretty consistent :-)

Some suggested conventions:

- use the currently most common names: endpoint, sref, bc, sreg, zk, 
props, etc.
- use initials: ed, sr, bc, sr, zk, etc.
- use simple words: endpoint, reference, context, registration, 
zookeeper, props, etc.
- use any combination that seems pleasant to read, e.g.: endpoint, sref, 
context, sreg, zookeeper, props, etc. (this or the previous option would 
be my pick)

Or, we can leave things as they are.

I can do the refactoring if it is agreed to do so.

So how about it?


Here's the quick-and-dirty command I used for the stats:
find -name "*.java" | xargs sed -rn -e 
s/.*EndpointDescription(<.*>)?\s+(\w+)[^a-zA-Z_(].*/\2/p' | sort | uniq 
-c | sort -nr

View raw message