And java conventions of long method camel case names are regarded as silly in other languages, descriptive short methods are very possible
user = User.getUserByGuidBecauseImAJavaTwat(gid)
And that makes sense to you? I don't recognize the language, but my guess it's one dot away from creating a user "user=User(guid=gid)". And if guid is a member variable, why are you assigning a value to it? Looks to me like you have some unnamed (...) function, does that imply "find"? Why? Go to your nearest CS school and 9 out of 10 pupils will figure out the purporse on the first function on the first try. You'd be lucky if 2 of 10 managed to guess the second. You're the kind of idiot which means people need 3-6 months of bootup time just to get into the head of the fucker who wrote the code.
I hate writing long variable and function names. I hate reading short variable and function names. And I've been back and forth, but here's my refined opinion: If you can't tell WTF the code is doing at a glance and want to add a micro-comment like "// find user", it's too obtuse. If you're trying to write a whole comment in the name like "getUserThatIsSomethingSomethingForWhateverBeforeThisAfterThat()", call it "getUser()" and write a damn comment. If it's ambigious, it's fine to start small and extend like if you used to have getUser() now you have getUserByGuid() and getUserByName().
As for the get/set prefix, I prefer the simpler user.guid() over user.getGuid() as it's really more a property than a function, you're just abstracting the implementation from the interface. Also you basically don't get any autocomplete before the 4th letter and it's not going to be consistent anyway, for true/false conditions you typically use "isSomething()". In this particularly case for a function I'd much rather call it "findUserByGuid()" though indicating it's a search on a set, not simply returning a value. Likewise if you have a class where you set numbers a and b and calculate the GCD, I'd much rather call the function calculateGcd() than getGcd() to point out that this function does the work. It gets a little ambiguous at times with "returnAddress()" the property vs "returnShipment()" the function where I sometimes reconsider that "getReturnAddress()" would be clearer but in 99% of the cases it's fine.