search for: lower_case

> If we are going to change how we name variables, I very much want them to > not collide with either type names or function names. My suggestion would be > "lower_case" names. > > This also happens to be the vastly most common pattern across all C++ coding > styles and C-based language coding styles I have seen. STL has "lower_case" functions, and exposes far fewer variables. I can't really recall which of myFunc/my_var or my_func/myV...

...Regarding making data-member names distinct from local variables, some people don't see why it should matter, others find it helpful; given this neutral-to-helpful spectrum, going with the kind-of helpful convention seems preferable. So: - Local variables and formal parameters should be lower_case, with one exception: Variables/parameters that have lambda/function type should follow the function-name spelling rules. - Class data members should have an "m_" prefix, so m_lower_case. - Initialisms and other abbreviations would be considered words for this purpose, so we have na...

...easier for me to read the code" and on the other side "meh, I don't see the benefit"; however I do *not* see anyone saying "No, this really would interfere with my code-reading." > > > So: > > > > - Local variables and formal parameters should be lower_case, with > > one exception: Variables/parameters that have lambda/function > > type should follow the function-name spelling rules. > > "lower_case" is a pretty drastic change from CamelCase and camelCase. > So far the only argument for it I've seen is, "ll...

I’d like to discuss revising the LLVM coding conventions to change the naming of variables to start with a lowercase letter. This should not be a discussion on the pain of such a transition, or how to get from here to there, but rather, if there is a better place to be. My arguments for the change are: 1. No other popular C++ coding style uses capitalized variable names. For instance here

> On Jul. 5, 2018, at 18:12, Bruce Hoult via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > > > On Thu, Jul 5, 2018 at 5:30 PM, Adrian Prantl via llvm-dev <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote: > > > > On Jul 5, 2018, at 1:09 PM, Rui Ueyama via llvm-dev <llvm-dev at lists.llvm.org <mailto:llvm-dev at

This thread is not active for a while, but I'm still interested in seeing a change. Reading through this thread, looks like we can agree that we want to change the local variable naming scheme so that they start with a lowercase letter. Besides that, there were discussions about lower_case, camelCase, m_ prefix, and each argument seems as convincing as others. I'm not sure what is the decision making process in a situation like this. I'd personally vote for changing local variables to start with a lowercase letter and keep other naming conventions as-is to make it a minimum...

...active for a while, but I'm still interested in seeing > a change. > > > > Reading through this thread, looks like we can agree that we want to > change the local variable naming scheme so that they start with a lowercase > letter. Besides that, there were discussions about lower_case, camelCase, > m_ prefix, and each argument seems as convincing as others. I'm not sure > what is the decision making process in a situation like this. > > > > I'd personally vote for changing local variables to start with a lowercase > letter and keep other naming conve...

...ead is not active for a while, but I'm still interested in seeing a change. > > > > Reading through this thread, looks like we can agree that we want to change the local variable naming scheme so that they start with a lowercase letter. Besides that, there were discussions about lower_case, camelCase, m_ prefix, and each argument seems as convincing as others. I'm not sure what is the decision making process in a situation like this. > > > > I'd personally vote for changing local variables to start with a lowercase letter and keep other naming conventions as-i...

.... >>>> >>>> >>>> >>>> Reading through this thread, looks like we can agree that we want to >>>> change the local variable naming scheme so that they start with a lowercase >>>> letter. Besides that, there were discussions about lower_case, camelCase, >>>> m_ prefix, and each argument seems as convincing as others. I'm not sure >>>> what is the decision making process in a situation like this. >>>> >>>> >>>> >>>> I'd personally vote for changing local var...

...eeing a change. >>>>> >>>>> >>>>> >>>>> Reading through this thread, looks like we can agree that we want to change the local variable naming scheme so that they start with a lowercase letter. Besides that, there were discussions about lower_case, camelCase, m_ prefix, and each argument seems as convincing as others. I'm not sure what is the decision making process in a situation like this. >>>>> >>>>> >>>>> >>>>> I'd personally vote for changing local variables to star...

...gt;>>>> >>>>> >>>>> Reading through this thread, looks like we can agree that we want to >>>>> change the local variable naming scheme so that they start with a lowercase >>>>> letter. Besides that, there were discussions about lower_case, camelCase, >>>>> m_ prefix, and each argument seems as convincing as others. I'm not sure >>>>> what is the decision making process in a situation like this. >>>>> >>>>> >>>>> >>>>> I'd personally vot...

On Fri, Feb 22, 2019 at 12:39 PM Chandler Carruth via llvm-dev < llvm-dev at lists.llvm.org> wrote: > On Fri, Feb 22, 2019 at 5:59 AM via llvm-dev <llvm-dev at lists.llvm.org> > wrote: > >> - Local variables and formal parameters should be lower_case, with >> one exception: Variables/parameters that have lambda/function >> type should follow the function-name spelling rules. >> > > I really dislike this exception. Callable objects are *objects* and > locally scoped, I would much prefer they look like variables. &g...

Hi folks, Git is on its way to learning how to ignore commits, allowing us to do variable renaming and other small refactorings without breaking git blame. It's like git-hyper-blame [1] but significantly more powerful as it uses fuzzy matching to match lines, including lines that may have been split or joined. A preview release of Git with this new feature is at:

...>>>> >>>>>>> Reading through this thread, looks like we can agree that we want to >>>>>>> change the local variable naming scheme so that they start with a lowercase >>>>>>> letter. Besides that, there were discussions about lower_case, camelCase, >>>>>>> m_ prefix, and each argument seems as convincing as others. I'm not sure >>>>>>> what is the decision making process in a situation like this. >>>>>>> >>>>>>> >>>>>>> &gt...

> On Feb 19, 2019, at 7:43 AM, Alex Bradbury via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > On Tue, 19 Feb 2019 at 15:24, Zachary Turner <zturner at google.com> wrote: >> On Mon, Feb 18, 2019 at 2:16 AM Michael Platings via llvm-dev <llvm-dev at lists.llvm.org> wrote: >>> >>> Regarding a plan for conversion, I'm keen to avoid perfect

...but I'm still interested in >> seeing a change. >> >> Reading through this thread, looks like we can agree that we want to >> change the local variable naming scheme so that they start with a >> lowercase letter. Besides that, there were discussions about >> lower_case, camelCase, m_ prefix, and each argument seems as >> convincing as others. I'm not sure what is the decision making >> process in a situation like this. >> >> I'd personally vote for changing local variables to start with a >> lowercase letter and keep other n...

On Tue, Mar 10, 2015 at 8:47 PM, Rafael Espíndola < rafael.espindola at gmail.com> wrote: > > However, everyone seems to think I'm advocating we never move the CMake > > version forward. That isn't what I'm saying at all. What I am saying is > that > > moving the CMake version forward has a cost. Not a huge insurmountable > cost, > > but non-zero

...> Variable names: ??? > > If we name variables in camelCase then variable names and function names > collide. > > If we are going to change how we name variables, I very much want them to > not collide with either type names or function names. My suggestion would > be "lower_case" names. > I think this would be bad: function(); lambda(); longFunction(); long_lambda(); ... but possibly not in practice, since function names rarely have only one word. A partial-camel-case, partly-underscores convention sounds strange to me. (I don't find this to be prob...

...in > >> seeing a change. > >> > >> Reading through this thread, looks like we can agree that we want to > >> change the local variable naming scheme so that they start with a > >> lowercase letter. Besides that, there were discussions about > >> lower_case, camelCase, m_ prefix, and each argument seems as > >> convincing as others. I'm not sure what is the decision making > >> process in a situation like this. > >> > >> I'd personally vote for changing local variables to start with a > >> lowercase...

In an effort to improve the out-of-the-box experience with Linux kernels for VMware users, VMware is working on readying the Virtual Machine Communication Interface (vmw_vmci) and VMCI Sockets (vmw_vsock) kernel modules for inclusion in the Linux kernel. The purpose of this post is to acquire feedback on the vmw_vmci kernel module. The vmw_vsock kernel module will be presented in a later post.