Displaying 3 results from an estimated 3 matches for "getthingy".
2019 Feb 13
3
changing variable naming rules in LLVM codebase
...eally, objecting on the grounds that a given style is already used for
> function names is really a very weak argument. IME function names are
> *incredibly* *hard* to confuse with anything else, because they *always*
> have
> surrounding syntactic context. Given `TheStuff->fooBar().getThingy()` is it
> even conceivable that you might not instantly get that fooBar and getThingy
> are methods? Therefore, using the same convention for some other kind of
> name is Not Confusing.
>
> OTOH, `TheStuff` comes out of nowhere with no clues to its origin, and
> *that*
> is a...
2019 Feb 13
4
changing variable naming rules in LLVM codebase
FWIW, I'm pretty strongly opposed to humbleCamelCase. We already use that
style so something else. One of the biggest advantages of changing the
variable naming convention would be to differentiate variables from other
constructs IMO, and that's the nature of many examples here.
Using underscore_names for variables as Zach suggests would,, onhe other
hand, be a significant improvement
2019 Feb 14
5
changing variable naming rules in LLVM codebase
...style is already used
>>> for
>>> function names is really a very weak argument. IME function names are
>>> *incredibly* *hard* to confuse with anything else, because they *always*
>>> have
>>> surrounding syntactic context. Given `TheStuff->fooBar().getThingy()` is
>>> it
>>> even conceivable that you might not instantly get that fooBar and
>>> getThingy
>>> are methods? Therefore, using the same convention for some other kind of
>>> name is Not Confusing.
>>>
>>> OTOH, `TheStuff` comes out...