Getter naming

[trask]

Sometimes we use getAbc() and sometimes abc().

I believe the core repo went with getAbc() everywhere(?).

Can we come up with explanation of when to use one vs the other?

E.g. here's one class where we use both (which may be ok, but I'd like to be able to write down the reason)

opentelemetry-java-instrumentation/instrumentation-api-semconv/src/main/java/io/opentelemetry/instrumentation/api/instrumenter/net/InetSocketAddressNetClientAttributesGetter.java

Lines 23 to 28 in 6d22758

	@Nullable
	public abstract InetSocketAddress getAddress(REQUEST request, @Nullable RESPONSE response);
	@Override
	@Nullable
	public final String peerName(REQUEST request, @Nullable RESPONSE response) {

[mateuszrzeszutek]

Sometimes we use getAbc() and sometimes abc().

I believe the core repo went with getAbc() everywhere(?).

Can we come up with explanation of when to use one vs the other?

I think we might have done that somewhat by accident, I don't think it was a conscious decision to use the abc() format.
We should go with getAbc(), since that's what we use in both SDK and instrumentation-api.

[trask]

Just a note: one place where we don't use get (and core repo doesn't use get either) is builder() methods (and their friends like spanBuilder(), tracerBuilder(), etc

[trask]

More notes:

Static methods on interfaces:

• IdGenerator.random()
• SpanProcessor.composite(...)
• SpanContext.getInvalid()
• SpanId.getInvalid()

I'd say that maybe random() should have been getRandom() (or getDefault()), but composite(...) makes sense (it's more like a builder), and we follow similar with AttributesExtractor.constant(...)

[mateuszrzeszutek]

I think we usually use <noun>() in static factory methods -- I think it's fine, it reads in a more "declarative" way