> If you have properties with ridiculous names, that's a bigger problem.

I have no control over third-party dependencies and how they name things.

I tend to solve that by wrapping inane APIs. At most I deal with ridiculous names and other API-brokenness once.

> I tend to solve that by wrapping inane APIs.

That is just another layer of abstraction which leads to even more confusion.

These abstractions can be taken to the extreme in things like Java, that's how you end up with a class named "InternalFrameInternalFrameTitlePaneInternalFrameTitlePaneMaximizeButtonWindowNotFocusedState".

If you wrap that in a new interface "IFIFTPIFTPMBWNFS" or even "crazyFrameStuff" (ridiculous enough), now you have to figure out what that actually is while debugging.

If one just comes to terms with the fact that Intellisense (and showing the method signatures while implementing) is extremely helpful even to very senior developers, life can be much easier.

It's not cheating.

No, I end up with classes like that because when I wrap APIs the point is to simplify, so I simplify. Though that is a last effort if ditching the broken API entirely isn't an option - e.g. if it's a third party API we can't avoid. That is rare to begin with.

You're free to find Intellisense etc. useful. I just don't. I go to great lengths to have an uncluttered view of the code when I work, because I find it far more preferable to focus on just the code. I'm not against it in principle - I've just not seen any solutions like that which works for me. I don't tend to need to look up methods much; when I work on a piece of code I tend to hold the APIs in memory pretty effortlessly, so that's just not much of a consideration.

I spent years actually looking at implementing visual languages because I liked the idea of providing more contextual information and views of information flows etc. to aid development, but I've yet to find something that works better for me than an uncluttered view of the text.