Would you call me a psychopath for doing this?

No, because you avoid the absolutely dumb "this" garbage.

Why though?

Edit:
@kescherRant its not dumb and imo it benefits a lot to code readabillity. Would discard this on code review right away.

Just cause you can do something doesn't mean you should.

@myss some devs are way sensitive about using _ with all the private properties. But I hate seeing those "_"s spread across the whole class file with no valid reason.

If it's in line with the code style convention you have, then it's fine.

Follow whatever the convention is.

I prefer this.whatever, because most ides autogenerate all that code.

Maybe a little.

But get rid of that I pattern for IInterfaces. It's super annoying

@netikras emm, but how would you make your code readable enough to identify you are using an Interface or an abstract class across an inheritance chain for example?

@dnsProbe why do you need to identify them? Why do you even care? IoC should hide implementation/abstraction distinction anyway.

If anything the I [anti]pattern makes code less readable by polluting text with unnecessary info

@dnsProbe abstractions are generic: UserService, PaymentRepository, OrderService.

Implementations are speciffic. LoggedInUserService, AnonymousUserService, InvoiceAwarePaymentService. There's no need to explicitly say "I am using an interface here". It should be the default w/o needing to mention it. IoC engine should autowire the beat suited implementation and you'd be workibg with UserService, w/o needing to know what type it is

@netikras I don't agree as interfaces are way different than classes/structs and it should be clear that you are using whichever for code readability.

Just my two cents.

@netikras I totally get the point you are making its IoC's headache to spinup and provide the instances as and when required but consider a usecase for a domain that fairly utilizes interfaces, abstract classes and base classes, then you may need some convention to paint a clear picture to make it easy for new members joining your team to navigates through the codebase. I am just talking from a readability standpoint.

@dnsProbe I'm still trying to think of a use case where you'd explicitly need to know whether you're working with an interface..😁

@twped Hm.

I like this. In larger classes / functions it can solve a lot of headache because you immediately know wether it's internal or external. And when it's internal, it's lifetime/scope is not limited to eg the function... So it's a very useful indicator.

Now, looking at the rest of the code...

Well. What does an interface called IReportService do?

I don't have a fucking clue. But based on it's name I have a very bad feeling.

Don't name an interface after a class instance.

An interface is a contract which all classes who implement it, must fulfill. It's generic, never specific to one class only.

So no to I<className>.

Delete this heresy.

@IntrusionCM first of all an interface does not do anything at all. As you say it's a contract. It is describing something.

And I didnt say you should name it after it's implementation class. That would be silly.

I suggest you name it after the contract it is supposed to describe. And I am the opinion that prefixing it with an "I" it helps the reader to immediately see that it is an interface.

Nothing else.

@netikras
Most of the arguments for using the IAmANonInstantiableGenericism naming strategy are centered around readability.

List being the most generic abstraction for ArrayList isn't immediately obvious without knowledge of the List suffix = Impl convention.

IEnumerable, IList, IReadOnlyList, ICollection, etc immediate tells the reader that a generic something is being used to provide a binding for something else.

It allies with the camp of "Don't write interfaces when there are no specializations."

Personally, I don't give a shit 😋

@netikras it's standard c# to do IInterface. Whether or not it makes sense is of little concern (I don't really like it either); the point is that language conventions should be followed so that someone else doesn't have to deal with your cowboy code style.

_privateMemberName and parameterName

not privateMemberName and _parameterName

@nebula could be worse though... Could be m_...

just curious why hexagon instead of a circle?

In Typescript you can declare member fields in the constructor.

public ReportService (
private readonly gateway: IReportGateway,
private readonly options: ReportClientOptions)
{ }

I am not certain your code is TS though... syntax matches, editor matches and colors do match as well :)

@dder thts c# you looking at

Following c# guidelines you should not name method arguments starting with _

listen man

have you SEEN some of the garbage Python out there?