Displaying 7 results from an estimated 7 matches for "isfoo".
2018 May 24
3
Style: getFoo() vs foo()
The coding guidelines say:
> Function names should be verb phrases (as they represent actions), and
command-like function should be imperative. The name should be camel case,
and start with a lower case letter (e.g. openFile() or isFoo()).
This means that functions that just compute or access a value (no
side-effects) should be named e.g. `getParent()`, rather than `parent()` as
they are in e.g. the standard library.
This is not a rule that is particularly strictly observed in practice :-)
Personally I find it adds noise and ob...
2011 Feb 18
1
[LLVMdev] DIFactory
...g to the LLVM Coding Standards
document (http://llvm.org/docs/CodingStandards.html#ll_naming):
*Function names*
should be verb phrases (as they represent actions), and command-like
function should be imperative. The name should be camel case, and start with
a lower case letter (e.g. openFile() or isFoo()).
The coding standards say functions should begin with a lower case letter,
but I see a lot of new code (not just DIBuilder) that uses method names that
begin with an upper case letter. Is the document incorrect, or is there
basically no enforcement?
--
-- Talin
-------------- next part -----...
2018 May 24
0
Style: getFoo() vs foo()
...llvm-dev <llvm-dev at lists.llvm.org> wrote:
>
> The coding guidelines say:
> > Function names should be verb phrases (as they represent actions), and command-like function should be imperative. The name should be camel case, and start with a lower case letter (e.g. openFile() or isFoo()).
>
> This means that functions that just compute or access a value (no side-effects) should be named e.g. `getParent()`, rather than `parent()` as they are in e.g. the standard library.
>
> This is not a rule that is particularly strictly observed in practice :-)
> Personally I...
2018 May 24
1
Style: getFoo() vs foo()
...lt;llvm-dev at lists.llvm.org> wrote:
>>
>> The coding guidelines say:
>>> Function names should be verb phrases (as they represent actions), and command-like function should be imperative. The name should be camel case, and start with a lower case letter (e.g. openFile() or isFoo()).
>>
>> This means that functions that just compute or access a value (no side-effects) should be named e.g. `getParent()`, rather than `parent()` as they are in e.g. the standard library.
>>
>> This is not a rule that is particularly strictly observed in practice :-)
>...
2011 Feb 18
0
[LLVMdev] DIFactory
On 18 February 2011 21:34, Talin <viridia at gmail.com> wrote:
> Sorry, I meant DIBuilder.
DIBuilder is the new DIFactory. I've been playing with it this week
and it's much easier and straightforward to use. I'm still having
problems to create arrays, though.
As far as I remember (from the 2010 meeting), the idea was to replace
and deprecate DIFactory.
I'm not saying we
2011 Feb 18
4
[LLVMdev] DIFactory
Sorry, I meant DIBuilder.
On Fri, Feb 18, 2011 at 1:32 PM, Talin <viridia at gmail.com> wrote:
> I didn't know DIFactory existed until you mentioned it just now.
>
> And if folks are adding brand new classes to LLVM, can we not follow the
> naming conventions in the developer guidelines?
>
> On Fri, Feb 18, 2011 at 5:14 AM, Renato Golin <rengolin at
2013 Apr 18
9
[PATCH v5 1/2] libxl: Introduce functions to add and remove USB devices to an HVM guest
This patch exposes a generic interface which can be expanded in the
future to implement USB for PVUSB, qemu, and stubdoms. It can also be
extended to include other types of USB other than host USB (for example,
tablets, mice, or keyboards).
For each device removed or added, one of two protocols is available:
* PVUSB
* qemu (DEVICEMODEL)
The caller can additionally specify "AUTO", in