Stack Overflow
-
David Kentley wrote:
I believe the only reason this is a problem is because you are used to case sensitivity in other languages.
Not the only reason. It is also considered bad writing to mix cases. Ask an English Major. This must be at least partially a "readability" issue and we are not even talking "code" at that point. Also all caps are difficult to read because we process the character hights and read faster. All caps slow down that process by eliminating hight variation. This indicates that consistency is optimal to readability. tRy ReadIng soMthiNg lIKe thIS aLLDaY LOnG aND sEe hOW yoU LiKE IT! With something as specific as "code" I think the problem is increased. Therefore I am sticking to the "readability" issue as supporting case-sensitive languages.
led mike
See Straw Man Argument[^] under the topic "Logical Falacies."
Matt Gerrans
-
PIEBALDconsult wrote:
detail hiding is a basic OOP principle.
:) Sure, as long as the "details" are not hidden so well that you mix them up and end up with a stack overflow.
Maybe you should just avoid all languages that allow any sort of recursion. :laugh:
Matt Gerrans
-
Properties are wonderful. I think Mr. Kentley has it right -- case sensitive languages are the problem.
Matt Gerrans
>>case sensitive languages are the problem No, sloppy coders are the problem. properties does not kill apps, people do.. ;-)
-
Maybe you should just avoid all languages that allow any sort of recursion. :laugh:
Matt Gerrans
Matt Gerrans wrote:
Maybe you should just avoid all languages that allow any sort of recursion.
No, I just avoid methods that look like data members ;P
-
>>case sensitive languages are the problem No, sloppy coders are the problem. properties does not kill apps, people do.. ;-)
They can have my properties when they pry them from my cold dead hands.
-
Matt Gerrans wrote:
Maybe you should just avoid all languages that allow any sort of recursion.
No, I just avoid methods that look like data members ;P
I'll admit I've used case-sensitivity to distinguish fields from the properties that represent them. I've never had this recursion problem and it doesn't seem like a big issue. Seems like it should be easy to track down. I don't even think it is necessary to have some silly convention like junking up field names with an "_" or "m_" prefix (or even a "look_out_this_here_is_a_member_variable_and_the_other_one_is_a_property_reference_so_do_be_careful_" prefix). I had more troubles with unexpected recursion when overloading the comparision operator. That's where you discover a strange dichotomy between reference variables and operator overloading, in that operator overloading kind of lets you treat variables like they are values when they are really references. It works out okay in C++ because you really can do that, but in C# it is trickier.
Matt Gerrans
-
This is one of the reasons that I use underscore to prefix fields. They make it so much easier to spot.
Arthur Dent - "That would explain it. All my life I've had this strange feeling that there's something big and sinister going on in the world." Slartibartfast - "No. That's perfectly normal paranoia. Everybody in the universe gets that." Deja View - the feeling that you've seen this post before.
I was not bitten by the same bug, but I started doing it a couple of months back. Reason? They're easier to spot. :)
Cheers, Vikram.
"Life isn't fair, and the world is full of unscrupulous characters. There are things worth fighting for, killing for and dying for, but it's a really small list. Chalk it up to experience, let it go, and move on to the next positive experience in your life." - Christopher Duncan.
-
Properties are wonderful. I think Mr. Kentley has it right -- case sensitive languages are the problem.
Matt Gerrans
Properties (with appropriate gettors and settors) are excellent assets to the language. I would say case-sensitivity is also required. The good glue is a a good consistent programming standard (aka) coding standard which would make a cleaner reading of the code, finer debugging, elegant troubleshooting and expedited resolution to the problem.
Vasudevan Deepak Kumar Personal Homepage namespace LavanyaDeepak
Personal Weblog
The World of Deepak and Lavanya
Views and Reviews -
Properties (with appropriate gettors and settors) are excellent assets to the language. I would say case-sensitivity is also required. The good glue is a a good consistent programming standard (aka) coding standard which would make a cleaner reading of the code, finer debugging, elegant troubleshooting and expedited resolution to the problem.
Vasudevan Deepak Kumar Personal Homepage namespace LavanyaDeepak
Personal Weblog
The World of Deepak and Lavanya
Views and ReviewsVasudevan Deepak Kumar wrote:
Properties (with appropriate gettors and settors) are excellent assets to the language.
How so?
-
Vasudevan Deepak Kumar wrote:
Properties (with appropriate gettors and settors) are excellent assets to the language.
How so?
Expressiveness.
-
Pete O'Hanlon wrote:
use underscore to prefix fields
Wow, I thought I was the only one left doing that. :cool:
led mike
Hehe, I'm still using m_ prefix in my code, for member variables. I got a fellow coworker who goes further and uses l_ prefix for local variables and p_ prefix for parameters... :doh:
A polar bear is a bear whose coordinates has been changed in terms of sine and cosine. Blog Personal Site
-
I had a problem with a web application killing the dev server built in to VS2005 with stack overflow errors and I couldn't find the problem. I went so far as finding every for, foreach, and while loop and putting a counter in them that would throw an exception with the method name in the message if it looped over 1000 times (which none of the loops should do in this app). The problem all came down to one capitalization error that I didn't see even though I went step by step through execution with the debugger...
public string Name
{
get { return this.Name; }
}
private string name;Obviously the "this.Name" in the property should be "this.name". I felt like a moron when it was over.
-
I had a problem with a web application killing the dev server built in to VS2005 with stack overflow errors and I couldn't find the problem. I went so far as finding every for, foreach, and while loop and putting a counter in them that would throw an exception with the method name in the message if it looped over 1000 times (which none of the loops should do in this app). The problem all came down to one capitalization error that I didn't see even though I went step by step through execution with the debugger...
public string Name
{
get { return this.Name; }
}
private string name;Obviously the "this.Name" in the property should be "this.name". I felt like a moron when it was over.
Classic, it makes me think that it is about time the compiler warned you about this sort of tight recursion where there is no possible exit. :)
Ant. I'm hard, yet soft.
I'm coloured, yet clear.
I'm fruity and sweet.
I'm jelly, what am I? Muse on it further, I shall return! - David Walliams (Little Britain) -
This is one of the reasons that I use underscore to prefix fields. They make it so much easier to spot.
Arthur Dent - "That would explain it. All my life I've had this strange feeling that there's something big and sinister going on in the world." Slartibartfast - "No. That's perfectly normal paranoia. Everybody in the universe gets that." Deja View - the feeling that you've seen this post before.
I even prefer the good old m_ prefix. MFC legacy.
"We trained hard, but it seemed that every time we were beginning to form up into teams we would be reorganised. I was to learn later in life that we tend to meet any new situation by reorganising: and a wonderful method it can be for creating the illusion of progress, while producing confusion, inefficiency and demoralisation." -- Caius Petronius, Roman Consul, 66 A.D.
-
I had a problem with a web application killing the dev server built in to VS2005 with stack overflow errors and I couldn't find the problem. I went so far as finding every for, foreach, and while loop and putting a counter in them that would throw an exception with the method name in the message if it looped over 1000 times (which none of the loops should do in this app). The problem all came down to one capitalization error that I didn't see even though I went step by step through execution with the debugger...
public string Name
{
get { return this.Name; }
}
private string name;Obviously the "this.Name" in the property should be "this.name". I felt like a moron when it was over.
That has happened to me a couple of times. It's Intellisense/Visual Assist fault, for completing the statement when I mean something else! :-D
Luis Alonso Ramos Intelectix Chihuahua, Mexico
Not much here: My CP Blog!
-
Hehe, I'm still using m_ prefix in my code, for member variables. I got a fellow coworker who goes further and uses l_ prefix for local variables and p_ prefix for parameters... :doh:
A polar bear is a bear whose coordinates has been changed in terms of sine and cosine. Blog Personal Site
I do this too (the m, l and p things). And even though camel case is widespread now, I find it too useful to drop it.