|
Since you like it, what's the rationale for starting just the first word with a lower case letter?
Why is
customerAccountNumber
better than
CustomerAccountNumber
or
strCustomerAccountNumber
or
lpszCustomerAccountNumber
?
|
|
|
|
|
Who knows? The point is convention. You can tell at a glance what you're dealing with (local/member/property etc). And if we all do things the same way it makes it easier to understand each other's code. A good thing surely.
Regards,
Rob Philpott.
|
|
|
|
|
Rob Philpott wrote: Who knows? The point is convention.
And that's my point. All you're saying is that being consistent is good, and being able to identify scope from name is good. But that's not a justification for using camel case.
I've never seen a good reason why it's "better" than other naming standards, and I think it's worse. My deliberately chosen example is something that is conventionally called a number, but in the real world is very ofen a mixture of letters and numbers, and so has to be represented as a string. Using the camel case standard, you somethings can't infer data type from the name, which to me seems a backward step.
|
|
|
|
|
Electron Shepherd wrote: But that's not a justification for using camel case.
It absolutely is. Having a standard, even if its not very good is far better than everyone going off and doing their own thing. I never claimed camel case to be a good idea but it is the convention in the example given. Its a bit like suggesting you spell words the way they sound rather than the way they're spelled because it makes more sense.
Regards,
Rob Philpott.
|
|
|
|
|
Rob Philpott wrote: But that's not a justification for using camel case
Rob Philpott wrote: It absolutely is.
No, it's a justification for using a standard. It's not a justifcation for selecting camel case as that standard.
Your point about "You can tell at a glance what you're dealing with (local/member/property etc). And if we all do things the same way it makes it easier to understand each other's code." are entirely valid, and I agree with them, but they apply just as much to Hungarian notation as camel case.
|
|
|
|
|
Electron Shepherd wrote: But that's not a justification for using camel case
Electron Shepherd wrote: It absolutely is.
Electron Shepherd wrote: No, it's a justification for using a standard.
Uh-huh. Ok it's not a justification for using camel case for its own merit, its justification for using camel case because that is the standard. Better?
Regards,
Rob Philpott.
|
|
|
|
|
Not really. It still doesn't explain why it's the standard in the first place. That's what I'm trying to userstand. Lots of people use camel case as a naming standard, but no-one seems able to say why it's better than the others.
So, if you were tasked with developing a set of coding standards, and you decided to use camel case for variables, would you be explain to someone the benefits of that over an MFC-style str... or C-style lpsz... convention?
|
|
|
|
|
Dude, I've told you I don't know why it's the standard, probably because they nicked it from Java at a guess. Standards aren't always designed, sometimes they just get adopted and evolve despite being imperfect. Who knows? I would expect Hungarian got dropped due to the better Intellisense handling in Visual Studio at its mainstay 'p_' no longer holding any worth. In short its benefits got outweighed by its clumsiness.
Regards,
Rob Philpott.
|
|
|
|
|
Rob Philpott wrote: I don't know why it's the standard
I'm not asking why it's the standard where you are. You seem to like it as a naming convention. What I'm asking is why you like it. Why do you think it's better than the others?
I may have misinterpreted your opinion of course. You may dislike it as much as I do...
|
|
|
|
|
Actually, it's not something I feel deeply passionate about. Kind of indifferent to it as a choice, kind of like it because it is a standard and I can, for instance, tell what's a type (Pascal) and what's a variable (Camel) at a glance.
Thank God, it's time to go to the pub now (almost)...
Regards,
Rob Philpott.
|
|
|
|
|
How about the MS Naming Guidelines[^]??
Sarchasm : The gulf between the author of sarcastic wit and the person who doesn't get it.
|
|
|
|
|
I sometimes feel alone in this opinion, but I believe that source code readability is a very, very, close second place to code correctness. Anyone else?
"Why look within yourself for THE TRUTH, when you're the one who's confused in the first place?"
Mr. Spackle
|
|
|
|
|
me too. which is why i think LINQ is crap.
|
|
|
|
|
I find LINQ quite readable in most cases.
|
|
|
|
|
StyleCop is meant to be used on user-written source files. Do not use it on auto-generated files
|
|
|
|
|
Hmmm, I always thought StyleCop was intended for the garbage can...
.45 ACP - because shooting twice is just silly ----- "Why don't you tie a kerosene-soaked rag around your ankles so the ants won't climb up and eat your candy ass..." - Dale Earnhardt, 1997 ----- "The staggering layers of obscenity in your statement make it a work of art on so many levels." - J. Jystad, 2001
|
|
|
|
|
Is that the latest incarnation of FXCOP? Perfect tool if you want lots of criticism of perfectly valid code if so.
Regards,
Rob Philpott.
|
|
|
|
|
No, FxCop and StyleCop are different. StyleCop analyzes your source code, whereas FxCop does static analysis on your compiled assembly. Normally you are supposed to use them together, so they complement each other.
|
|
|
|
|
Oh, ok. In which case, I hate *both* of them.
Regards,
Rob Philpott.
|
|
|
|
|
|
They complement each other, but they certainly don't compliment you. BTW - they work really well in combination with NDepend.
|
|
|
|
|
Pete O'Hanlon wrote: BTW - they work really well in combination with NDepend.
Interesting. Never used NDepend myself though.
|
|
|
|
|
i hate the need for styling in first place.
|
|
|
|
|
I'll admit that I'm not a fan of all styling conventions, and I think when working on the same project as others, it's nice to just stay consistent. But the underscore in variable names is killing me, I didn't think it would bug me so much.
|
|
|
|
|
I don't like style cop unless I am offshoring unthinking work to unthinking developers. True software is written by creative professionals. If I wanted to be micromanaged I would work in a call center.
|
|
|
|